压测调优需基于线程池状态与任务特性确定并发边界，平衡CPU、I/O、队列、线程数；按CPU/I/O/混合型任务设定线程数，分离业务与容器线程池；监控activeCount、queue.size等指标；分阶段识别队列堆积、吞吐平台、拒绝突增三拐点；验证稳定性并固化有界队列+明确拒绝策略配置。
压测调优不是“试几个数字看哪个QPS高”，而是通过观察线程池内部状态变化，结合任务特性反推合理并发边界。核心目标是让CPU、I/O、队列、线程数四者达到协同平衡，避免某一项成为瓶颈。
明确任务类型，决定调优起点
任务性质直接决定线程数的理论下限和上限：
-
CPU密集型（如加解密、图像处理）：线程数不宜超过 CPU逻辑核数 + 1。再多只会加剧上下文切换，吞吐不升反降。可用
Runtime.getRuntime().availableProcessors()获取核数。 -
I/O密集型（如HTTP调用、DB查询、文件读写）：线程数需覆盖等待时间。推荐公式：
核数 × (1 + 平均等待时间 / 平均CPU计算时间)。例如核数8、平均处理10ms（其中1ms计算+9ms等待），理论值 ≈ 8 × (1 + 9) = 80。 - 混合型（如典型Web接口）：建议先按I/O密集估算，再通过压测收敛。Spring Boot应用中，业务线程池应与Tomcat容器线程池分离，避免互相争抢。
设计可监控的线程池实例
不能只看外部QPS和响应时间，必须暴露内部指标才能定位真因：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 使用
ThreadPoolExecutor手动构造，禁用Executors.newXXX（它们隐藏了队列容量和拒绝策略）。 - 关键监控项实时采集：
•getActiveCount()：当前正在执行任务的线程数
•getQueue().size()：排队中任务数量
•getCompletedTaskCount()与getTaskCount()差值反映积压趋势
• 拒绝异常（RejectedExecutionException）是否出现 - 建议扩展
ThreadPoolExecutor，在beforeExecute和afterExecute中埋点记录耗时、线程ID、任务哈希，用于分析长尾任务。
分阶段压测，观察三类拐点
用JMeter或Gatling逐步加压，每阶段持续2–3分钟，重点关注以下三个临界点：
立即学习“Java免费学习笔记（深入）”；
-
队列开始堆积点：当
queue.size()持续 > 队列容量 × 0.7，说明核心线程已饱和，但临时线程未及时扩容——检查corePoolSize是否偏低，或任务入队逻辑是否被阻塞。 -
吞吐平台期：QPS不再随并发用户数上升，而
activeCount接近maximumPoolSize，CPU使用率 > 85%，此时继续加压只会抬高延迟，说明已达线程层瓶颈。 -
拒绝/异常突增点：出现批量
RejectedExecutionException或CallerRunsPolicy大量触发，表明workQueue已满且线程扩无可扩——需调大队列容量、提高maximumPoolSize，或优化单任务耗时。
调优后验证与固化
找到候选参数组合后，还需做两件事：
- 做稳定性压测：以最优并发量持续运行15–30分钟，观察GC频率、内存增长、线程数是否震荡。若
activeCount在 core 和 max 之间频繁伸缩，说明keepAliveTime过短，可适当调大（如从60秒→300秒）。 - 配置有界队列 + 明确拒绝策略：例如
new ArrayBlockingQueue(200)配合new ThreadPoolExecutor.CallerRunsPolicy()，既防OOM，又能在过载时自然降速，比直接丢任务更可控。 - 将最终参数写入配置中心（如Nacos/Apollo），支持运行时动态调整，应对流量峰谷变化。
