Executors.newFixedThreadPool() 易OOM是因为其使用无界LinkedBlockingQueue，任务持续提交而消费滞后时队列无限膨胀，堆内存被占满；newCachedThreadPool() 更危险，会因SynchronousQueue+无限线程数导致栈内存溢出。
为什么 Executors.newFixedThreadPool() 容易 OOM
它用的是无界队列 LinkedBlockingQueue，任务持续提交但消费跟不上时，队列无限膨胀，堆内存直接打满。不是线程数爆了，是待执行任务堆满了。
- 默认构造的
LinkedBlockingQueue容量是Integer.MAX_VALUE，等于没设上限 - 常见于定时任务、消息监听等“生产快、处理慢”的场景，比如下游接口响应变慢几秒，几十万任务就卡在队列里
-
newCachedThreadPool()更危险：核心线程数 0、最大线程数Integer.MAX_VALUE，加上SynchronousQueue（不存任务），一有并发就疯狂创建线程，栈内存撑爆
替代方案：用 ThreadPoolExecutor 手动构造，控制三个关键参数
必须显式指定核心线程数、最大线程数、队列容量，才能真正兜住风险。JDK 的 Executors 工厂方法只是语法糖，掩盖了底层可控性。
- 队列优先选
ArrayBlockingQueue，容量必须设具体值，比如new ArrayBlockingQueue(1024) - 拒绝策略别用默认的
AbortPolicy（抛RejectedExecutionException），线上建议CallerRunsPolicy：让调用线程自己执行，自然限流 - 线程工厂建议命名，比如
new ThreadFactoryBuilder().setNameFormat("biz-pool-%d").build()，方便排查线程归属
Executors.newSingleThreadExecutor() 的隐藏问题
它返回的是包装过的 FinalizableDelegatedExecutorService，无法转型为 ThreadPoolExecutor，所以你没法调用 getPoolSize()、getQueue().size() 等监控方法，也关不掉内部线程池的 shutdown hook。
- 一旦传入的
Runnable抛未捕获异常，这个单线程就死了，后续任务全卡住，且无日志提示 - 它底层用的仍是无界
LinkedBlockingQueue，同样存在堆积风险 - 真要单线程，不如直接 new
ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(128))
线程池配置没有银弹，得看任务类型
CPU 密集型和 IO 密集型任务的线程数设置逻辑完全不同，套用固定公式反而坏事。
立即学习“Java免费学习笔记（深入）”；
- 纯计算任务（如加解密、图像处理）：线程数 ≈ CPU 核数，多开只会增加上下文切换开销
- IO 密集型（如 HTTP 调用、DB 查询）：线程数可设为
CPU 核数 × (1 + 平均等待时间 / 平均工作时间)，但更稳妥的是压测后定值 - 混合型任务（比如先查 DB 再算数据）：按实际瓶颈拆成两个池子，别混用
线程池不是越“大”越好，是越“准”越稳。很多人调参只盯着线程数，却忘了队列长度、拒绝策略、线程存活时间这些真正决定稳定性的开关。
