IO密集型任务线程池配置核心是匹配真实阻塞比例，推荐公式为CPU核数×(1+wait_time/compute_time)，起步值设CPU×2～4，需结合压测、有界队列、合理maximumPoolSize及CallerRunsPolicy拒绝策略协同调优。
IO 密集型任务的线程池配置，核心是“用更多线程填满等待空窗”，而不是堆算力。关键不在于盲目加数，而在于让线程数匹配真实阻塞比例——任务发出去后等响应的时间越长，就越需要更多线程并行跑着，把 CPU 的闲置时间利用起来。
先估算合理线程数起点
别直接套“CPU×2”。更靠谱的做法是基于实测阻塞系数 D = wait_time / compute_time 计算：
- 比如一次数据库查询平均耗时 200ms，其中 180ms 在等网络和磁盘响应，只有 20ms 真正计算 → D ≈ 9 → 理论线程数 ≈ CPU 核数 × (1 + 9) = CPU×10
- 但这个值偏高，实际建议从 CPU×2～CPU×4 起步（例如 8 核机器设 corePoolSize=16～32）
- 压测时观察活跃线程数是否长期接近上限，再逐步上调，直到吞吐不再明显增长或上下文切换飙升（>5000 次/秒需警惕）
队列选有界、容量要算出来
LinkedBlockingQueue 默认无界，极易引发 OOM；必须用 ArrayBlockingQueue 或 SynchronousQueue，并控制容量：
- ArrayBlockingQueue 容量 ≈ 预期 TPS × 平均可接受排队时长（如目标 P99 延迟 500ms，TPS=200 → 队列≈100）
- 高波动流量可选 SynchronousQueue（容量为 0），靠动态扩容扛峰值，但 maximumPoolSize 必须设合理上限，否则线程爆炸
- 禁用无界队列——它会让拒绝策略失效，掩盖负载问题
配套参数不能松动
光调线程数没用，其他参数必须协同：
立即学习“Java免费学习笔记（深入）”；
- maximumPoolSize 设为 corePoolSize 的 1.5～2 倍（如 core=24，则 max=36～48），给突发留缓冲，但不超过全局线程上限（16 核服务器总线程建议 ≤128）
- keepAliveTime 设 60 秒左右，让临时扩容的线程在空闲后及时回收，避免长期占资源
- 拒绝策略必须用 CallerRunsPolicy：下游慢了、队列满了，就让调用方自己执行，天然限流，防雪崩
- 务必用自定义 ThreadFactory 给线程命名（如 “io-db-1”、“io-http-5”），出问题时一眼定位来源
必须监控、验证、联动
配置完不等于生效，上线后得盯住三件事：
- 监控活跃线程数曲线：是否频繁触顶？是否长期低于 corePoolSize（说明配多了）？
- 看队列积压量和拒绝任务数：持续积压说明队列小或线程少；拒绝突增说明下游瓶颈或流量超预期
- 和下游资源对齐：DB 连接池大小、HTTP 客户端最大连接数、第三方接口 QPS 限额，都要与线程池规模匹配，避免“池子大、管子细”
