java线程池资源泄漏本质是未关闭线程池导致gc roots持续可达、threadlocal累积及强引用对象图滞留；必须通过显式shutdown、awaittermination+shutdownnow兜底、threadlocal配对remove、autocloseable或spring生命周期统一管理实现全链路防御。
Java线程池资源泄漏不是“偶尔发生”的小问题，而是由未终止的线程、未清理的ThreadLocal、强引用的对象图共同导致的系统级隐患。真正有效的预防，不靠事后排查，而在于从创建、使用到关闭的全链路防御设计。
线程池必须显式关闭，不能依赖JVM自动回收
ThreadPoolExecutor默认创建的是非守护线程（non-daemon thread），只要线程存活，JVM就不会退出。即使应用上下文已销毁，残留线程仍会持有外部类引用、缓存对象、数据库连接等，造成内存持续占用。
- 临时线程池（如工具方法中创建）必须在作用域结束前调用
shutdown() - 全局或长生命周期线程池（如Spring Bean）应通过容器生命周期管理，配置
destroyMethod = "shutdown" - 绝对避免静态变量持有未托管的
ExecutorService，除非有统一、可靠的关闭入口
关闭流程要完整：shutdown + awaitTermination + shutdownNow兜底
仅调用shutdown()只是“发通知”，不代表线程池已终止；不等待就退出主线程，会导致工作线程后台静默运行，任务丢失、资源悬空。
- 先调用
executor.shutdown()，拒绝新任务，允许队列中任务完成 - 紧接着用
awaitTermination(timeout, unit)等待合理时长（如30秒），确认是否真正终止 - 超时后调用
shutdownNow()尝试中断运行中任务，并再次awaitTermination（如5秒）确认状态 - 捕获
InterruptedException后需恢复中断状态：Thread.currentThread().interrupt()
ThreadLocal是线程池场景下的隐形泄漏源
线程复用意味着ThreadLocal变量不会随任务结束自动清除。若任务中设置了ThreadLocal<connection></connection>或ThreadLocal<usercontext></usercontext>却未remove()，该引用将长期滞留在线程的ThreadLocalMap中，拖垮整个对象图。
- 所有
set()操作后，必须配对remove()，尤其在finally块中执行 - 避免在任务中存储大对象（如缓存Map、DTO集合）到ThreadLocal
- 可考虑用
InheritableThreadLocal替代时更需谨慎，它会跨线程传递引用
用AutoCloseable封装或Spring生命周期接管关闭逻辑
人工编码易遗漏异常路径下的关闭调用。更可靠的方式是让资源管理机制本身承担责任。
- 自定义线程池包装类实现
AutoCloseable，close()方法内封装完整关闭流程 - 配合
try-with-resources语法，确保无论是否异常都会触发关闭 - 在Spring Boot中声明为
@Bean(destroyMethod = "shutdown")，交由ApplicationContext统一管理 - 避免在Runnable/Callable内部持有线程池引用，防止闭包延长其生命周期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
