企业官网建设流程全解析

一句话回答你：压测这事儿，看着是给系统施压，实际是在帮自己找“系统什么时候会跪、跪在哪、怎么救”的答案。

我这些年用Java写过不少业务系统，也折腾过各种接口，最深的体会就是：大多数性能问题不是靠感觉“优化”出来的，而是靠压测把问题逼出来的。很多时候你以为的瓶颈在数据库，压完发现是线程池配错了；你以为GC是元凶，压完发现是锁竞争把CPU耗光了。不跑一轮像样的压测，你连问题的门都摸不着。

这篇内容我打算从实操角度完整拆解Java应用性能压测这件事——怎么设计压测场景、怎么判断指标、怎么定位瓶颈、怎么落地优化，最后用一个真实场景把整个流程串起来。适合刚接手微服务性能优化的后端开发，也适合正在准备生产环境容量评估、想搞清楚“为什么系统一到高峰期就卡”的运维同学。看完你至少能拥有一个属于自己团队的排查路径，而不是拿到压测报告后手足无措。

1. 压测前的准备工作：不做好这些，压测就是白跑

很多人上来就装JMeter、开线程组、填接口地址，然后一点“运行”，看着QPS数字还挺高，就觉得系统没问题。这个做法我强烈不建议，因为你根本没有建立“可比较的基准”，压出来的数据既不能解释问题，也无法指导优化。压测不是跑脚本，是整个工程流程的起点，前面几步没做好，后面全是在浪费时间。

1.1 环境隔离：为什么压测不能直接在联调环境跑

先聊环境的选择。真实压测最忌讳的就是在共享联调环境里跑——别人正在调接口，你这边疯狂灌流量，两边互相污染，数据乱成一锅粥。我在实际项目里见过最离谱的情况：压测环境下有一个定时任务在批量清理数据，把压测产生的测试订单全部清掉了，导致响应时间曲线突然断崖式下跌，一开始还以为是服务崩了，最后排查出来是数据被定时任务删了，白白浪费了半天时间。

正确的做法是准备一套独立的性能测试环境，尽量在硬件规格、网络拓扑、依赖中间件版本上对标生产环境。这里有个常见的误解：很多人觉得性能测试环境可以用低配机器，只要验证功能就行。但你压的是“性能”，如果测试机的CPU核数只有生产的一半，堆内存也小，那你压出来的线程池参数、连接池大小、JVM参数全都不能直接迁移到生产，因为资源水位完全不对。如果实在申请不到完整的环境，至少也要做到核心链路的服务单独隔离，下游的数据库、缓存、MQ用同等规格的实例，这样才能让压测结果有参考价值。

1.2 测试数据和压测模型：先想清楚模拟的是什么

数据准备是大部分人最容易偷懒、也最容易翻车的地方。我见过有人拿生产库脱敏数据直接灌到测试库，结果压测的时候发现数据量太大，SQL扫描全表，接口的响应时间从2毫秒飙到800毫秒，他们一开始还以为系统有问题，结果一看数据量是生产的30倍。压测数据的核心原则是“分布贴近生产，总量分级可控”：主表数据量级要和生产相近，索引选择性和唯一值分布也要接近，否则优化出来的SQL索引在压测环境有效，到了生产就失效。

压测模型同样需要提前设计。你得想清楚模拟的是哪种流量形态，是平稳的日常流量，还是秒杀式的突发流量，还是两者都要覆盖。我常用的做法是先做一次小规模探底压测，比如50并发跑5分钟，观察基础表现；然后逐步递增到目标并发，观察系统吞吐和响应时间的拐点在哪；最后再在拐点附近做持续稳定压测，跑15到30分钟，看各项指标是否会产生缓慢恶化。这个思路比一上来直接上500并发要安全得多，也更容易定位问题，因为你手里有一整条递增曲线可供分析。

1.3 工具选型：JMeter、wrk、Gatling到底怎么选

压测工具是另一个容易费口水的话题。我综合多年使用经验给你一个相对客观的结论：不要迷恋工具，而要看工具能否覆盖你的压测维度。

