InheritableThreadLocal：解析父子线程间如何传递上下文变量数据

InheritableThreadLocal仅在new Thread()构造时通过Thread.init()触发一次父线程值的浅拷贝，线程池、CompletableFuture、@Async等复用线程场景因不调用init()而无法继承，导致读取旧值而非null；需手动捕获-传递-清理，或改用TtlExecutors包装的TransmittableThreadLocal。

InheritableThreadLocal 这个工具，可以帮你在子线程创建时得到父线程的上下文副本，但要注意它的生效范围非常有限——仅限于 new Thread() 这种全新线程构造的场景。一旦牵扯到线程池、CompletableFuture、@Async 这类复用线程的场景，它就彻底失灵了。这不是配置的问题，而是它底层的设计机制决定的。

它怎么工作的？只在子线程诞生那一刻“拍照”

说白了，InheritableThreadLocal 的底层机制很简单——它重写了 ThreadLocal 的两个方法：

• getMap(Thread t)：从 t.inheritableThreadLocals 读值，而不是 t.threadLocals
• createMap(Thread t, T firstValue)：初始化时把值写入 t.inheritableThreadLocals
• 真正触发继承的核心动作，是在 Thread.init() 里完成的——把父线程当前所有 InheritableThreadLocal 的值浅拷贝过去。而 init() 只在 new Thread() 构造时调用一次，这一点至关重要。

为什么 CompletableFuture 和 @Async 拿不到值？

原因很简单：它们的执行依赖的不是新线程，而是从线程池里调度一个已有的线程。这就有问题了：线程已经创建过，init() 早就不跑了，父线程的值根本传不过去。结果不是 null——更棘手——拿到的是上一个任务留下的旧值。举个例子，traceId="req-a" 可能被 req-b 的任务误读，这种脏上下文比空值更隐蔽，也更难排查。

• CompletableFuture.runAsync() 默认走 ForkJoinPool.commonPool()，线程被反复复用
• @Async 底层是 ThreadPoolExecutor，线程不会再重新构造，init() 完全失效
• 所以，不是拿不到值，而是拿到的值可能是错的

在线程池中让它真正起作用的实操方式

想在线程池里用 InheritableThreadLocal，不能指望自动继承了——必须手动搬运，同时做清理。具体的做法其实不复杂，但每一个步骤都不能省：

• 在提交任务前，先捕获父线程里每个关键 InheritableThreadLocal 的当前值，比如 traceId.get()、userId.get() 这些
• 把捕获的值作为闭包变量传入 Runnable/Callable，在子线程执行前 set() 回去
• 最关键的一步：必须在 finally 块里调用 remove()，防止该线程被复用时携带残留值
• 如果你用了多个 InheritableThreadLocal 实例，那每个都要单独做这套操作——没有通用的反射方案能安全兜底

要不要换 TransmittableThreadLocal？

TTL 是专门解决线程池场景的增强方案，但得注意几个前提。首先，必须用 TtlExecutors.getTtlExecutorService(pool) 包装原有的线程池，裸用 Executors.newFixedThreadPool() 依然无效。其次，它通过字节码增强或 Runnable 装饰实现“捕获-重放”，对 Netty ChannelFuture、Reactor publishOn 这类非标准线程启动方式，仍需额外适配。如果你的项目已经稳定使用 InheritableThreadLocal，而且异步逻辑在可控范围内，手动包装 Runnable 反而更轻量、更透明——很多时候，踏实的代码比炫酷的方案更靠谱。