必须在任务结束后显式清理threadlocal值，因线程复用导致threadlocalmap中旧value残留而污染后续请求；推荐重写afterexecute或使用onceperrequestfilter兜底清理。
Java 线程池防止 ThreadLocal 数据污染，核心就一条：每次任务结束时必须显式清理 ThreadLocal 值。因为线程复用不会自动清空 ThreadLocalMap，前一个请求留下的数据会直接“串”到下一个请求里。
为什么复用会导致污染
Tomcat 默认线程池（或自定义 ThreadPoolExecutor）中的线程长期存活。ThreadLocal 的值实际存在每个 Thread 对象的 ThreadLocalMap 中，key 是 ThreadLocal 实例（弱引用），value 是你存的数据（强引用）。线程执行完任务不清理，map 里的 value 就一直挂着——下次该线程处理新请求时，get() 还能拿到旧值，尤其是没调 set() 的时候，脏数据直接生效。
必须在任务结束后统一清理
不能只靠业务代码里写 try-finally，容易遗漏（比如异常未捕获、任务被中断、甚至逻辑没走到 finally）。最可靠的方式是在线程执行完 Runnable 后兜底清理：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 继承
ThreadPoolExecutor，重写afterExecute(Runnable r, Throwable t) - 在方法体内对所有已知 ThreadLocal 调用
.remove() - 确保即使任务抛出未捕获异常，清理也一定执行
Web 场景推荐用 Filter 或 Interceptor 清理
Spring Boot 项目中，HTTP 请求生命周期明确，适合在请求出口处集中清理：
- 写一个
OncePerRequestFilter，在doFilterInternal最后或afterCompletion回调里调用threadLocal.remove() - 如果用了多个 ThreadLocal（如用户信息、traceId、事务上下文），挨个 remove
- 注意：要放在 response 已提交之后或 finally 块中，避免因异常跳过
声明和使用要规范
减少出错概率，从源头控制：
- ThreadLocal 声明为
private static final，避免重复创建和意外 GC - 提供封装好的
clear()方法，内部只做remove()，不写set(null)（后者不释放 Entry，仍可能内存泄漏） - 业务代码里凡用到
set()，原则上都要配对remove()；短生命周期场景（如一次请求）建议“用完即清”，哪怕只读也清
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
