别信CPU+1/IO×2了：用排队论把线程池调优算明白

在 Java 服务端开发中，线程池几乎无处不在。

异步任务、接口聚合、批量处理、消息消费、第三方 RPC...只要一个任务不希望直接占用当前线程太久，我们往往都会想到线程池。

而线程池最让人头疼的问题之一，就是：

corePoolSize 到底应该设置多少？

maximumPoolSize 设置多少合适？

queueCapacity 到底应该设置 10、50，还是 1000？

很多时候，我们的答案是：

• CPU 密集型：CPU 核心数 + 1
• IO 密集型：CPU 核心数 × 2
• 或者直接设置一个比较大的线程数
• 队列？先来个 100、500、1000 再说

这些经验并不是完全没有价值。

但它们有一个明显的问题：

它们很难回答“为什么是这个数字”。

更进一步：

如果业务流量从 500 QPS 涨到 900 QPS，会发生什么？

如果单个任务平均执行 200ms，线程池需要多少线程才能满足业务目标 QPS？

如果我希望任务在队列中平均只等待 20ms，队列到底需要多大？

如果流量存在 3 分钟的周期性突发，又应该怎么设计？

这些问题，就开始进入排队论（Queuing Theory）的范畴。

而在线程池调优中，排队论恰好提供了一套非常有价值的思考框架。

---

一、线程池本质上就是一个“小型排队系统”

先不要急着看公式。

我们先想象一个非常普通的场景。

用户请求进入 Java 服务：

请求
  ↓
Tomcat
  ↓
业务线程池
  ↓
执行任务
  ↓
返回结果

假设业务线程池有 20 个工作线程。

当请求到达时，如果有空闲线程：

请求1 ──→ 线程1
请求2 ──→ 线程2
请求3 ──→ 线程3
...

任务可以立即执行。

但是，如果 20 个线程全部都在忙：

                ┌→ 线程1
                ├→ 线程2
请求 → 线程池 ──┼→ ...
                ├→ 线程20
                │
                └→ 队列
                     ↑
                  后来的任务

新的任务怎么办？

排队。

这其实就是一个非常典型的排队系统：

任务到达
   ↓
等待
   ↓
服务
   ↓
完成

而排队论研究的，恰恰就是这种问题。

---

二、M/M/c：最经典的多服务台模型

在排队论中，有一个非常经典的模型：

M/M/c。

这里的三个字符分别描述了排队系统的核心特征：

M / M / c
│   │   │
│   │   └── 服务台数量
│   └────── 服务时间分布
└────────── 到达过程

第一个 M 表示到达过程具有 Markovian 特征，在经典模型中对应泊松到达过程。

第二个 M 表示服务时间服从指数分布。

c 表示服务台数量。

例如：

M/M/1

就是只有一个服务台。

而：

M/M/10

就是 10 个服务台。

放到线程池里就很好理解了：

线程池中的每一个工作线程，都可以看成一个服务台。

所以：M/M/c 可以帮助我们建立一个非常直观的线程池模型。

---

三、把排队论的参数翻译成线程池语言

排队论里面有几个非常重要的参数。

1. λ：到达率

排队系统中的 λ 表示单位时间内到达多少个任务。

例如：

λ = 500 个/秒

在线程池中，可以直接理解成：

任务提交速率，也就是 QPS。

所以：

λ = 500 QPS

意味着：

每秒平均有 500 个任务进入线程池。

---

2. μ：单个服务台的服务率

排队论中的 μ 表示一个服务台单位时间能够处理多少个任务。

假设一个线程平均处理一个任务需要：

200ms

即：

单次服务平均时长 S = 0.2s

单个线程理论上的平均处理能力就是：

$$\begin{aligned} μ &= \frac{1}{S} \\ &= \frac{1}{0.2} \\ &= 5 \end{aligned}$$

也就是说：

一个线程平均每秒处理 5 个任务。

---

3. c：服务台数量

如果线程池有：

100 个工作线程

那么：

c = 100

也就是：

排队系统拥有 100 个并行服务台。

因此，线程池的三个核心参数可以这样对应：

排队论	线程池
λ	任务提交速率（QPS）
μ	单个线程的处理速率
c	工作线程数
1/μ	单个任务平均处理时长
ρ	线程池利用率

这正是我们后面用排队论分析线程池的基础。

---

四、最重要的参数：利用率 ρ

有了 λ、μ、c 之后，我们可以得到一个非常重要的指标：

$$ρ = \frac{λ}{cμ}$$

它表示整个服务系统的利用程度。

例如：

λ = 500 QPS

单线程平均处理时间：
S = 200ms

