促销活动开始前，运维和开发同学最关心的一个问题就是：当前这套服务到底能扛住多大的并发？很多人会写一个固定参数的线程池压一遍，得到一个看似不错的数字，结果大促一上线就雪崩。问题的根源往往不在压测工具，而在于线程池参数是写死的，压测时想模拟不同的并发水位，只能改代码、打包、重启，一轮压测下来半天时间就没了。其实 JDK 的 ThreadPoolExecutor 早就预留了动态调整的能力，也就是 setCorePoolSize 和 getCorePoolSize 这对方法。这篇文章就从原理到实战，完整讲一遍如何利用它们搭建一套可以在线调参的压测环境。
一、getCorePoolSize 与 setCorePoolSize 的底层原理
先看 getCorePoolSize，它的实现非常简单，就是返回一个 volatile 修饰的成员变量 corePoolSize。而 setCorePoolSize 才是真正干活的方法。当调用 setCorePoolSize 传入新值时，线程池内部会做三件事：第一，用新值更新 corePoolSize 变量；第二，如果新值比当前工作线程数小，多余的空闲线程会被中断回收；第三，如果新值比当前工作线程数大，会立即预启动新的工作线程去补齐到新值，而不是像初始化那样懒加载。
这里有一个容易被忽略的细节：线程的回收依赖 interruptIdleWorkers 方法。这个方法会尝试中断那些没有正在执行任务的空闲 Worker。注意是空闲的，正在跑任务的线程不会被强杀，所以动态调小核心线程数是平滑的，不会导致正在执行的任务被中断。这个特性对线上环境非常友好，也是美团开源的 DynamicTp 这类动态线程池组件能够落地的基石。
再看一下 JDK 源码中 setCorePoolSize 的关键逻辑，帮你建立更直观的印象：
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0)
throw new IllegalArgumentException();
// 计算差值，决定是补充线程还是回收线程
int delta = corePoolSize - this.corePoolSize;
this.corePoolSize = corePoolSize;
if (workerCountOf(ctl.get()) > corePoolSize)
// 线程过多，中断空闲线程让其退出
interruptIdleWorkers();
else if (delta > 0)
// 核心线程变多，直接预启动补齐
int k = Math.min(delta, workQueue.size());
while (k-- > 0 && addWorker(null, true)) {
if (workQueue.isEmpty())
break;
}
}从源码可以看出，调大和调小的行为是不对称的：调大时只有队列里有积压任务才会立即创建新线程，队列是空的就不会补；调小时只是发中断信号，实际回收要等线程走完 getTask 里的判断逻辑。理解了这一点，压测时观察线程数的变化就不会觉得诡异了。
二、实现一个可动态调参的线程池压测骨架
原理清楚了，接下来写一个可以直接跑的压测骨架。思路是把 ThreadPoolExecutor 包一层，暴露一个 HTTP 接口用于在线修改核心线程数，同时通过 getCorePoolSize 实时上报当前参数，方便压测脚本在每一轮压力档位前后做参数核对，避免出现"参数改了但没生效"的脏数据。
@RestController
public class ThreadPoolController {
private final ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, // 初始核心线程数
128, // 最大线程数
60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(1000),
new ThreadPoolExecutor.CallerRunsPolicy());
// 在线调整核心线程数
@PostMapping("/pool/resize")
public String resize(@RequestParam int coreSize) {
int before = executor.getCorePoolSize();
executor.setCorePoolSize(coreSize);
// 注意：如果新核心数超过原最大线程数，需要同步调大 maximumPoolSize
if (coreSize > executor.getMaximumPoolSize()) {
executor.setMaximumPoolSize(coreSize);
}
return "coreSize: " + before + " -> " + executor.getCorePoolSize();
}
// 模拟促销下单业务的处理任务
@PostMapping("/pool/submit")
public String submit() {
executor.execute(() -> {
try {
// 模拟一次下单链路耗时，包含扣库存、写订单、发消息
Thread.sleep(50);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
return "accepted, active=" + executor.getActiveCount()
+ ", core=" + executor.getCorePoolSize();
}
}这段代码里有几个点必须强调。第一，setCorePoolSize 的入参不能超过 maximumPoolSize，否则会抛 IllegalArgumentException，所以压测前如果要突破初始的最大线程数，必须先调大 maximumPoolSize 再调核心数，代码里已经做了保护。第二，监控指标要和 getCorePoolSize 的返回值对齐，压测报告里每一轮 QPS 都要标注当时的核心线程数，否则数据没有说服力。第三，拒绝策略建议用 CallerRunsPolicy，压测时它能起到天然的限流反压作用，防止任务被静默丢弃导致吞吐虚高。
三、促销压测实战：从 8 核心线程逐级拉到 64 的完整流程
有了动态调参能力，压测流程就可以设计成阶梯式的。第一步，系统预热，以低流量跑五分钟，让 JIT 编译完成、连接池就绪。第二步，固定压测流量为每秒 600 个请求，然后依次把核心线程数调整为 8、16、32、64 四个档位，每个档位持续压测三分钟，记录平均响应时间、P99 延迟和错误率。第三步，回放数据，找出吞吐拐点。
用一个典型的压测结果来说明怎么读数据。假设任务平均耗时 50 毫秒，理论上单个线程每秒能处理 20 个任务，64 个核心线程的理论上限就是 1280 TPS。实测中，8 线程时 TPS 大约 155，16 线程约 305，基本呈线性增长；但到了 64 线程，TPS 可能只到 950 左右，不再线性。原因通常是下游数据库连接池成为瓶颈，或者 CPU 上下文切换开销变大。这个拐点就是你要找的答案：促销期间核心线程数设置在这个拐点附近，再大就是浪费甚至副作用。
最后列几个实战中高频踩坑点。一是队列容量要设置合理，无界队列会让最大线程数永远不生效，动态调参也就失去了意义；二是任务里如果有 Thread.sleep 模拟耗时，别忘了压测前把 sleep 换成更真实的下游调用，否则测出来的线程数水位严重失真；三是动态调参接口本身要做好权限控制，绝不能裸奔在公网，促销前建议加一层内网网关校验；四是每次调参后等待一到两秒再开始压测，给 interruptIdleWorkers 和预启动线程留出生效时间，确保 getCorePoolSize 读到的值和线程池实际状态一致。把这些细节都照顾到，你就能在大促前用最短的时间完成一次可信的并发性能压测。
getCorePoolSize线程池动态调参修改时间：2026-09-06 17:56:37