发现问题
最近在进行压测发现,有一些接口时好时坏,通过sentry日志平台及sky walking平台跟踪发现,用户张三获取到的用户上下文确是李四。
代码走读
用户登录下上文
1 | typescript复制代码/** |
在拦截器中有调用UserContext.set恢复用户登录上下文,并在请求结束时调用UserContext.clear清理用户登录上下文。
拦截器注册配置
1 | typescript复制代码/** |
通过debug可以发现UserContext中的ThreadLocal的清理工作没有得到执行。导致请求进来时,有可能ThreadLocal已存在了,就不会再根据请求上下文恢复了。
springmvc 源码走读
tomcat 在收到http请求后,最终会交由spring mvc的DispatcherServlet
处理。
这里可以从doDispatch按图索骥,顺藤摸瓜地往下看起走。
源码走读:DispatcherServlet
1 | java复制代码/** |
请求会得到分发,然后执行各个已注册Handler的preHandle–>postHandle–>afterCompletion。
源码走读:HandlerExecutionChain
applyPreHandle
1 | java复制代码/** |
当执行到preHandle返回false时,它就会从上一个返回true的handler依次往前执行afterCompletion,它自己的afterCompletion得不到执行。
triggerAfterCompletion
1 | less复制代码/** |
triggerAfterCompletion只会在(1)出现异常,(2)preHandle返回false 或(3)正常执行结束才会从索引interceptorIndex依次往前执行。
所以基于以上源码可以得知,在写拦截器时preHandle返回false时,afterCompletion是不会执行的。所以一些必要的清理工作得不到执行,会出现类似我们遇到的帐号串的问题。
参考资料
本文转载自: 掘金