ThreadLocal 的 set() 可能引发内存泄漏，根本原因是其 ThreadLocalMap 的 key 为弱引用而 value 为强引用，当 ThreadLocal 实例被回收后 value 仍滞留，尤其在线程池中长期存活线程下无法释放。
ThreadLocal 的 set() 为什么可能引发内存泄漏
根本原因是 ThreadLocal 内部使用了以当前 ThreadLocal 实例为 key、用户值为 value 的 ThreadLocalMap，而这个 map 的 key 是弱引用（WeakReference），value 却是强引用。当外部不再持有 ThreadLocal 引用（比如类卸载、Spring Bean 销毁），key 被 GC 回收，但 value 仍被 map 的 entry 持有，无法释放——尤其在线程池复用线程的场景下，该 entry 会长期滞留。
典型现象：堆内存中出现大量 ThreadLocalMap$Entry 对象，对应的 value 是大对象（如 UserContext、TraceId 等），GC 日志显示老年代持续增长却无法回收。
- 只有线程结束时，
ThreadLocalMap才会整体被回收；线程池中的工作线程几乎永不终止 -
set()和get()都会触发探测式清理（expungeStaleEntries），但仅清理「已失效的 key 对应的 entry」，不保证及时或彻底 - 如果只调用
set()从不remove()，且线程长期存活，泄漏基本确定
必须配合 remove() 使用，且要放在 finally 块里
这不是可选项，而是强制实践。哪怕你用了 try-with-resources 或 Spring AOP，只要逻辑可能提前 return/break/throw，就必须确保 remove() 执行。
错误写法：threadLocal.set(val); doWork(); —— 中间抛异常就漏了；if (condition) threadLocal.remove(); —— 条件不满足时照样残留。
- 正确模式：在业务逻辑包裹的最外层
try-finally中调用threadLocal.remove() - 不要依赖
ThreadLocal的构造函数或initialValue()来“自动初始化+自动清理”——它不解决清理问题 - 若上下文需跨多层方法传递，建议封装成工具类（如
ContextHolder），把set/remove收口，避免各处裸调用
public static void executeWithContext(User user) {
threadLocal.set(user);
try {
doBusinessLogic();
} finally {
threadLocal.remove(); // 必须！不可省略
}
}
使用 static final ThreadLocal 时更要小心生命周期
很多人误以为 static final ThreadLocal<T> 安全，其实恰恰相反：它的生命周期与类相同，几乎永生；而它关联的 value 若未手动 remove()，就会随线程一直挂着。
尤其在 Web 容器（Tomcat/Jetty）或 Spring Boot 应用中，一次请求 → 分配线程 → set → 处理 → 忘 remove → 线程归还池子 → 下次请求复用同一 ThreadLocalMap → 上次 value 还在。
- 永远不要在 static 变量中持有非 primitive / 不可变类型的
ThreadLocal值，除非你能 100% 控制其清理时机 - 考虑用
InheritableThreadLocal？不行——它加剧泄漏风险（子线程继承后更难统一清理） - 若必须长期持有上下文（如日志 MDC），优先选用框架方案（如 Logback 的
MDC.put()已内置remove()配合 filter 清理）
如何验证 ThreadLocal 是否已清理干净
不能只靠“没报错”或“功能正常”判断。得看运行时行为：
- 用
jstack <pid>查看线程栈，确认关键线程（如http-nio-8080-exec-）是否频繁执行到ThreadLocalMap.set或expungeStaleEntries - 用
jmap -histo:live <pid>统计ThreadLocalMap$Entry数量，对比多次 full GC 后是否下降；若稳定不降，大概率有残留 - 在
remove()后加日志（如log.debug("Cleared context for thread {}", Thread.currentThread().getName());），观察是否每请求都触发 - 单元测试中可反射访问
Thread.currentThread().threadLocals（注意 JDK 版本兼容性），断言 size 归零
最麻烦的地方在于：泄漏往往只在高并发、长时间运行后才暴露，而代码看起来“逻辑完整”。所以清理动作必须变成肌肉记忆，而不是等出事再补。