μ = 1 / 0.2 = 5 QPS

线程数：
c = 100

那么：

$$\begin{aligned} ρ &= \frac{500}{100 \times 5} \\ &= 1 \end{aligned}$$

这意味着：

线程池理论上的处理能力，刚好等于任务到达速度。

看起来好像刚刚好。

但实际上，这已经是一个非常危险的状态。

---

五、为什么线程池不能长期跑在 100%？

这是理解线程池调优最重要的一步。

假设：

线程池处理能力 = 500 QPS

平时：

到达速度 = 400 QPS

那么还有一定余量。

但是突然：

到达速度 = 500 QPS

所有线程都开始忙。

如果再出现：

501 QPS

意味着什么？

每秒多出来 1 个任务，没有线程能够立即处理。

于是开始排队。

如果继续：

到达 550 QPS
处理能力 500 QPS

那么每秒都会多出来 50 个任务，队列不断增长。

所以经典 M/M/c 模型要求：

ρ < 1

否则系统会变得不稳定，队列可能持续增长。

这也是为什么：

线程池“线程数够不够”，不能只看当前 QPS，还要看系统利用率和流量波动。

---

六、线程池为什么会出现“越忙，延迟越高”？

这其实也是排队论非常直观的结论。

假设：

任务处理时间：200ms
线程数：100

理论处理能力：

$$\frac{100}{0.2} = \text{500 QPS}$$

如果只有 100 QPS，大部分任务来了就能直接执行。

所以：排队时间 ≈ 0

但是如果流量逐渐增加：

100 QPS
200 QPS
300 QPS
400 QPS
450 QPS
480 QPS

线程池越来越忙。

任务立即获得线程的概率越来越低。

于是：

排队时间 ↑
RT ↑

当 ρ → 1，系统的排队延迟会变得越来越敏感。

所以生产环境里经常会出现一种现象：

QPS 并没有增加多少，但 RT 却突然开始明显上涨。

很多时候，问题并不是业务代码突然变慢了。

而是系统已经开始排队了。

---

七、线程池调优并不是“线程越多越好”

看到这里，很容易产生一个误区：

既然线程池忙了会排队，那我把线程数调大不就好了？

也不一定。

线程数增加意味着并发执行能力增加，但线程本身也会带来成本：

线程栈内存
上下文切换
CPU 调度
锁竞争
下游连接竞争
数据库连接竞争
HTTP 连接竞争

特别是 IO 型任务。

假设：

平均任务耗时 200ms

但真正占用 CPU 的时间可能只有：

10ms

剩下：

190ms

都在等待网络、数据库或者第三方服务。

这种情况下增加线程数确实可能提高吞吐。

但如果无限增加：

100
200
500
1000

最终可能不是线程池解决了问题，而是把压力继续传给了：

数据库
Redis
HTTP 服务
连接池
CPU

所以：

线程池调优的目标，从来都不是让线程数尽可能大。

真正的目标应该是：

在满足吞吐量的同时，让排队延迟、系统利用率和资源消耗处于合理范围。

这时候，我们就需要更加量化的方法。

---

八、Little's Law：排队论中最值得掌握的一条公式

如果说 M/M/c 帮助我们建立了“线程池是一个排队系统”的模型，那么 Little's Law 则给了我们一个非常简单、非常实用的关系：

$$L = λ \cdot W$$

其中：

L = 系统中的平均任务数
λ = 平均到达率
W = 任务在系统中的平均停留时间

如果只关注队列：

$$L_q = λ \cdot W_q$$

其中：

Lq = 平均排队任务数
Wq = 平均排队等待时间

这些关系并不依赖 M/M/c 的具体假设，是排队论中非常具有普适性的关系。

---

九、Little's Law 放到线程池里，会发生什么？

假设我们的业务：

QPS = 500

我们希望：

平均排队等待时间 ≤ 20ms

那么根据：

$$L_q = λ \cdot W_q$$

可以得到：

$$\begin{aligned} L_q &= 500 \times 0.02 \\ &= 10 \end{aligned}$$

也就是说：

如果希望平均排队等待时间控制在 20ms 左右，那么从平均意义上看，队列中的任务数量应该大约是 10 个量级。

这就和我们平时设置：

queueCapacity: 10

产生了联系。

注意，这里不是说：

“Little's Law 算出来队列必须设置成 10。”

而是说：

它给了我们一个非常有价值的量级参考。

最终到底设置多少，还要结合突发流量、任务耗时分布、拒绝策略以及实际压测结果验证。

---

十、这就是“经验调参”和“模型调参”的区别

假设现在有一个线程池：

corePoolSize: 50
maximumPoolSize: 100
queueCapacity: 1000

