线程池任务堆积本身不是内存泄漏，但会导致堆内存持续增长、GC失效并最终触发OutOfMemoryError；根源是任务对象无法及时消费释放，尤其持有业务对象引用时构成事实内存泄漏。
线程池任务堆积本身不是内存泄漏，但会引发堆内存持续增长、GC失效、最终触发 OutOfMemoryError。问题根源在于“任务对象无法被及时消费和释放”，导致大量待执行的 Runnable 或 Callable 实例长期驻留堆中——尤其当它们持有业务对象引用时，就构成了事实上的内存泄漏。
明确队列边界，禁用无界队列
使用 LinkedBlockingQueue 默认构造函数（即无界队列）是最大风险点。其容量为 Integer.MAX_VALUE，任务持续涌入后，队列无限膨胀，直接吃光堆内存。
- 改用显式容量的有界队列，例如
new LinkedBlockingQueue(200) - 配合拒绝策略，避免任务“无声丢失”或线程失控：推荐
CallerRunsPolicy（调用线程自己执行）或自定义策略记录告警 - 避免使用
Executors.newFixedThreadPool(n)和newCachedThreadPool()，它们底层都隐含无界或弹性过大的队列/线程模型
控制线程创建规模，防止栈内存耗尽
每个线程默认占用约 1MB 栈空间。若线程池无上限地创建新线程（如 newCachedThreadPool 在高并发下），短时间内可能耗尽整个 JVM 内存，甚至触发 OS 级 OOM Killer。
- 一律使用
ThreadPoolExecutor显式构造，严格限定corePoolSize和maximumPoolSize - CPU 密集型任务：线程数 ≈ CPU 核心数 + 1
- IO 密集型任务：可设为 2–4 倍核心数，但必须搭配有界队列，不能靠“多开线程”掩盖处理瓶颈
监控关键指标，及时发现堆积苗头
仅靠“不报错”不代表健康。需主动采集并告警以下运行态指标：
立即学习“Java免费学习笔记（深入）”；
- 队列大小：持续 > 队列容量 50% 就说明消费跟不上生产，需排查下游慢、锁竞争或任务逻辑阻塞
-
活跃线程数：接近
maximumPoolSize表示线程已拉满，系统吞吐已达瓶颈 - 已完成任务数 vs 提交任务数：差值持续扩大 = 积压加剧，可结合 Prometheus + Micrometer 暴露为监控指标
清理任务中的强引用，避免间接泄漏
任务对象自身可能持有大对象（如 byte[]、List、DTO）、未关闭资源（InputStream）、或注册了监听器。即使任务执行完，若这些引用未被显式置空或释放，GC 仍无法回收。
- 在
Runnable.run()或Callable.call()结束前，手动清空大字段、关闭流、注销回调 - 避免在任务中使用匿名内部类捕获外部大对象；改用局部变量 + 显式传参
- 慎用
ThreadLocal：若在线程池中复用线程，务必在任务结束时调用remove()，否则上一个请求的数据会污染下一个
