数据污染的核心原因是线程复用且未显式remove()，导致下一个任务读取上一个任务残留值；必须在finally中调用remove()兜底清理，禁用set(null)，并可通过afterExecute统一补救。
在线程池中复用 ThreadLocal 时，数据污染的核心原因是：线程不销毁，而 ThreadLocal 的值未及时清理，导致下一个任务 get() 到上一个任务遗留的数据。防止污染不是靠“等它消失”，而是靠主动、确定、兜底的清理机制。
必须在业务结束时显式调用 remove()
ThreadLocal 不会自动清空，尤其在线程池里，一个线程可能连续执行几十个请求。只要没调 remove()，旧值就一直留在当前线程的 ThreadLocalMap 中。
- 务必放在 try-finally 的 finally 块里，确保异常或正常返回都能执行
- 不要写成
if (xxx) tl.remove()—— 条件不成立时，值照样残留 - 禁止用
set(null)替代remove()：它只是把 value 设为 null，Entry 还在，key=null 的脏项仍占内存、影响 GC
声明为 static final，但更要严控生命周期
ThreadLocal 实例本身应声明为 private static final，这是正确做法，能避免重复创建、便于统一管理。但这反而放大风险——它的生命周期几乎与 JVM 同寿，每个工作线程都为它维护一份 value。
- 错误示例：每次 new Callable 都 new 一个 ThreadLocal → 失去线程隔离意义，还加剧 GC 压力
- 正确示例：
private static final ThreadLocalCONTEXT = new ThreadLocal(); - 配套动作：每次 set() 后，必须有对应的 remove()，不能依赖 initialValue() 或构造逻辑“自动重置”
用 afterExecute 做兜底清理
即使业务代码忘了 remove，也可以通过线程池钩子补救。继承 ThreadPoolExecutor，重写 afterExecute 方法，在任务执行结束后统一清理你定义的 ThreadLocal。
- 只清理自己声明的 ThreadLocal，不要碰 Spring、MyBatis 等框架管理的上下文（它们自有生命周期）
- 示例：在
afterExecute中调用CONTEXT.remove()，比依赖每个任务自觉更可靠 - 注意：该方法在任务执行完毕后触发（无论成功或抛异常），是最后一道防线
警惕 InheritableThreadLocal 和虚拟线程组合
普通 ThreadLocal 是线程隔离的，但 InheritableThreadLocal 会在创建子线程时复制父线程的值。在 Java 21+ 虚拟线程场景下，调度频繁，容易让本不该关联的请求意外共享上下文（比如 A 请求的用户 ID 传给了 B 请求）。
- 除非明确需要继承，否则一律使用普通 ThreadLocal
- 若必须用 InheritableThreadLocal，需在子线程内自行调用 remove()，父线程的 remove() 对子线程无效
- 避免在虚拟线程中无意识开启继承行为，防止上下文“跨请求泄漏”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
