线程池大小的估算与验证
线程池大小由任务的计算时间、等待时间、到达速率、内存占用和下游容量共同决定。“CPU 核数加一”只能作为实验起点，不能直接成为生产配置。
1. 先区分计算与等待
CPU 密集任务持续占用核心，线程数接近可用核心数时通常已经接近吞吐上限。增加更多平台线程主要带来调度和缓存成本。
阻塞 I/O 任务在等待期间不使用 CPU，可以容纳更多并发。一个常见估算是：
线程数 ≈ CPU 核数 × 目标利用率 × (1 + 等待时间 / 计算时间)
它依赖稳定的平均值；真实请求有长尾、混合任务和外部限流，所以只能给出压测区间。
2. Little 定律可以检查并发量级
稳定系统中，平均在途任务数约等于吞吐乘以平均响应时间：
并发量 ≈ 每秒完成数 × 平均耗时（秒）
目标 1,000 TPS、平均占用 50 ms 时，平均约有 50 个任务在途。若 p99 为 2 秒，突发下所需容量和队列风险会完全不同，因此还要看分布而非只看平均。
3. 最小的下游上限决定有效并发
线程池有 200 个 Worker，而数据库连接池只有 30 个连接，多出的线程大多只是在等连接。继续扩线程会增加内存和调度，不能提升数据库吞吐。
需要列出每项限制：
- CPU 配额和容器可见核心数。
- 数据库、HTTP 与文件句柄上限。
- 单任务栈、缓冲区和堆对象。
- 对端 QPS、并发和超时预算。
- 同实例上其他执行器的总线程数。
4. 用饱和曲线确定配置
压测至少逐步调整线程数，并记录：
- 吞吐、平均与 p95/p99 延迟。
- active、pool size、queue size、最老任务年龄和拒绝。
- CPU 利用率、上下文切换、GC 与分配率。
- 数据库连接等待和下游错误率。
当线程继续增加而吞吐不再上升、长尾和切换开始变差时，已经越过有效区间。配置应留出故障和流量波动余量，而不是卡在单次测试峰值。
5. 动态调整也需要安全边界
根据队列或延迟自动扩缩容时，要设置最小、最大、冷却时间和下游硬上限。队列增长可能来自下游变慢，此时扩大并发会造成正反馈。
线程池参数只是实例内控制。水平扩容还会增加整个集群打向数据库或第三方接口的总并发，需要统一容量预算。
6. 常见问题
6.1 I/O 密集任务直接设置为 2 × CPU 可以吗
只能当缺少数据时的起点。等待/计算比可能远大于或小于 1，真正上限也可能来自连接池或对端限流。
6.2 CPU 使用率低是否说明线程太少
不一定。线程可能在等锁、连接、磁盘或远程服务。先用栈、JFR 和池指标确认等待目标，再调整并发。
7. 面试题
7.1 怎样为一个 I/O 密集任务配置线程池大小
出现公司：美团、滴滴
考察重点
- 等待/计算时间与 Little 定律。
- 下游容量和内存边界。
- 通过压测寻找饱和点。
相关内容：第 1 节“先区分计算与等待”至第 4 节“用饱和曲线确定配置”。
参考回答
先测任务计算时间、等待时间和目标吞吐，用核心数乘目标利用率和 1 + W/C 得到实验区间，也可以用 Little 定律检查目标吞吐对应的在途量。然后取数据库连接、对端并发、内存等约束中的更小上限。
逐步增加线程压测吞吐与 p99，同时看队列、拒绝、CPU、切换和下游等待。吞吐停止增长而长尾变差的位置说明继续加线程无效，最终配置还要留出波动余量。