线程池参数：核心线程数、最大线程数、队列大小如何影响吞吐
说实话，调线程池参数是我过去踩坑最多的领域之一。早期我天真地以为“线程池嘛，调大点就完了”——结果不是 CPU 飙到 90 就是应用直接 OOM。后来才真正理解，这三个参数是连锁的，改一个就会牵动另外两个。
我们先从最基础的开始：线程池怎么工作的？说白了就是：有任务进来了，先看核心线程数，核心线程不够了进队列，队列满了再尝试扩容到最大线程数。如果最大也满了，就执行拒绝策略。
核心线程数 —— 线程池的“常备军”
核心线程数是你线程池里一直活着的线程数量（允许空闲超时回收除外）。我心里有个公式：对于 CPU 密集型任务，核心线程数 = CPU 核数 + 1；对于 IO 密集型任务，可以更大，比如 2 * CPU 核数。但这不是死规则，还要结合实际。
我曾经在一个日志处理项目里，把核心线程数设成了 64，机器才 8 核。结果是上下文切换的天，吞吐量反而只有合理配置时的 60%。后来我一步步压测，发现 16 个核心线程已经能跑满带宽了。嗯，核心线程数不是越大越好——更少的线程有时意味着更高的吞吐。
最大线程数 —— 线程池的“应急部队”
最大线程数决定了线程池最多能膨胀到多少。它和队列大小是搭档：队列满了，才会创建新线程到 max。我推荐把它设为 CPU 核数 * 2（IO 密集）或 CPU 核数 + 1（CPU 密集），但务必配合压测调整。
有一回我接手一个老系统，最大线程数设为 500，队列无限大。结果突发流量来了，队列撑爆内存，线程数激增到 500，CPU 飙到 100%，服务挂了。后来我把队列设为有界（比如 2000），最大线程数压到 80，吞吐反而提升了——因为不再无限制排队，系统避免了惊群效应。
队列大小 —— 线程池的“缓冲区”
队列长度直接影响任务的等待时间和资源消耗。常见分三种：
- 有界队列（ArrayBlockingQueue）：固定长度，队列满后触发扩容。适合对延时敏感的场景。
- 无界队列（LinkedBlockingQueue）：几乎无限长度，导致最大线程数几乎不会扩容。任务积压在内存里，风险大——我见过因此触发的 OOM。
- 同步移交队列（SynchronousQueue）：不存储任务，直接把任务交给新线程。适合高并发、短任务场景。
我个人习惯：生产环境不用无界队列。宁愿让任务失败（触发拒绝策略）也不能让 JVM 挂掉。比如用 ArrayBlockingQueue，队列大小按平均任务耗时 × 期望排队数估算，留 30% 余量。
| 参数 | 设太小 | 设太大 | 最佳实践 |
|---|---|---|---|
| 核心线程数 | CPU 利用率低，吞吐上不去 | 上下文切换严重，吞吐反而下降 | CPU 密集：N+1；IO 密集：2N+1 |
| 最大线程数 | 队列积压严重，响应变慢 | 线程爆炸，系统不稳定 | 压测定上限，不超过 100～200（视系统） |
| 队列大小 | 频繁触发扩缩容，线程震荡 | 内存溢出，GC 压力大 | 有界队列 + 当前系统可承受的积压上限 |
你想想看，这三个参数就像水龙头、水管和水池。核心线程数是水龙头常开大小，最大线程数是应急水量，队列长度就是水池容量。任何一个配错都会导致系统水漫金山或者断流。
// 一个示例配置（使用 ThreadPoolExecutor）
ThreadPoolExecutor executor = new ThreadPoolExecutor(
16, // 核心线程数
32, // 最大线程数
60L, TimeUnit.SECONDS, // 空闲线程存活时间
new ArrayBlockingQueue<Runnable>(2000), // 有界队列
new ThreadPoolExecutor.AbortPolicy()); // 满了就抛异常activeCount（当前活跃线程数）、queueSize（队列长度）、completedTaskCount（累积完成数）。如果 activeCount 长期接近 corePoolSize 且 queueSize 在增长，说明核心线程数不够，或者任务积压；如果 activeCount 频繁跳涨到 maxPoolSize 附近，说明队列太小或负载太猛。根据这些指标去回测调参，远比拍脑袋靠谱。
实践上我建议：先定队列大小（按业务可接受的最大排队时间估算），再定核心线程数（让 CPU 跑满但不过载），最后限制最大线程数（作为安全上限）。每次只改一个变量，对比压测报表。这样不会懵圈。
就说这么多。参数调优没有银弹，但理解了他们如何影响吞吐，你就有了方向。