• JMeter：胜在生态全、支持分布式压测、断言丰富，适合复杂业务流程和多协议场景，大多数Java团队的标配。
• wrk / wrk2：基于C语言的高性能压测工具，单机即可压出很高的并发，适合快速验证单个接口的QPS天花板，但不能模拟复杂业务链路。
• Gatling：基于Scala的异步压测工具，脚本可维护性好，生成的HTML报表非常专业，适合有代码洁癖的团队，但学习曲线比JMeter陡一些。
• 自研压测脚本：如果只是内部工具类接口，用Java自己写一个多线程请求客户端也行，但要注意别让压测客户端本身的线程开销成为瓶颈。

工具本身没有绝对的好坏，我见过有的团队用JMeter跑得很溜，也见过有人用wrk两三分钟就定位了问题。关键是你得选一个团队内大家都会用、能沉淀脚本和报告的工具，而不是今天用这个、明天换那个，最后连历史数据都没法对比。

2. 压测过程的核心指标：看懂数据背后的系统状态

压测跑起来之后，你盯着屏幕看什么？很多人只看QPS和响应时间，这两个数字当然重要，但只看它们远远不够。你要通过一组指标的组合，去反推系统内部到底发生了什么。

2.1 QPS、TPS、RT和TP99：这几个数字要放在一起看

先明确概念。QPS全称是Queries Per Second，通常指每秒请求数；TPS全称是Transactions Per Second，通常指每秒处理的事务数。单接口场景下两者数值可能一致，但业务链路场景下，一个事务可能包含多个请求，这时候混用就会产生误判。我建议在压测报告中统一口径，要么都用请求数，要么都用事务数，不要这场压测说QPS、那场说TPS，搞得后面分析的同学一头雾水。

RT（Response Time）和TP99是响应时间维度的核心指标。RT看平均值容易骗人，因为少数慢请求会把平均值拉高，或者大量快请求把平均值压低。TP99的意思是99%的请求响应时间不超过该值，它能有效暴露尾部延迟，这才是用户真实体验的关键。举个实际例子，有个网关服务压测时平均RT只有80毫秒，但TP99到了600毫秒，这就是典型的“大部分请求还行、但每隔一段时间就有一个请求明显变慢”，这种问题在平均值上完全看不出来，必须看百分位指标。

2.2 并发用户数和QPS的换算：一个被反复问到的关系

很多新人混淆“并发数”和“QPS”，总觉得并发100就是每秒100个请求，其实两者存在一个换算关系：QPS = 并发数 / 平均RT（单位秒）。如果平均RT是100毫秒，并发100时，理论上QPS能达到1000；但如果RT本身就要1秒，那并发100时QPS最多只有100。所以压测时你要观察两类变化：一是保持并发不变、RT上升，说明系统处理能力在下降；二是并发增加、QPS不再线性增长，说明系统已经到达某个瓶颈点，再加并发只会让队列堆积、RT飙升。

实际的阶梯压测一般这样操作：先以10并发起步，稳定跑2到3分钟，记录QPS和RT；然后逐步增加到20、50、100、200，每轮观察QPS是否随并发增长。当发现QPS增长明显放缓、RT开始急剧上升时，回去看一眼上一档的数据，那个点附近基本就是系统的软上限。再往后压就不是为了测容量上限，而是为了验证系统在过载情况下的表现，比如会不会出现大量超时、连接池是否被打满、线程是否堆积。

2.3 错误率和资源水位：比响应时间更早暴露问题的信号

错误率同样是压测中的必看项，它和RT的区别在于：RT变差说明系统还在干活，只是慢；错误率上升说明系统已经开始拒绝干活了。常见的错误有HTTP 5xx、超时报错、连接池获取不到连接、数据校验异常等。我一般以错误率不超过0.1%作为一个基础门槛，超过就要立刻暂停压测，先查错误日志，而不是继续加压把问题放大。

