Java线程池本身不导致内存泄漏，但任务中ThreadLocal未remove、监听器未注销、静态集合误存对象、资源未关闭等会导致内存泄漏。关键在任务结束后未清理资源，使对象无法回收。
Java 线程池任务未结束本身不会直接导致内存泄漏，但任务执行中不当持有对象引用 + 线程长期复用，会构成典型的内存泄漏温床。关键不在“任务没结束”，而在于任务结束后资源没清理、线程没释放上下文、ThreadLocal 没 remove、大对象被意外滞留。
下面从几个高发场景讲清楚逻辑和表现：
ThreadLocal 未清理是线程池内存泄漏的头号原因
线程池中的线程生命周期远长于单个任务。如果任务里用了 ThreadLocal 存用户信息、事务上下文、缓存数据等，但没在任务结束前调用 remove()：
-
ThreadLocal实例可能已被 GC（key 变 null），但 value 仍是强引用 - 该 value（比如一个 5MB 的
byte[]或 DTO）就卡在ThreadLocalMap里出不去 - 同一线程反复执行新任务 → 多个已失效 Entry 积累 → 堆内存缓慢上涨 → Full GC 后仍不回落
✅ 正确做法：必须配合
try-finally或 AOP 统一兜底立即学习“Java免费学习笔记（深入）”；
try { threadLocal.set(largeObject); doBusiness(); } finally { threadLocal.remove(); // 关键！不能省 }
任务中注册了全局监听器或回调但未注销
比如在任务里向 EventBus、Spring ApplicationEventPublisher、Netty ChannelPipeline 添加监听器，或注册定时任务（ScheduledExecutorService.scheduleAtFixedRate），却没在任务退出时反注册：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 监听器对象通常隐式持有当前任务对象或外部类引用
- 线程池线程持续存活 → 监听器一直被强引用 → 整个闭包链上的对象无法回收
⚠️ 尤其注意 Lambda 表达式捕获局部变量或
this的情况，容易形成隐藏强引用。
静态集合误存任务临时对象
任务中把请求参数、结果、日志上下文塞进静态 Map / List（例如用于调试或统计），但忘了清理：
- 静态容器生命周期 = JVM，对象一旦进去就几乎不会被回收
- 单次请求存 1KB，每秒 1000 请求 → 1 秒就涨 1MB，几小时 OOM
✅ 替代方案：用
WeakHashMap（key 弱引用）、带过期策略的Caffeine缓存，或严格限定作用域+手动清除。
未关闭的流、连接、资源在任务中被打开
虽然这不算“线程池特有”，但在复用线程场景下危害放大：
- 一个任务打开了
InputStream、ResultSet或ZipFile，异常跳过close() - 下一个任务复用同一线程 → 文件句柄/连接数耗尽 + 对应 buffer 对象滞留堆中
- 表现为
OutOfMemoryError: unable to create new native thread或IOException: Too many open files
✅ 必须用
try-with-resources，避免依赖finalize()或线程终止来释放。
本质上，线程池只是把“短命线程”换成了“长命线程”，把本该随线程消亡而自动清理的资源，变成了需要显式、及时、可靠释放的对象。任务没结束不是问题，任务结束了还赖着不走，才是泄漏的起点。
