线程池配置不当是导致Java堆内存OOM的常见原因，尤其当使用无界队列（如new LinkedBlockingQueue()）或newCachedThreadPool时，任务积压、对象长期存活引发GC失效。
看到 java.lang.OutOfMemoryError: Java heap space 就该怀疑线程池？
不是所有堆内存 OOM 都是线程池惹的祸，但只要日志里频繁出现 ExecutorService 相关类（比如 ThreadPoolExecutor、LinkedBlockingQueue）在堆栈中，或者监控显示活跃线程数持续上涨、队列积压任务暴涨，那线程池就是头号嫌疑人。根本原因往往不是“用了线程池”，而是它被当成无底洞来用：任务疯狂塞进无界队列，线程无限创建，拒绝策略形同虚设。
new LinkedBlockingQueue() 是最隐蔽的内存炸弹
这个默认构造函数创建的是容量为 Integer.MAX_VALUE 的“逻辑有界、实际无界”队列——任务来了就往里塞，GC 回收不了还在排队的对象，堆内存直接被撑爆。尤其在 IO 密集型业务（如 HTTP 调用、DB 查询）中，响应慢 → 任务堆积 → 队列膨胀 → OOM，一气呵成。
- 错误写法：
new ThreadPoolExecutor(2, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue()) - 正确做法：明确限制容量，例如
new LinkedBlockingQueue(200)，并配合理拒策略 - 更优选择：CPU 密集型任务直接用
SynchronousQueue，它不存储任务，迫使线程池立即扩容或触发拒绝策略，反而更安全
怎么确认是线程池导致的 OOM？三步现场抓证据
别等服务挂了才查。在 JVM 启动参数里加好诊断开关，出问题时立刻能定位：
- 加参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，OOM 时自动生成.hprof文件 - 运行中采样：
executor.getActiveCount()和executor.getQueue().size()打点到监控系统，看是否持续增长 - 分析 dump：
Eclipse MAT打开后点 “Leak Suspects Report”，如果发现大量Runnable或业务对象被LinkedBlockingQueue$Node持有，基本坐实
线程池配置不是调数字，而是匹配业务特征
盲目套用“核心线程数 = CPU 核心数 × 2”会翻车。关键看任务类型和资源瓶颈：
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型（如图像压缩、复杂计算）：线程数过多只会加剧上下文切换，建议
Runtime.getRuntime().availableProcessors() + 1，队列用SynchronousQueue - IO 密集型（如 Redis 调用、文件读写）：线程可稍多，但必须配
有界队列 + AbortPolicy并接告警，否则失败任务无声堆积 - 千万别用
Executors.newCachedThreadPool()上生产——它底层用的就是无界SynchronousQueue，最大线程数Integer.MAX_VALUE，等于把线程创建权完全交给请求流量
线程池本身不泄漏内存，但它像一根导火索：配置松懈 → 任务滞留 → 对象长期存活 → GC 失效 → 堆满。真正难排查的，往往是那个忘了清理的静态缓存，正安静躺在队列节点里，等着被 MAT 的支配树揪出来。
