ThreadLocal 在线程池中必然残留，不显式清理会导致上下文污染；其 value 为强引用，key 为弱引用，异常或遗漏 remove 会使 value 长期驻留，引发数据错乱。
ThreadLocal 在线程池中不是“可能”污染，而是“必然”残留——只要没显式清理，复用线程就会把上一个任务的上下文带进下一个任务。这不是偶发 Bug，是机制决定的确定性风险。
为什么污染会“隐身”出现
线程池中的线程长期存活，而 ThreadLocal 的值就锁死在它的 ThreadLocalMap 里。一次请求 set 了 userId="u1001"，执行完没 remove；下一次分配到同一线程的请求 get()，拿到的还是 "u1001"，哪怕它本该是 "u2002" 或 null。这种错乱不会报错，只会在日志、数据库写入、权限校验等环节悄悄出问题，比如：
- 回调接口没走登录流程，却记录了前一个用户的操作人 ID
- 异步任务中 traceId 复用导致链路追踪断裂或串号
- 多租户系统中 tenantId 残留，造成数据跨租户误读
实战排查三步定位法
不靠猜，靠证据：
-
查堆内存增长：用
jmap -histo:live <pid>观察 String、DTO、UserContext 等对象实例数是否随请求量线性上升；若线程数稳定但老年代持续涨，大概率是 ThreadLocalMap 积压 -
抓线程快照：用
jstack <pid>确认活跃线程名（如 "task-1", "http-nio-8080-exec-5"）是否长期存在，再结合业务日志比对相同线程 ID 处理的不同请求 traceId -
看堆转储细节：用 MAT 打开 heap dump，筛选
java.lang.ThreadLocal$ThreadLocalMap，展开其 table 数组，逐个检查 Entry.value 的实际类型和内容——重点找那些本该随请求结束就释放、却长期驻留的对象
真正管用的防御手段
不能依赖“线程新建时自动清空”，因为线程池几乎不新建线程；也不能只靠 setThreadFactory，它只对扩容新线程生效。必须在任务生命周期内主动控制：
- 所有 Runnable/Callable 提交前，用闭包捕获当前上下文值（如 traceId、userId），并在 run() 开头 set，finally 中 remove
- Spring 环境下，重写
ThreadPoolTaskExecutor.afterExecute()，统一调用各 ThreadLocal 实例的 remove() - 避免 static ThreadLocal 存大对象；若必须存，remove 后再置 null，切断强引用链
最容易被忽略的关键细节
Entry 的 key 是弱引用，value 是强引用——GC 只能回收 key 为 null 的 Entry，但 value 仍牢牢挂在 Thread → threadLocals → table → Entry → value 这条链上。也就是说：
- ThreadLocal 实例本身没被回收 ≠ value 安全；相反，static 声明反而让 key 难回收，value 更顽固
- 异常路径下没走 finally？value 就永远卡住；AOP 或 Filter 中只 set 不 clear？一次遗漏就埋下隐患
- 多个 ThreadLocal（traceId、tenantId、authToken）要各自 remove，漏一个就等于开一道后门
