核心线程数与队列大小需协同设计：CPU密集型任务推荐core=CPU核数，I/O密集型可用Ncpu/(1−阻塞系数)估算；队列宜选有界类型，避免无界导致OOM；最终须通过压测与监控验证调优。
核心线程数和队列大小不是孤立参数，它们必须协同设计——线程数决定“谁干活”，队列大小决定“活等多久”。设得过大或过小，都会引发任务堆积、线程争抢、拒绝频繁或资源浪费。
先看任务类型，再定核心线程数
核心线程数本质是常驻并发能力，要贴合任务对 CPU 的实际占用模式：
-
CPU 密集型任务（如图像缩放、JSON 解析、复杂算法）：线程几乎不阻塞，过多线程只会加剧上下文切换。推荐
corePoolSize = Runtime.getRuntime().availableProcessors()或+1（弥补偶尔缺页或锁等待）。 -
I/O 密集型任务（如 HTTP 调用、DB 查询、文件读写）：线程大量时间在等待，CPU 空闲。可设为
2 × Ncpu起步；若已知阻塞系数（例如 80% 时间在等响应），可用公式Ncpu / (1 − 阻塞系数)估算，比如 4 核 + 阻塞系数 0.9 → 约 40 个核心线程。 -
混合型任务：取中间值，常见做法是
1.5 × Ncpu到2 × Ncpu，后续靠压测微调。
队列大小不能凭感觉，要看调度意图
队列不是“缓冲区越大越好”，它决定了线程池是倾向“扩线程”还是“堆任务”：
-
想优先复用线程、控制资源总量：选小容量有界队列（如
ArrayBlockingQueue(100)）。任务积满后触发扩容，适合 I/O 型突发流量，避免内存被长任务队列吃光。 -
想平滑吞吐、容忍短时延迟：选中等容量队列（如
LinkedBlockingQueue(1000)）。适合 CPU 型稳定负载，让核心线程持续工作，减少创建/销毁开销。 -
想零排队、即交即执行（或即拒）：用
SynchronousQueue。它不存任务，提交即尝试交给空闲线程；若无空闲，则直接走扩容逻辑。适合高实时性场景，但要求maximumPoolSize设置合理，否则极易触发拒绝。
注意：别用无界队列（如未指定容量的 LinkedBlockingQueue），一旦下游变慢，任务会无限堆积，最终 OOM。
立即学习“Java免费学习笔记（深入）”；
核心数与队列要互相制衡
二者搭配不当，会导致行为失真：
- 核心线程数很小（如 2）、队列却很大（如 10000）→ 大部分任务永远等在队列里，线程池形同虚设，响应延迟不可控。
- 核心线程数很大（如 50）、队列又极小（如 10）→ 一有波动就疯狂扩容，线程数飙升，上下文切换拖垮性能。
- 理想配比参考：CPU 型任务常用
core=4, queue=200；I/O 型任务常用core=16, queue=50或core=8, queue=0（SynchronousQueue）。
最后一步：验证与收敛
公式只是起点，真实效果必须靠数据说话：
- 用压测工具（如 JMeter）模拟峰值 TPS，观察平均响应时间、队列积压量、线程活跃数、拒绝率；
- 监控运行时指标：JVM 线程数、GC 频率、CPU 使用率、队列 size（可通过
ThreadPoolExecutor.getQueue().size()暴露）； - 调整策略：若队列长期 >70% 满且响应变慢 → 加核心线程或减队列；若线程数频繁触达
maximumPoolSize且 CPU 高 → 减最大线程或换更高效实现。
不复杂但容易忽略。