资源水位我习惯看五样：CPU使用率、内存使用率、磁盘IO、网络带宽、JVM的GC开销。特别是CPU和GC，这两个指标直接反映应用线程的运行状态。如果CPU已经跑满而QPS还在下降，多半是代码里有死循环、频繁Full GC或者锁竞争严重；如果CPU占用很低但RT很高，问题大概率不在计算，而在等待——等锁、等IO、等下游响应。前一种情况从应用自身入手，后一种情况要从依赖链路入手，方向别搞反了。

3. 问题定位的实操技巧：从结果反推系统瓶颈

压测报告拿到手，最刺激的环节来了：定位瓶颈。我见过不少团队在报告会上对着图表猜来猜去，一会儿怀疑数据库、一会儿怀疑缓存，但就是拿不出证据。定位问题必须讲究证据链，每一步都要有对应的命令或者数据支撑。

3.1 CPU高、QPS低：先查锁、GC与线程状态

先说一类非常典型的症状：压测过程中CPU使用率很高，但QPS始终上不去。这种场景下我首选的操作是执行top -Hp [pid]看线程CPU占用，然后用thread dump抓取线程栈，看那些线程到底在干什么。

抓线程栈可以用JDK自带的jstack命令，也可以直接用Arthas的thread命令，个人强烈推荐Arthas，一个命令就能看到CPU最高的线程和对应的业务代码行号，省去了在jstack长文本里翻半天还翻不到的痛苦。我遇到过一个真实的案例：压测一个订单查询接口，CPU飙到85%，但QPS只有200多，怎么想都不对。用Arthas thread -n 3定位后发现热点全在一个日期格式化工具类的SimpleDateFormat.parse方法上，因为SimpleDateFormat不是线程安全的，大家加了synchronized保护，结果线程全部卡在锁上排队，表面看是CPU高，实际是锁竞争导致大部分线程在空转。后来把SimpleDateFormat替换成ThreadLocal或者DateTimeFormatter，QPS直接翻了四倍。

GC也是CPU高的常见来源，特别是频繁Full GC。定位手段是用jstat -gcutil [pid] 1000连续观察几秒，如果看到FGC列的数字快速增长、FGCT占比很高，那就是GC瓶颈。这时候不要急着调堆内存，先jmap -dump导出堆内存，用MAT或者jvisualvm打开看对象分布，确认是不是有对象泄漏、大对象或者集合无限增长。我见过一个内存泄漏导致的隐蔽问题：压测时每次请求都会往一个静态Map里塞数据，但从来不清除，一开始看不出问题，压到30分钟时Full GC频繁触发，QPS断崖下跌，dump出来一看Map里有几百万条无效记录。这种问题只看CPU是定位不到的，必须结合GC指标和堆分析。

3.2 CPU低、RT高：重点排查IO、连接池与下游依赖

与CPU高相反的另一类典型症状是CPU很闲，但请求响应很慢。这种情况的核心思路是“找等待”——线程都在等什么？等数据库、等Redis、等下游HTTP接口、等线程池队列里的资源。

先说数据库。先看一眼慢SQL日志，再看数据库连接池有没有被打满。我常用的排查顺序是：压测时打开连接池监控，看活跃连接数是否到了最大值；如果到了，去数据库侧看当前会话都在执行什么SQL。最常见的坑是连接池配置过小，比如默认的HikariCP maximumPoolSize只有10，压测并发一上来，线程全在等连接，RT自然就上去了。把连接池调大确实能快速缓解，但这不是根本解法，根本问题往往是某条SQL扫描行数太大、执行时间太长，把连接占住了。所以连接池调大之后还要回头查SQL的执行计划，确认索引有没有生效，避免用连接池扩容掩盖SQL本身的问题。

缓存和下游接口的排查思路类似。如果Redis的响应时间在压测中明显上升，要确认是否出现了大Key、热Key或者慢查询命令；如果调用下游接口的RT升高，要在压测前提前拿到下游可承受的流量上限，避免压测把别人的系统打挂。我特别提醒一点：压测时凡是涉及下游依赖，务必先跟相关团队拉通，明确哪些依赖可以压、哪些需要mock掉。我见过有团队压自己的服务，结果把下面的支付渠道测试额度打光，对方半夜发来告警，场面一度非常尴尬。

