ThreadLocal 本质是线程级键值容器，值存于线程的 ThreadLocalMap 中（key 为弱引用 ThreadLocal 实例，value 为强引用数据）；线程池复用导致未 remove 的 value 持续残留，引发数据错乱与内存泄漏，故必须在 finally 或统一拦截点强制 remove。
不能滥用 ThreadLocal，核心在于它和线程池的生命周期不匹配：ThreadLocal 的值绑定在线程上，而线程池里的线程是长期复用的——前一个任务设的值，若没清理，下一个任务就可能误读到。
ThreadLocal 本质不是“变量”，而是“线程级键值容器”
每个线程内部持有一个 ThreadLocalMap，key 是 ThreadLocal 实例（弱引用），value 才是你存的数据（强引用）。也就是说，ThreadLocal 本身不存值，只是个“取值凭证”；真正存数据的是线程自己的 map。一旦线程被复用，map 里的 entry 还在，value 就一直挂着。
线程池复用放大了“忘记清理”的后果
普通线程执行完就销毁，map 自然回收；但线程池中的线程会反复执行不同任务。如果某个任务用了 ThreadLocal.set(userId)，却没调 remove()，那么：
- 下一次调度到该线程的任意任务，get() 都可能拿到上一个用户的 userId
- 日志 MDC 中 traceId 混乱，链路追踪断裂或错绑
- 事务上下文残留，导致跨请求提交/回滚异常
- 更隐蔽的是：新任务没 set，但逻辑依赖非空值，结果用上了脏数据
remove() 不是可选项，而是强制清理动作
靠“业务代码记得清”不可靠，必须结构化保障清理时机：
立即学习“Java免费学习笔记（深入）”；
- 在 finally 块 中调用 remove()，确保即使抛异常也执行
- Web 场景下统一在 Filter 或 Interceptor 的 afterCompletion 阶段清理
- Spring 环境可用 @Scope("prototype") + @PreDestroy 或自定义 ThreadLocal 清理 Bean
- 避免在 lambda 或并行流中直接 set/remove，容易遗漏或跨线程失效
弱引用 Key 并不能帮你“自动兜底”
有人误以为 key 是弱引用，GC 后 value 就能回收——这是误解。key 被回收后，entry 变成 “key=null”，但 value 仍被 map 强引用着，无法 GC。只有主动 remove() 或 ThreadLocalMap 的 resize/探测清理时才可能顺带 purge 掉这些 stale entry，但不保证及时性。长期运行的服务中，这种“遗孤 entry”越积越多，就是内存泄漏的源头。
