【一】案例说明

现在有一个springboot项目，有一个接口是使用easyexcel对100万条数据进行批量导出，引入线程池提高效率，通过压测来得到线程池合适的配置参数

【二】明确线程池核心参数及优化目标

【1】线程池核心参数（需压测验证的关键参数）

（1）corePoolSize：核心线程数（始终存活的线程数）。
（2）maximumPoolSize：最大线程数（核心线程忙时可扩容的最大线程数）。
（3）workQueue：任务队列（核心线程忙时，新任务的缓冲队列，如LinkedBlockingQueue）。
（4）keepAliveTime：非核心线程空闲存活时间（超出核心线程数的线程，空闲后销毁的时间）。
（5）rejectedExecutionHandler：拒绝策略（任务队列满且线程数达最大值时的处理策略，如AbortPolicy/CallerRunsPolicy）。

【2】优化目标

（1）吞吐量：单位时间内成功导出的任务数（越高越好）。
（2）响应时间：单个导出任务的平均 / 90%/99% 响应时间（越低越好）。
（3）资源利用率：CPU 使用率（建议≤80%）、内存使用率（无 OOM 风险）、线程池活跃线程数（无大量空闲线程）。
（4）稳定性：无任务被拒绝、无数据库连接池耗尽、无频繁 GC。

【三】压测前准备

【1】环境搭建

（1）硬件：测试环境配置需接近生产（如 CPU 核心数、内存大小、磁盘 IO），避免因环境差异导致结果失真。
（2）依赖隔离：压测期间关闭其他非必要服务（如定时任务、其他接口），确保资源仅用于导出接口。
（3）数据准备：提前在测试库中准备 100 万条符合生产特征的测试数据（避免压测时因数据生成消耗资源）。

【2】线程池初始配置（基于经验值）

导出任务属于IO 密集型（涉及数据库查询 IO、文件写入 IO），初始参数可参考经验值：