3.3 线程池和队列：最容易“温水煮青蛙”的隐患

线程池的问题是压测中特别容易被忽略、又特别典型的。默认情况下，像Tomcat的max-threads如果没配置，可能是200；如果你在代码里用了自定义线程池处理异步任务，线程也往往配得比较随意。压测时进程能扛住前几分钟的流量，但随着队列积压，RT会越来越差，最终在某一个临界点上线程全部被打满，QPS掉到几乎为零，这个表现很多时候容易被误判为“数据库变慢了”。

定位方式很简单：压测时每隔一段时间抓一次线程池的活跃线程数、队列积压量。Java自带的ThreadPoolExecutor可以通过getActiveCount、getQueue().size()拿到这些数据，或者更省事的是用Micrometer的jvm.executor监控指标直接上Grafana。当发现活跃线程数长期等于corePoolSize、队列深度持续上涨，说明线程池已经饱和了，再多的请求进来也都是排队，而不是执行。这时候有两个优化方向：一是调整核心线程数和队列大小，但要注意不是无限调大就是好事，线程太多反而导致上下文切换开销增加，CPU碎片化严重；二是要做限流和降级，让超过系统承受能力的请求快速失败，而不是长时间堆积在队列里影响全局稳定性。

4. 优化实践：从代码到参数的立体化调优

定位到问题之后，优化是顺理成章的事。但优化也要讲策略，不能头痛医头。我的经验是先做优先级排序：先改那些改动小、收益大的，再处理框架级和参数级的调优，最后才考虑架构层面的调整。

4.1 代码层面的优化：优先消灭无意义的开销

代码优化的核心原则是“减少每次请求的无意义开销”。举几个我经常在项目中看到的例子：

• 循环里重复创建对象或执行数据库查询，完全可以把对象创建提到循环外，把查询结果批量取回来。
• 用Stream做复杂嵌套过滤的时候，注意避免多次遍历同一个大集合；如果数据量大，一次stream操作能做完的事就别拆成三个pipe。
• 日志打印过度也是一类隐形开销，尤其是大对象序列化成JSON打日志，在高并发下极其耗CPU。生产环境压测前我会全局过一遍日志级别，把info级别下不该打印的内容关掉。

代码层面的优化见效快，但要注意每次改动都要有压测数据支撑，不要凭感觉“觉得这样会快”。我之前有个同事优化一个方法，觉得把ArrayList换成LinkedList会快，压测之后发现QPS反而没变化——因为业务代码压根没有在头部插入的操作。优化的前提是测量，没有压测验证的优化都是玄学。

4.2 线程池与连接池的参数调整：结合压测数据来定

参数调优方面，线程池和连接池是最值得深抠的。线程池不是越大越好，线程数超过一定程度后，CPU上下文切换的成本会侵蚀掉并发收益。业界有个通用参考公式：CPU密集型任务线程数设为CPU核数+1，IO密集型任务线程数设为CPU核数*2，但实际业务往往是混合型的，最靠谱的方式是通过压测找拐点。

我负责过的支付网关项目，最初Tomcat线程数配的是默认200，压测发现100并发时QPS就上不去了，加大线程数到400反而更差。后来用公式算了IO密集型合理值，再配合压测逐步调整，最终定在160，压测数据反而最优。原因是这个服务大量时间在等待下游HTTP响应，并非计算密集，线程数过多会让CPU浪费在切换上。

连接池同理。HikariCP的maximumPoolSize不是配置越大越好，连接数超过数据库能有效处理的会话数量后，反而因为连接争用增加延迟。一个相对可靠的经验公式是：连接数 = ((核心线程数 * 2) + 有效存储设备并发数)，按这个为起点，再结合压测数据做加减法。

4.3 JVM调优和缓存策略：最后的大招与常用手段

