ThreadLocal内存泄漏源于线程长期存活且ThreadLocalMap中value强引用未释放，核心是key弱引用可被回收而value强引用持续存在，尤其在线程池中易发。
ThreadLocal 内存泄漏不是“对象没被回收”这么简单，而是线程长期存活 + ThreadLocalMap 中 value 强引用未释放共同导致的。最典型场景是线程池中复用线程却忘记清理 ThreadLocal 数据。
内存泄漏是怎么产生的
核心在于 ThreadLocalMap 的设计机制：
- Key 是弱引用：Entry 的 key（即 ThreadLocal 实例）是 WeakReference，当外部不再持有该 ThreadLocal 的强引用时（比如局部变量方法结束、static 引用被置 null），GC 会回收 key，Entry.key 变为 null
- Value 是强引用：Entry.value 指向你存进去的对象（如 User、byte[]、SimpleDateFormat），这个引用链完整存在：Thread → ThreadLocalMap → Entry → value
- 线程不死，value 就不释放：尤其在线程池中，线程长期存活，即使 key=null，value 仍被强引用着，无法 GC —— 这就是泄漏的根源
- 清理不主动，过期 Entry 积压：ThreadLocalMap 只在 set/get/remove 时顺带扫描并清理 key=null 的 Entry（expungeStaleEntries），若线程后续不再调用这些方法，无效条目就一直卡在 map 里
怎么排查内存泄漏
重点看三类线索，结合工具定位：
- 堆内存持续增长 + OOM 前频繁 Full GC：用 jstat -gc 或 Prometheus + Grafana 观察老年代使用率缓慢上升
- 线程池线程持有大量大对象：用 jstack 查看线程状态，再用 jmap -histo:live 或 MAT 分析堆快照，筛选出被 ThreadLocalMap.value 引用的大对象（如 byte[]、String、自定义 DTO）
-
ThreadLocalMap 中存在大量 key=null 的 Entry：在 MAT 中打开 Dominator Tree，搜索
java.lang.ThreadLocal$ThreadLocalMap$Entry，查看其 value 字段是否指向业务对象，且 key 为 null -
代码审计关键点：全局搜索
ThreadLocal.set(、threadLocal.get(，检查是否配套remove()；特别关注 Filter、Interceptor、AOP、Runnable/Callable 提交处
怎么正确解决和预防
不是“加个 remove 就完事”，而要分层落地：
立即学习“Java免费学习笔记（深入）”；
-
必须用 try-finally 保证 remove：哪怕只 get 一次，也要清理
try {<br> Object val = tl.get();<br> // 业务逻辑<br>} finally {<br> tl.remove(); // 不能省略<br>} -
静态 ThreadLocal 要 withInitial + 不可变：避免 static 引用导致类卸载失败；优先用
ThreadLocal.withInitial(() -> new XXX())，而非重写 initialValue() - 线程池任务结束前统一清理：若无法修改每个任务，可在包装 ExecutorService 时拦截 Runnable/Callable，在 run() 后强制 remove 所有已知 ThreadLocal
-
Web 场景绑定请求生命周期：Spring 用户可用
@RequestScope替代 ThreadLocal；Servlet 环境可在 Filter 的 finally 块中 clear 所有上下文 ThreadLocal - 监控兜底：通过 JVMTI 或字节码增强（如 ByteBuddy），对 ThreadLocal.set 注入埋点，统计未配对 remove 的调用栈，线上告警
常见误区提醒
别踩这些坑：
- 认为 “key 是弱引用就不会泄漏” —— 错，泄漏的是 value，不是 ThreadLocal 本身
- 只在 set 前 remove —— 错，get 后也可能持有引用，必须每次使用后清理
- 用 threadLocal = null 代替 remove() —— 无效，null 掉的是局部变量，ThreadLocalMap 里的 value 还在
- 依赖线程结束自动清理 —— 错，线程池线程永不结束，map 也不会销毁