@Configuration
public class ThreadPoolConfig {@Bean("exportExecutor")public Executor exportExecutor() {// 获取CPU核心数（假设测试机为8核）int cpuCore = Runtime.getRuntime().availableProcessors();ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(cpuCore * 2); // 核心线程数：IO密集型通常为CPU核心数*2executor.setMaxPoolSize(cpuCore * 4);  // 最大线程数：核心线程数的2倍executor.setQueueCapacity(1000);       // 任务队列大小：初始1000executor.setKeepAliveSeconds(60);      // 非核心线程空闲60秒销毁executor.setThreadNamePrefix("export-");// 拒绝策略：任务队列满时，让提交任务的线程执行（避免任务丢失，同时限流）executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());executor.initialize();return executor;}
}

【3】压测工具与监控指标

压测工具：JMeter（简单易用）或 Gatling（高并发场景更稳定）。

监控指标：
（1）系统层面：CPU 使用率、内存使用率、磁盘 IO（导出文件写入速度）、网络 IO（若涉及远程存储）。
（2）JVM 层面：堆内存使用、GC 次数 / 耗时（避免频繁 Full GC）、线程数（活跃线程 / 阻塞线程）。
（3）应用层面：接口响应时间（平均 / 90%/99%）、吞吐量（TPS）、线程池状态（活跃线程数、队列等待数、拒绝任务数）。
（4）数据库层面：连接池使用率、查询响应时间、锁等待（避免导出时数据库成为瓶颈）。

【四】压测方案设计（控制变量法）

每次仅调整 1 个参数，其他参数固定，对比不同配置下的指标变化。

【1】场景 1：确定最佳核心线程数（corePoolSize）

（1）固定参数：maxPoolSize = 32（8 核 CPU×4）、queueCapacity = 1000、keepAliveTime = 60s。
（2）变量：corePoolSize 取值：4、8、16、24、32（基于 CPU 核心数的 0.5~4 倍）。
（3）压测条件：并发用户数 = 50（模拟实际可能的最大并发导出请求），持续压测 10 分钟。
（4）观察指标：
当corePoolSize过小时（如 4）：活跃线程数很快达上限，任务大量进入队列，响应时间变长。
当corePoolSize过大时（如 32）：CPU 使用率可能超过 80%，上下文切换频繁，吞吐量下降。
最佳值：CPU 使用率稳定在 60%~70%，响应时间最短，吞吐量最高的corePoolSize。

【2】场景 2：确定最大线程数（maximumPoolSize）

（1）固定参数：corePoolSize = 场景1的最佳值、queueCapacity = 1000、keepAliveTime = 60s。
（2）变量：maximumPoolSize 取值：corePoolSize、corePoolSize×1.5、corePoolSize×2、corePoolSize×3。
（3）压测条件：并发用户数 = 100（高于日常并发，模拟峰值），持续压测 10 分钟。
（4）观察指标：
若maximumPoolSize= 核心线程数：高并发时任务全靠队列缓冲，响应时间可能过长。
若maximumPoolSize过大（如核心线程数 ×3）：非核心线程频繁创建销毁，增加开销。
最佳值：非核心线程被触发（即活跃线程数 > corePoolSize），但未导致 CPU 过高（<80%），且响应时间无明显增加的配置。

【3】场景 3：确定任务队列大小（queueCapacity）

（1）固定参数：corePoolSize和maximumPoolSize为前两步最佳值，keepAliveTime = 60s。
（2）变量：queueCapacity 取值：500、1000、2000、5000（或使用无界队列Integer.MAX_VALUE）。
（3）压测条件：并发用户数 = 150（超峰值，测试队列缓冲能力），持续压测 10 分钟。
（4）观察指标：
队列过小（500）：可能触发拒绝策略（任务被拒绝），但内存占用低。
队列过大（5000）：任务堆积过多，内存占用飙升（尤其 100 万条数据的任务对象），可能 OOM。
最佳值：无任务被拒绝，且内存使用率稳定（堆内存占用 < 70%）的最小队列大小。

【4】场景 4：验证拒绝策略（rejectedExecutionHandler）

（1）固定参数：前 3 步的最佳corePoolSize、maximumPoolSize、queueCapacity。
（2）变量：拒绝策略（AbortPolicy终止任务并抛异常、CallerRunsPolicy让提交线程执行、DiscardOldestPolicy丢弃最老任务）。
（3）压测条件：并发用户数 = 200（远超系统承载能力），持续 5 分钟。
（4）观察指标：
AbortPolicy：适合严格不允许任务丢失的场景，但会抛异常需业务处理。
CallerRunsPolicy：适合需要限流的场景（提交线程被阻塞，间接降低并发），但响应时间变长。
最佳策略：根据业务是否允许任务丢失选择，建议优先CallerRunsPolicy（避免任务丢失且自带限流）。

【五】压测结果分析与最优配置确定

【1】关键指标对比表（示例）

配置项	吞吐量（TPS）	平均响应时间（s）	90% 响应时间（s）	CPU 使用率	内存使用率	拒绝任务数
corePoolSize=8	12	8.5	12.3	65%	50%	0
corePoolSize=16	18	5.2	7.8	70%	55%	0
corePoolSize=24	17	5.5	8.1	85%	60%	0

（表格解读：corePoolSize=16时，吞吐量最高，响应时间最短，CPU 使用率适中，为最佳值）

【2】最优配置判断标准

（1）吞吐量：在相同并发下，该配置的 TPS 最高。
（2）响应时间：90% 响应时间≤业务可接受阈值（如 10 秒）。
（3）资源稳定：CPU 使用率≤80%，内存无明显泄漏，GC 正常（无频繁 Full GC）。
（4）无任务丢失：拒绝任务数为 0（或在业务允许范围内）。

【六】最终验证与动态调整

稳定性验证：用最优配置，以日常并发的 1.5 倍持续压测 30 分钟，观察指标是否稳定（无明显波动）。
动态参数优化：生产环境可通过 Spring Cloud Config/Apollo 动态调整线程池参数（无需重启服务），例如：

// 动态修改核心线程数
@Autowired
private ThreadPoolTaskExecutor exportExecutor;public void updateCorePoolSize(int coreSize) {exportExecutor.setCorePoolSize(coreSize);
}

结合业务峰值：在已知业务峰值时段（如每日凌晨报表导出），临时调大corePoolSize和maximumPoolSize，峰值后恢复默认值。

【七】总结

通过 “控制变量法” 压测，重点关注核心线程数、最大线程数、队列大小三个参数，结合 IO 密集型任务特性（线程数可略高于 CPU 核心数），最终找到 “吞吐量高、响应时间短、资源占用合理” 的配置。对于 100 万条数据导出场景，典型最优配置可能为：corePoolSize=CPU核心数×2、maximumPoolSize=CPU核心数×3、queueCapacity=1000~2000，具体需根据实际压测结果调整。