JVM调优是优化清单里的重量级选手，但千万别一上来就干这个。先把代码问题、线程池参数、SQL问题处理完，再回头看JVM。我的经验是优先确认三件事：堆内存是否足够支撑压测期的对象分配而不频繁Full GC、新生代是否过小导致对象过早进入老年代、GC算法是否匹配应用的特点（响应优先还是吞吐优先）。

缓存策略是另一个能快速见效的手段。热点数据如果能进本地缓存，比如用Caffeine做本地缓存，就能把大量重复查询挡在应用层，减少下游压力。但要特别注意缓存一致性，尤其是那种变更频繁的数据，本地缓存的过期时间要很短，或者依赖更新事件主动失效。跨服务的热点数据则可以考虑集中式缓存Redis，但要结合数据量评估内存成本和命中率，别什么数据都往缓存里塞，最后缓存比数据库还慢。

数据库优化方面，最常见的是慢SQL的处理。一条SQL执行10毫秒，你以为还好，但每秒500次请求就是5秒的数据库耗时。通过压测期间的慢日志和EXPLAIN执行计划，定位扫描行数大的SQL，加合适的索引、改写查询逻辑，往往能带来比线程池调参更显著的提升。

5. 一个完整的压测案例：从QPS上不去到定位并修复

前面讲的都是方法论，最后用一个我实际经历过的案例，把整个流程串起来。这个案例不算复杂，但很有代表性，几乎每次做性能分享我都会拿它当开场。

当时我们团队负责一个用户中心服务，对外提供用户信息查询接口，功能上是典型的三级链路：接收请求后再调用下游积分服务，返回响应。压测前预估这个接口单机至少能扛500 QPS，但第一轮压测结果让人大跌眼镜：50并发都跑不满，QPS卡在不到80，RT平均超过了600毫秒，而且进程的CPU利用率只有30%左右。

按照前面说的定位思路，第一步先看CPU和线程状态。CPU很低，说明不是计算瓶颈，是等待瓶颈。先抓数据库连接池监控，发现活跃连接数一直顶在最大值20，大量线程堆积在获得数据库连接的动作上。进一步查慢SQL日志，发现有一条按用户ID查积分明细的SQL执行耗时达到了300毫秒。EXPLAIN一看，问题很明显：积分明细表的user_id字段没有索引，每次查询都是全表扫描。更隐蔽的是，这个查询是循环里调用的，一个用户查最近十条累计积分，实际上要对这张大表做十次全表扫描。

定位到这一步，修复思路就非常清晰了。第一步，给user_id字段加上索引；第二步，把循环里的查询改成一条SQL批量查出数据；第三步，把连接池上限从20调到40，缓解高峰期连接争用。重新压测，同样的50并发下QPS到了380，RT降到130毫秒。继续加压到100并发，QPS到了620，TP99稳定在280毫秒以内。整个优化过程从定位到修复，只用了大半天，而核心问题就是一条缺索引的SQL加一个错误的循环调用。

这个案例可以说明一个很朴素但很重要的道理：性能优化的价值不在于堆资源，而在于做对关键选择。找到那条每次请求都在重复全表扫描的SQL并修好，比把实例翻倍更有效，也更持久。很多人遇到性能问题第一反应是扩容、加机器，但机器加完之后问题依然在，只是被暂时掩盖了，等流量增长到下一个量级，同样的瓶颈会再次爆发。

关于压测，我个人的习惯是把每次压测的结论和优化动作都记录下来，形成团队的性能基线库。下次业务上量或者服务改造，先跑一遍历史回归压测，看哪些指标恶化了、哪些优化被某个改动破坏了。性能压测的真正价值不只是这一次出了多少QPS，而是一套可以复用的“探针”，让每次发布、每个重构都能在灾难发生前提前暴露风险。

最后分享一个实操小技巧：压测的脚本和压测结果报告一定要存版本库，跟代码一起走。很多团队压完就扔，三个月后想复盘根本没数据可看。把压测脚本纳入CI/CD流程，每次重大变更自动触发一轮冒烟压测，能帮你挡掉很多线上事故。这比任何花哨的性能治理框架都有用。