核心线程未释放会导致内存泄漏，因其长期持有ThreadLocal、静态缓存等对象引用，使关联堆内对象无法回收；需通过jstack定位异常业务线程、jmap/MAT分析ThreadLocalMap及GC Roots验证。
线程池核心线程未释放为何会导致内存泄漏
Java 线程池中，核心线程（corePoolSize）默认不会超时销毁，即使长期空闲也持续存活。若这些线程持有业务对象引用（如 ThreadLocal、静态缓存、监听器、大对象闭包等），而线程本身不终止，其所关联的栈帧、本地变量、ThreadLocalMap 就无法被回收——这会间接“钉住”大量堆内对象，造成内存持续增长。
关键线索：识别异常存活的核心线程
不是所有活跃线程都危险，需聚焦“本该空闲却长期持占资源”的线程。可通过以下方式定位：
- 用 jstack
获取线程转储，筛选出状态为 TIMED_WAITING 且堆栈含 java.util.concurrent.ThreadPoolExecutor$Worker.run的线程，再检查其是否卡在getTask()中等待任务——这是正常空闲态；但若堆栈显示它正执行业务逻辑（如MyService.process()）且长时间未退出，则需警惕 - 重点关注线程名含
pool-1-thread-、taskExecutor-等自定义命名前缀的线程，结合代码确认其是否应属于核心线程 - 检查线程是否持有非 transient 的 ThreadLocal 对象：在 jstack 输出中搜索
ThreadLocalMap或查看堆转储中java.lang.Thread实例的threadLocals字段引用链
ThreadLocal 是最隐蔽的“线程钉子”
线程池复用机制下，ThreadLocal 若未显式 remove()，其 value 会随线程生命周期长期驻留。尤其当 value 是大对象（如 byte[]、List
- 典型错误模式：
private static final ThreadLocal但从未调用sdf = new ThreadLocal(); sdf.remove() - 验证方法：用 jmap -histo
查看 java.lang.ThreadLocal$ThreadLocalMap$Entry实例数是否异常偏高；再用 MAT 打开 heap dump，按 GC Root 追溯其 value 引用的对象类型 - 修复原则：每次使用后必须
try-finally { ... } finally { tl.remove(); }，或改用withInitial()+ 不可变对象
排查与验证步骤闭环
不要只看线程状态，要联动堆内存证据：
- 第一步：用 jstat -gc
观察 Old Gen 使用率是否阶梯式上升，且 Full GC 后回落极少 → 确认内存泄漏存在 - 第二步：用 jmap -dump:format=b,file=heap.hprof
生成堆快照，用 Eclipse MAT 打开 → 查看 “Leak Suspects Report” - 第三步：在 MAT 的 “Dominator Tree” 中，筛选出由
java.lang.Thread直接/间接支配的大对象，右键 → “Path to GC Roots” → 勾选 “exclude weak/soft references”，观察是否经由threadLocals或静态容器指向业务类 - 第四步：回查代码，确认线程池创建处是否设置了
allowCoreThreadTimeOut(true)（仅适用于需动态收缩的场景），并检查所有提交的任务是否在 finally 块中清理了 ThreadLocal 和临时缓存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