如果有人问：

为什么 queueCapacity 是 1000？

如果回答：

因为生产环境一般这么设置。

这就是经验。

但如果我们换一种思路：

业务 QPS
↓
任务平均处理时间
↓
单线程处理能力
↓
目标线程池利用率
↓
估算线程数
↓
目标排队等待时间
↓
估算队列容量
↓
压测验证

那么整个过程就变成了：

先建模 -> 再计算 -> 再压测 -> 再修正。

这才是我们真正想建立的线程池调优方法。

---

十一、排队论并不是一个“算出答案”的魔法

这里需要特别强调一点。

排队论不是告诉你：

“输入几个数字，直接得到一个绝对正确的线程池配置。”

现实系统远比数学模型复杂。

比如：

• 任务耗时并不一定服从指数分布
• QPS 可能存在周期性波动
• 请求可能存在瞬时突发
• Tomcat 本身也有线程池
• 下游 RPC 有连接池
• 数据库有连接池
• CPU 有上限
• GC 会造成抖动
• 线程调度存在额外开销
• 任务耗时还可能存在长尾

所以：

M/M/c 是模型，不是真实系统本身。

模型的价值在于：

给我们一个合理的第一性估算。

然后通过压测和监控去验证这个估算。

---

十二、从“拍脑袋”走向“可验证”

因此，一套比较完整的线程池调优过程，可以逐渐形成这样的闭环：

        业务特征
           ↓
   ┌─────────────────────────┐
   │ QPS / 峰值QPS            │
   │ 任务平均耗时              │
   │ 任务类型 CPU密集 / IO密集  │
   └─────────────────────────┘
           ↓
        排队模型
           ↓
   ┌───────────────┐
   │ 线程数估算      │
   │ 利用率估算      │
   │ 队列容量估算    │
   └───────────────┘
           ↓
        实际压测
           ↓
   ┌───────────────┐
   │ TPS            │
   │ RT / P95/P99   │
   │ 活跃线程数       │
   │ 队列大小        │
   │ CPU            │
   │ 拒绝任务数      │
   └───────────────┘
           ↓
       对比模型
           ↓
       调整参数
           ↓
       再次压测

这时候，线程池调优就不再是：

“我感觉 100 个线程差不多。”

而是：

“按照当前 QPS、任务处理时间和目标利用率，理论上需要约 N 个线程；按照目标排队等待时间，队列容量应该在 M 的量级；然后通过压测验证实际 P95/P99、CPU、活跃线程数和拒绝数。”

这两种思维方式完全不同。

---

十三、下一步：真正开始算线程池

到这里，我们其实还没有真正开始“调线程池”。

我们只是完成了一件更重要的事情：

建立模型。

现在，我们已经知道：

λ 可以代表任务提交 QPS；

$μ = \frac{1}{S}$ 可以代表单线程处理能力；

c 可以代表工作线程数；

$ρ = \frac{λ}{cμ}$ 可以描述线程池利用率；

而：

$L = λ \cdot W$ 和 $L_q = λ \cdot W_q$ 则可以把QPS、排队任务数、等待时间联系起来。

接下来，我们就可以真正回答几个非常实际的问题：

问题 1

已知：

QPS = 500
任务平均耗时 = 200ms

那么：

线程池到底需要多少个线程？

---

问题 2

如果我们希望线程池利用率控制在：

70% 或者 80% 或者 90%

那么：

线程数应该怎么算？

---

问题 3

如果希望：

平均排队等待时间 ≤ 20ms

那么：

queueCapacity 应该设置多少？

---

问题 4

如果平时只有：

500 QPS

但是每隔几分钟会出现：

900 QPS

并且持续：

3 分钟

那么：

到底应该按照 500 QPS 设计，还是按照 900 QPS 设计？

---

问题 5

如果为了扛住突发流量，把：

maximumPoolSize

调得非常大，会不会反过来把 Tomcat、数据库或者下游 RPC 打爆？

这些问题，才是线程池调优真正有意思的地方。

而答案，就可以从我们今天建立的这套模型继续往下推。

---

写在最后

线程池本质上不是一个简单的：

corePoolSize
maximumPoolSize
queueCapacity

三个数字。

它背后其实是一个完整的排队系统：

流量
 ↓
任务到达
 ↓
排队
 ↓
线程服务
 ↓
任务完成

而排队论提供了一套语言，让我们可以把这个过程量化。

M/M/c 帮助我们理解多线程并行服务系统；

ρ 帮助我们理解线程池为什么不能长期处于满载状态；

Little's Law 则把 QPS、排队任务数和等待时间联系起来。