线程池中 threadlocal 忘记 remove 必然导致污染，因复用线程会残留上一请求的值；必须在任务执行前后主动 set/remove，或通过 afterexecute、filter/interceptor 统一清理，并用日志、jmap、mat 主动排查。
线程池里用 ThreadLocal 忘记 remove，不是“可能”污染，而是“必然”污染——只要线程被复用，上一个请求存的值就大概率留在下一个请求里。这不是偶发问题，是机制决定的确定性风险。
为什么污染会悄悄发生
线程池中的线程长期存活，ThreadLocal 的值就锁死在它的 ThreadLocalMap 里。比如一次请求 set 了 userId="u1001"，执行完没 remove；下一次分配到同一线程的请求调用 get()，拿到的还是 "u1001"，哪怕它本该是 "u2002" 或 null。这种错乱不报错，只在以下环节暴露：
- 回调接口没走登录流程，却记录了前一个用户的操作人 ID
- 异步任务中 traceId 复用，导致链路追踪断裂或串号
- 多租户系统中 tenantId 残留，造成数据跨租户误读
真正管用的清理方式
不能依赖“线程新建时自动清空”，因为线程池几乎不新建线程；也不能只靠 setThreadFactory，它只对扩容新线程生效。必须在任务生命周期内主动控制：
- 所有 Runnable/Callable 提交前，用闭包捕获当前上下文值（如 traceId、userId），并在 run() 开头 set，finally 中 remove
- Spring 环境下，重写 ThreadPoolTaskExecutor.afterExecute()，统一调用各 ThreadLocal 实例的 remove()
- 避免 static ThreadLocal 存大对象；若必须存，remove 后再置 null，切断强引用链
Filter/Interceptor 场景怎么兜底
Web 请求链路中，Filter 或 Interceptor 常用于 set 用户上下文，但响应返回后若没 clear，就会污染后续请求：
- 在 Filter 的 doFilter 方法末尾显式调用 remove()
- Spring 的 HandlerInterceptor.afterCompletion 中统一 remove
- 不要只依赖 try-finally 写在业务方法里——拦截器本身可能被跳过，或异常未被捕获
排查和验证是否真漏了 remove
别等 OOM 才行动，主动验证更有效：
- 在疑似位置加诊断日志：if (threadLocal.get() != null) log.warn("ThreadLocal value still present before set")
- 用 jmap -histo:live 观察 String、DTO、UserContext 等对象实例数是否随请求量线性上升
- 用 MAT 分析 heap dump，筛选 ThreadLocalMap.Entry，重点找 key == null 但 value 指向大对象的“幽灵条目”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
