InheritableThreadLocal在线程池中“复用旧值”是因为线程复用导致继承逻辑不触发，且上一次任务的值未remove，造成上下文污染；其浅拷贝仅复制引用，加剧并发风险；修复需手动set/remove或改用TransmittableThreadLocal。
为什么线程池中 InheritableThreadLocal 会“复用旧值”
InheritableThreadLocal 的继承只发生在 new Thread() 构造时，靠的是 JVM 在 Thread 初始化阶段把父线程的 inheritableThreadLocals Map 深拷贝到子线程。但线程池（如 ThreadPoolExecutor）里的线程是复用的——submit() 或 execute() 不会创建新线程，只是从队列取一个空闲线程执行任务。这意味着：父线程设置的值根本不会触发继承逻辑，而该线程上一次任务留下的 InheritableThreadLocal 值还留在 inheritableThreadLocals 里。
常见现象是：A 请求设置了用户 ID “u1001”，异步任务执行完后没 remove()；B 请求复用同一线程，get() 拿到的还是 “u1001”，造成用户信息错乱。
- 不是“没传过去”，而是“根本没清干净，旧值还在”
-
childValue(T)方法不生效——因为没发生线程继承 - 所有基于线程池的异步框架（
CompletableFuture、Dubbo 线程模型、Spring @Async）都受此影响
InheritableThreadLocal 的浅拷贝到底拷了什么
所谓“浅拷贝”，是指 ThreadLocal.createInheritedMap() 复制的是 Entry 数组本身，但每个 Entry 中的 value 是直接引用复制，不是深克隆。如果 value 是可变对象（比如 HashMap、UserContext 实例），子线程拿到的是同一个对象引用。
这在单次父子线程场景下问题不大，但在线程池中叠加复用，就变成双重风险：既可能读到旧数据，又可能被并发修改破坏状态。
- value 是基本类型或不可变对象（如
String、Long）→ 安全性稍高，但污染仍存在 - value 是
new HashMap()或自定义上下文类 → 多个任务共享同一实例，写操作互相覆盖 - 即使手动
set()新值，也只是替换引用，旧对象若没被 GC，仍占内存
如何验证当前线程池是否已污染
最直接的方式是在任务开头加日志，打印关键上下文和线程名：
log.info("thread={}, user={}", Thread.currentThread().getName(), userContext.get());
观察相同线程名（如 pool-1-thread-3）连续执行不同请求时，userContext.get() 是否出现前序请求的残留值。也可以在 beforeExecute() 钩子中统一检查：
- 重写
ThreadPoolExecutor.beforeExecute() - 对每个任务执行前调用
userContext.get() != null+log.warn()报警 - 配合
Thread.currentThread().getId()做线程级 trace
真正能落地的修复方式只有两种
别信“只要用 InheritableThreadLocal 就能自动透传”的说法——在线程池里它就是失效的。必须主动干预生命周期。
- 每次任务开始前手动
set()当前上下文，结束前必须remove()，且不能依赖finally（异常可能跳过）→ 推荐用 try-with-resources 封装AutoCloseable上下文管理器 - 彻底弃用
InheritableThreadLocal，改用TransmittableThreadLocal（TTL），它通过wrap(Runnable)和decorate()显式绑定上下文，与线程池天然兼容 - Spring 环境下可用
@Scope("prototype")+RequestContextHolder替代，避免 ThreadLocal 层面操作
最容易被忽略的一点：即使用了 TTL，如果上游没调用 TtlRunnable.get() 包装提交的任务，透传依然不生效——包装动作必须出现在任务进入线程池之前，而不是在 run() 内部。
