写在开头昨天帮一个刚转正的小伙子解决了一个bug。业务场景极其常见用户下单后主流程直接返回成功同时抛一个异步任务到线程池里去记录一条详细的用户操作日志。小伙子为了代码简洁在网关层把解析出来的 userId 存进了 ThreadLocal 封装的 UserContext 里。结果一上测试环境主流程好好的但异步线程里记录的日志操作人全是 Null甚至偶尔还会出现张三的日志记到了李四头上的诡异现象。他百思不得其解“明明在网关拦截器里塞进去了怎么一进线程池数据就离奇失踪了呢”这个坑几乎每一个做 Java 后端的同学都踩过。面试官也非常喜欢拿这个日常场景来考察你对并发底层的理解。今天 Fox 不扯什么虚无缥缈的海量高并发就结合这个最接地气的实战场景带大家把 ThreadLocal 和线程池之间的底层纠葛一次性彻底理清。一、 userId 为什么会丢先说结论因为执行任务的物理线程变了。ThreadLocal 的全名是“线程局部变量”。它的底层数据结构 ThreadLocalMap 是死死绑定在 Thread.currentThread()当前正在执行的线程身上的。存数据的时候你的拦截器跑在 Tomcat 的 Web 线程里比如 http-nio-8080-exec-1userId 稳稳地绑在这个 Web 线程上。取数据的时候你的异步记录日志任务被交给了自定义的业务线程池比如 biz-logger-pool-1。当这个工作线程去调 UserContext.get() 时它摸摸自己的口袋发现里面空空如也自然只能返回 Null。二、 面试常考陷阱被误用的 InheritableThreadLocal小伙子查了半天资料跑来跟我说“Fox 老师我懂了父子线程传值不能用普通的 ThreadLocal得换成 InheritableThreadLocal (ITL)”我赶紧把他拦住。如果你在业务线程池里用了 ITL那离真正的线上生产事故就不远了。为什么打开 JDK 源码一看便知InheritableThreadLocal 的值拷贝动作只发生在 new Thread()创建新线程的那一瞬间。但大家想想咱们平时用线程池的核心目的是什么是线程复用 线程池里的核心线程早就被预热创建好了当张三的异步日志任务丢进去时线程池直接派一个“老员工”老线程去干活根本不会触发创建新线程的动作自然也就不会有上下文的拷贝。更致命的是如果这个“老员工”上一次执行任务时残留了李四的 userId且没有被清理掉张三的任务就会直接读取到李四的上下文这就是为什么线上偶尔会出现“数据串号”的根本原因。实战铁律只要有线程池复用的地方绝对不能使用 InheritableThreadLocal三、标准解法阿里的 TTL组件面对线程池上下文传递这个硬骨头业内最成熟、最务实的解决方案是阿里开源的 TransmittableThreadLocal (简称 TTL)。它的原理一点都不神秘核心就是 12 个字“提交时捕获执行时回放”。它不依赖线程创建的瞬间而是拦截你把 Runnable 扔进线程池的那一次 submit 或 execute 动作Capture捕获在主线程把任务提交给线程池的那一刻TTL 会立刻给主线程当前的上下文拍个“快照”。Replay回放等到了线程池内部某一个工作线程真正开始执行这个任务前TTL 会把刚才拍的“快照”强制覆盖到这个工作线程上。Restore恢复任务跑完之后TTL 还会顺手把工作线程的上下文恢复原样干干净净绝不污染下一个任务。代码落地极其简单// 1. 将原生的 ThreadLocal 替换为 TTL public static final TransmittableThreadLocalString USER_CONTEXT new TransmittableThreadLocal(); // 2. 提交异步任务时用 TtlRunnable 包装一层 (最关键的一步) executorService.submit(TtlRunnable.get(() - { // 在这里安心调用稳如老狗绝对不丢、不串号 String userId USER_CONTEXT.get(); logService.saveLog(userId, 执行了下单操作); }));四、 最后的兜底保命千万别忘了 remove()把问题解决了最后 Fox 还要再唠叨一句关乎系统健康度的底线无论是用原生的 ThreadLocal还是阿里的 TTL只要是在复用线程的环境下比如 Tomcat 线程池、业务线程池用完之后必须老老实实在 finally 块或者拦截器的 afterCompletion 方法中调用 remove() 进行清理因为 ThreadLocalMap 里的 Key 虽是弱引用但 Value 是强引用。如果不清理那些随着请求进来的大对象比如完整的 UserInfo就会在线程中不断堆积。只要线程不死这部分内存就永远无法被 GC 回收日积月累最终必然会导致 JVM 内存泄漏引发频繁的 Full GC 甚至 OOM。写在最后日常 CRUD 写多了很容易让我们忽略底层运行机制。很多诡异的线上 Bug扒开外衣本质上都是对多线程和内存模型的理解存在盲区。