「Java 进阶之路」系列 Day11
写在前面
Day10 讲完了线程池的基本原理，这篇解决两个更实际的问题：为什么大家都说不要用 Executors 的工厂方法，以及线程数到底该怎么设置------公式背了很多，但真正落到一个具体业务场景里该怎么算，很多人还是没底。
一、为什么不推荐 Executors 的工厂方法
Executors 提供的几个静态方法看起来很省事，但每一个都藏着坑：
java
// 有坑：newFixedThreadPool底层用的是无界的LinkedBlockingQueue
// 任务提交速度长期大于处理速度时，队列会无限增长，最终导致OOM
Executors.newFixedThreadPool(10);
// 有坑：newCachedThreadPool的maximumPoolSize是Integer.MAX_VALUE
// 瞬时大量任务涌入时可能创建极其大量的线程，把系统资源耗尽
Executors.newCachedThreadPool();
// 有坑：newSingleThreadExecutor和FixedThreadPool一样用无界队列
Executors.newSingleThreadExecutor();
// 推荐：自己手动指定全部参数，显式控制队列大小和拒绝策略
new ThreadPoolExecutor(
4, 8, 60, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(200),
new ThreadFactoryBuilder().setNameFormat("order-pool-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy()
);问题的共性：这几个工厂方法为了"用起来简单"，把队列容量或者最大线程数这类关键参数设成了几乎没有限制的值。表面上省心，代价是把风险留到了生产环境------一旦流量出现异常（比如下游变慢导致任务堆积、或者瞬时流量暴涨），无界队列会不断吃内存直到 OOM，无界线程数会不断开线程直到资源耗尽，而这些问题在日常测试、低流量时根本不会暴露，一旦触发往往是线上故障。
手动 new ThreadPoolExecutor(...) 强迫你把每个参数都想清楚，尤其是队列容量和拒绝策略------这两个恰恰是"出事故时最后一道防线"，不应该交给一个默认值去决定。
二、线程数设置：两个基础公式
线程数不是越多越好，也不是越少越稳，核心取决于任务是"耗 CPU"还是"耗等待"：
| 任务类型 | 推荐公式 | 原因 |
|---|---|---|
| CPU密集型（纯计算，几乎不等待） | 线程数等于CPU核数加1 | 多这一个线程用来应对偶发的短暂停顿，避免核心空转浪费 |
| IO密集型（大量时间在等网络、磁盘） | 线程数等于CPU核数乘以（1加上等待时间除以计算时间） | 线程在等IO的时候CPU是空闲的，可以让更多线程搭伙共用这些空闲的CPU时间 |
为什么两种任务的公式差这么多：CPU 密集型任务几乎不会主动让出 CPU，线程数一旦超过核数，多出来的线程只能靠时间片轮转硬抢，除了增加上下文切换开销没有任何好处；IO 密集型任务大部分时间线程都在"傻等"（等网络返回、等磁盘读写），这段时间 CPU 完全空闲，多开几个线程正好可以利用这些被浪费的空闲时间去处理别的任务，所以能开的线程数远超过 CPU 核数。
三、业务场景复盘：一个典型的"查库存"接口
假设有一个查询库存的接口，处理一次请求大概经历这几步：本地简单校验参数（耗时忽略不计）→ 调用下游仓储系统的 HTTP 接口查真实库存（平均耗时 80ms）→ 组装返回结果（几乎不耗时）。这是典型的 IO 密集型任务------绝大部分耗时都花在"等下游接口返回"上，而不是本地计算。
假设机器是 4 核，按公式估算：
等待时间约等于80ms（等下游接口）
计算时间约等于5ms（本地校验加组装结果）
线程数约等于4乘以（1加80除以5）等于4乘以17等于68算出来的 68 只是一个起点，不是可以直接照搬上线的最终答案，原因是这个公式假设的是理想情况，没考虑下游接口本身能不能撑住 68 路并发调用、机器内存能不能撑住这么多线程的栈空间、以及等待时间是不是稳定的（下游接口偶尔抖动到 500ms 怎么办）。
接下来该做的是压测和监控，而不是直接信公式的结果：
- 用压测工具模拟真实流量，观察在不同线程数下接口的响应时间和吞吐量曲线，找到那个"再加线程也不能提升吞吐、反而开始下降"的拐点
- 盯着线程池的队列水位------如果队列长期是空的，说明线程数可能设多了；如果队列长期堆积，说明处理能力跟不上，要么加线程要么优化下游
- 盯着下游依赖的承受能力------本地线程池能开很多线程，但下游服务如果扛不住这么大的并发，压力只是从"本机队列堆积"转移成了"下游接口超时/降级"，公式算出来的线程数还要结合下游能承受的并发上限做一次封顶
一句话总结：公式给的是一个合理的起点，用来避免"拍脑袋"式的瞎猜；真正合适的线程数，最终要靠压测数据和线上监控指标去校准，而且还要考虑下游依赖能不能扛住这么大的并发，不能只看本机这一侧的账。
四、面试追问
Q1：为什么不推荐直接用 Executors 的工厂方法创建线程池？
因为 newFixedThreadPool 和 newSingleThreadExecutor 底层用的是无界的 LinkedBlockingQueue，一旦任务提交速度长期大于处理速度，队列会无限膨胀直到内存溢出；newCachedThreadPool 的最大线程数是 Integer.MAX_VALUE，瞬时大量任务涌入时可能创建极其多的线程，耗尽系统资源。这些问题在低流量时不会暴露，往往是线上流量异常时才会引发故障，所以更推荐手动 new ThreadPoolExecutor 显式指定队列容量和拒绝策略，把这些关键参数掌握在自己手里。
Q2：CPU 密集型任务为什么线程数设置成核数加1就够了，不能更多吗？
因为 CPU 密集型任务几乎不会主动让出 CPU 去等待什么，线程数一旦超过核数，多出来的线程只能靠操作系统的时间片轮转去抢占 CPU，这只会增加上下文切换的开销，不会带来真正的并行收益。多出的那一个线程主要是用来应对任务偶尔短暂停顿（比如触发了一次GC）时不让CPU核心空闲，不是为了增加并发度。
Q3：IO 密集型任务为什么可以设置比 CPU 核数多得多的线程数？
因为 IO 密集型任务的大部分耗时都花在等待网络、磁盘等外部资源返回，这段等待期间线程虽然存在，但并不占用 CPU，CPU是空闲的。多开一些线程，可以让这些空闲的CPU时间被别的线程用来处理其他请求，从而提升整体吞吐量。等待时间相对计算时间的比例越高，能够有效利用的线程数也就越多，这就是公式里"等待时间除以计算时间"这一项的意义。
Q4：为什么说线程数公式算出来的结果只是一个起点，不能直接拿来用在生产环境？
因为公式是基于理想情况的估算，没有考虑下游依赖的真实承受能力、机器内存等资源限制，以及等待时间本身是否稳定（下游接口抖动会让实际情况和估算值偏离很大）。真正合适的线程数需要结合压测数据（不同线程数下的吞吐量和响应时间曲线）和线上监控指标（队列水位、下游超时率）去校准，公式只是避免从零瞎猜的一个合理起点。
Q5：设置线程池参数时，为什么还要考虑下游服务能承受的并发上限？
因为线程池本身能开多少线程，只反映了本机这一侧的处理能力，如果线程数设得很大、但下游依赖（比如数据库、其他微服务）根本扛不住这么高的并发，压力并不会消失，只是从"本机线程池队列堆积"转移成了"下游服务超时或者被打垮"，可能引发更大范围的连锁故障。所以线程数不能只按本机资源去算，还要结合下游能承受的并发上限做封顶。
下一篇预告
Day12 讲 ScheduledThreadPoolExecutor 怎么实现延迟和周期性任务调度，以及 FutureTask 的状态机原理，顺带认识一下更适合异步编排的 CompletableFuture。