线程池队列选错是java堆内存oom高频诱因，关键在于误用逻辑有界、实际无界的队列（如默认容量integer.max_value的linkedblockingqueue），导致任务积压、对象长期存活、gc失效；应按cpu/io密集型匹配synchronousqueue或有界linkedblockingqueue，禁用priorityblockingqueue，并配置监控告警与堆转储。
线程池队列选错，是 Java 堆内存 OOM 的高频诱因。问题不在“用了队列”，而在用了**逻辑有界、实际无界的队列**——比如 new LinkedBlockingQueue()，它默认容量是 Integer.MAX_VALUE，等同于无界。任务一压就堆满，对象长期存活，GC 回收不了，内存直接撑爆。
识别危险队列：哪些写法要立刻改
以下配置看似合理，实则埋雷：
-
new ThreadPoolExecutor(2, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue())—— 默认无界，任务积压即OOM -
Executors.newCachedThreadPool()—— 底层用的是无界SynchronousQueue+ 最大线程数Integer.MAX_VALUE，等于把线程创建权完全交给流量 - 没配拒绝策略，或用了
AbortPolicy却没接告警——任务失败静默丢弃，掩盖了积压事实
选对队列：按业务类型匹配
队列不是越大越好，而是要让系统在压力下“有反应”：
-
CPU 密集型任务（如计算、编码、加解密）：用
SynchronousQueue。它不缓存任务，新任务来时必须有空闲线程，否则立即触发拒绝策略，避免盲目堆积 -
IO 密集型任务（如 HTTP 调用、DB 查询、Redis 访问）：用有界
LinkedBlockingQueue，容量建议 50～200（视响应延迟和吞吐目标定），并搭配CallerRunsPolicy或AbortPolicy + 监控告警 - 绝对不用
PriorityBlockingQueue做通用任务队列——它无界且排序开销大，容易掩盖调度问题
上线前必做三件事
光改代码不够，得让问题可发现、可追溯、可验证：
- JVM 启动加参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，OOM 时自动生成堆快照 - 在监控系统里打点：
executor.getActiveCount()和executor.getQueue().size()，持续观察是否单边上涨 - 定期用 Eclipse MAT 打开 dump 文件，看 “Leak Suspects Report” —— 若大量
Runnable或业务对象被LinkedBlockingQueue$Node持有，就是队列背锅
配置不是调数字，而是建反馈闭环
线程池不是静态参数，而是业务水位的晴雨表：
- 队列满 70% 就触发告警，不是等 100% 才介入
- 拒绝策略执行次数每分钟 > 5 次，说明当前容量已无法承接流量，需扩容或限流
- 核心线程数别硬套 “CPU 核数 × 2”，IO 密集型可设为
2 × CPU 核数 + 10，但必须配合有界队列兜底
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
