1. 问题描述
我们公司有两套平台,一套基础平台,包含常见的用户、组织、角色等功能,另一套是BPM管理平台,两套平台通过Oauth统一认证实现互认。
前端时间项目组反馈,登录业务系统后调用BPM接口,一开始一切正常,过两三天之后所有的BPM接口都开始报错。重启BPM平台后接口访问正常,但过几天后再次开始报错。
2. 排查
收到问题,第一时间查询BPM平台日志。发现日志中记录到BPM调用基础平台接口过程中,基础平台返回401未授权异常。
经过一段时间的排查发现,在主线程中的Feign调用基础平台接口正常,子线程中调用基础平台接口会返回HTTP 401。怀疑子线程中获取不到主线程Request
的Header
。
继续跟踪代码,发现子线程的Feign调用接口时,构建请求的RequestTemplate
的Header
中也是有token的,于是推翻了之前的验证。而且如果子线程获取不到token,肯定是一直调用失败,而不会几天后才出现调用失败的情况。
再向下追踪,发现主线程的Feign调用接口时用的token,与子线程的Feign调用接口时用的token竟然不同。这可真是离了个大谱啊……用postman测试,主线程token有效,子线程token过期。
写代码把主线程token和子线程token分别Base64解密,更滑稽的事儿来了,两个token分别属于不同的用户。
再后面的头脑风暴过程不写了,聪明的小伙伴大概能猜到原因,所以直接给结论了。
3. 结论
提到子线程拿主线程Request
的token,第一反应肯定是利用InheritableThreadLocal
来实现父子线程通信,其原理简单地说,就是在创建子线程时,其内部的init()
方法会获取父线程变量,并将其保存到自身的InheritedMap
中。其中比较重要的就是在初始化子线程时调用init()
方法这一步。
这里的bug在于,我们的系统中使用了线程池。众所周知,线程池会初始化一批线程来复用,以减少申请线程的消耗,提升效率。因此,只有第一次new Thread()的时候,子线程才会复制父线程变量,后面每次使用子线程调用Feign接口的时候,都不再取父线程token,而是一直用以前的token,直到token过期,且恰好主线程用到了包含过期token的子线程,此时问题开始发生了。
有关InheritableThreadLocal
和线程池搭配使用的问题,这篇文章写得更加详细:
4. 解决方案
考虑了几种方案,最终采用了又成熟又方便的TransmittableThreadLocal
。
TransmittableThreadLocal
由阿里巴巴开源,专门用来解决线程池与InheritableThreadLocal
搭配使用失效的问题。
TransmittableThreadLocal
提供了一种非常简单的使用方法,代码入侵极少,我们也采用了这种方法:
- 使用TtlExecutors.getTtlExecutorService(executorService)来修饰原有ExecutorService。
- 将原来用到的
InheritableThreadLocal
替换为TransmittableThreadLocal
。