ThreadLocal未清理隐患需从线程复用、对象残留、堆内存结构三方面主动识别：堆中大量key为null但value强引用大对象的“幽灵条目”，长期存活线程（如Tomcat exec线程、ForkJoinPool）执行路径中set后未remove，配合jmap/jstack/MAT及GC日志综合验证。
发现 ThreadLocal 未清理导致的隐患，关键不是等 OOM 才动手，而是从线程复用特征、对象残留痕迹和堆内存结构三方面主动识别。
看堆里有没有“幽灵条目”
ThreadLocal 泄漏最典型的堆内表现是：大量 ThreadLocalMap$Entry 对象中 key == null，但 value 指向大对象（比如 byte[]、UserContext、TraceId、ProtocolContext 等）。这些 Entry 已无法通过 ThreadLocal 访问，却因强引用卡在内存里，就是“幽灵条目”。
- 用
jmap -histo:live查看是否异常多的Entry或你业务中的上下文类（如com.xxx.Context）实例 - 用
jmap -dump:format=b,file=heap.hprof抓快照，用 MAT 打开后运行 Leak Suspects Report，重点关注 “ThreadLocalMap → Entry → value” 链路 - 在 MAT 的 Dominator Tree 中筛选
java.lang.Thread，展开每个线程的threadLocals字段，检查其table数组里是否有大量 key 为 null 的项
盯住长期存活的线程
短期线程泄漏不明显；真正危险的是被反复调度、持续运行数小时甚至数天的线程——比如 Tomcat 的 http-nio-8080-exec-*、Spring Boot 默认的 ForkJoinPool.commonPool、或自定义线程池的核心线程。
- 用
jstack观察线程名和java.lang.Thread.State，确认哪些线程处于RUNNABLE或WAITING且已运行很久 - 结合应用日志或 Micrometer + Prometheus 监控，看某线程是否连续处理了数百/数千个请求却未重启
- 重点审查这些线程执行过的代码路径：Filter、Interceptor、AOP 切面、
Runnable/Callable提交点——这些地方 set 了 ThreadLocal，但 return 前没 remove
加诊断日志快速验证
别靠猜，动手验证是否真因未 remove 导致堆积。
- 在疑似位置加一行日志：
Object val = threadLocal.get(); if (val != null) { log.warn("ThreadLocal value still present before set: {}", val.getClass().getSimpleName()); }
如果高频打印，说明前一次任务结束时没清理，当前又覆盖写入，旧值已泄漏 - 在线程池场景下，可临时重写
ThreadPoolExecutor.afterExecute()，统一检查threadLocal.get() != null，快速定位漏删位置 - 对 Lambda 场景，搜索所有含
.set(且紧邻->或lambda$的代码行，人工核对是否每处都有对应.remove()或封装在 try-finally 中
查 GC 日志与内存曲线形态
确认是不是真泄漏，而不是正常晋升：
- 观察监控曲线：若堆内存平滑上升、GC 后不回落，且老年代（Old Gen）持续膨胀（比如从 1.2G 涨到 2.8G），而 Young GC 频率不变但每次存活对象比例变高，就高度可疑
- 检查 GC 日志：没有频繁 Full GC，但
OldGen使用率单向爬升，说明有对象进了老年代就再没被回收过 - 配合 JVM 参数
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/，提前捕获 dump，避免等到崩溃才分析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
