话说回来，

写在前面

Day10 讲完了线程池的基本原理。这篇文章解决两个更实际的问题：为什么大家都说不要用 Executors 的工厂方法，还有线程数到底该怎么设置——公式背了很多，但真正落到一个具体业务场景里该怎么算，很多人还是没底。

一、为什么不推荐 Executors 的工厂方法

Executors 提供的几个静态方法看起来很省事。但每一个都藏着坑：

 // 有坑：newFixedThreadPool 底层用的是无界的 LinkedBlockingQueue
// 任务提交速度长期大于处理速度时队列会无限增长，最终导致 OOM
Executors.newFixedThreadPool;// 有坑：newCachedThreadPool 的 maximumPoolSize 是 Integer.MAX_VALUE
// 瞬时大量任务涌入时可能创建极其很多线程，把程序资源耗尽
Executors.newCachedThreadPool;// 有坑：newSingleThreadExecutor 和 FixedThreadPool 一样用无界队列
Executors.newSingleThreadExecutor;// 推荐：自己手动指定全部参数，显式控制队列大小和拒绝策略
new ThreadPoolExecutor(
/* corePoolSize */,/* maximumPoolSize */,/* keepAliveTime */,TimeUnit.SECONDS。new ArrayBlockingQueue,new ThreadFactoryBuilder.setNameFormat.build,new ThreadPoolExecutor.CallerRunsPolicy);

问题共性：这些工厂方法为了“用起来简单”，把关键参数设成几乎没有限制的值。表面省心，却把风险留给生产环境——无界队列会不断吃内存直到 OOM。无界线程数会不断开线程直到资源耗尽。这些问题在低流量时根本不会暴露，一旦触发往往是线上故障。

手动 new ThreadPoolExecutor 强迫你把每个参数都想清楚。特别是队列容量和拒绝策略——这两个恰恰是“出事故时最终一道防线”，不应该交给默认值去决定。

二、线程数设置：两个基础公式

线程数不是越多越好。也不是越少越稳，主要取决于任务是“耗 CPU”还是“耗等待”。

为什么两种任务公式差这么多？

• CPU 密集型任务几乎不会主动让出 CPU；怎么说呢，多余线程只能靠时间片轮转硬抢，只增加上下文切换开销。
• I/O 密集型任务大部分时间处于“傻等”。此期间 CPU 完全空闲，多开几个线程正好利用这些被浪费的空闲 CPU 时间。

三、业务场景复盘：典型的 “查库存” 接口

假设有一个查询库存接口。其处理流程为：

1. 本地简单校验参数
2. 调用下游仓储程序 HTTP 接口查真实库存
3. 组装返回结果

This is a classic I/O‑intensive task—most time spent waiting for downstream response.

假设机器有 N = 4 CPU 主要**：

等待时间 ≈ 80 ms
计算时间 ≈ 5 ms
建议线程数 ≈ N × = 4 × = 4 × 17 = **68**

算出来的是起点值，仅供参考**；它基于理想情况，没有考虑下游接口承载能力、机器内存、还有等待时间是否稳定等因素。

接下来应做：

S：*公式给出合理起点，用来避免盲目猜测；真正合适的线程数必须通过压测数据和线上监控指标校准，并结合下游依赖能否承受高并发进行封顶。

M 面试追问整理

• A. .newFixedThreadPool/.newSingleThreadExecutor: 用无界 LinkedBlockingQueue； 若提交速率长期> 执行速率，则队列无限增长 → OOM。
• B. .newCachedThreadPool: 最大线程数为 Integer.MAX_VALUE；突发高峰可能创建过多线程 → 程序资源被耗尽。话说回来，
• C. 在低流量测试中看不到问题。却在线上突发流量导致灾难性失效。
• D. 手动 .new ThreadPoolExecutor。明确控制关键参数，可把风险掌握在自己手里。
• E. 使用者痛点: “生产环境突然 OOM / 故障”通常因为默认工厂方法未考虑异常流量。
• S 小结: 为了可控性与安全性，请自定义配置而非默认工厂。

至于M2，CPU 密集型为何只需核数+1？不能更多吗，

• A. CPU 密集型任务几乎不主动让出 CPU；超过核数后多余线程只能靠 OS 时间片抢占，只带来上下文切换成本而无收益。按理说，
• B. 一个额外线程用于短暂 GC 或微小停顿。使主要始终保持活跃，而非因频繁切换造成延迟堆积。
• C. 使用者痛点: “看到高并发导致 CPU 饱和但吞吐未提高”，原因是超额线程没有意义且加重上下文切换负担。
• S 小结: 对于纯计算工作，只需核数+1 即可获得最优性能与资源平衡。说起来，

M3这方面。I/O 密集型为何能设比核数多得多？

• A. I/O 阻塞期间。CPU 空闲，可由其他活跃 I/O 任务占用，从而提高整体吞吐率。
• B. 等待/计算比例越高。可利用空闲 CPU 的数量就越大，从而需要更多并发执行器实例来覆盖等待周期。
• C. 使用者痛点: “I/O 高峰期出现明显卡顿”往往由于缺乏足够并发度以利用空闲 CPU 时间导致效率低下。-->

M4的观点是，为何公式算出的结果只是起点？不能直接上线，

• A. 理想模型忽略了下游服务瓶颈与实际网络抖动；实际等待时间波动会导致估算偏离很大。-->

M5这方面，为何要考虑下游服务能承受多少并发？