1. 压测到底解决什么问题先分清四种压测类型我做Java性能压测这些年最深的一个体会是压测不是拿工具把请求怼上去、看系统什么时候挂掉那么简单。它真正解决的是线上流量还没到我就已经知道系统会在哪里先倒下的问题。你可以在凌晨三点从容地观察CPU飙到100%、Redis连接池被打穿、数据库慢SQL把整个链路拖垮而不是在大促当天的流量高峰里手忙脚乱地翻日志。这种提前量就是压测最大的价值。1.1 为什么线上系统总在流量高峰掉链子很多团队对性能的认识停留在代码能跑就行直到线上出事故才意识到问题的严重性。我见过一个典型的例子某个订单系统的接口平时扛200 QPS没问题结果活动预热阶段流量涨到800 QPS系统直接雪崩。事后定位发现问题根本不在接口代码而在一个毫不起眼的定时任务——它每5分钟做一次全表扫描平时没人在意但流量一上来数据库锁竞争加剧定时任务和业务查询互相拖累最后所有线程都堆积在数据库连接池等待上。这就是压测存在的意义它让你在系统还健康的时候就从外部流量视角看到内部资源的真实承载边界。压测过程中发现的问题往往不是某个接口写崩了这种显性Bug而是延迟、排队、资源竞争、GC停顿等只在高并发下才暴露的隐性缺陷。这类问题最大的特点是单测、功能测试、代码评审全都发现不了只有把流量真实地打上去才能让它们浮出水面。1.2 压力测试、负载测试、容量测试、稳定性测试的选型差异很多人把压测当成一个笼统的词实际上不同的测试类型解决的是完全不同的问题。我平时在团队里会按这张表来选型测试类型核心问题典型做法关注指标压力测试系统在多高流量下开始出错或崩溃持续加压直到错误率上升错误率、TPS拐点、RT激增点负载测试系统在预期流量下能否稳定运行按预估峰值流量并发运行P99 RT、TPS达标率、资源利用率容量测试系统的最大承载能力是多少阶梯式加压找到吞吐量上限最大TPS、最大并发数、资源瓶颈位置稳定性测试系统在持续压力下是否会劣化用70%~80%的极限流量跑数小时内存趋势、GC频率、连接池回收情况这里有一个经验之谈线上事故中最常见的不是瞬间压垮而是持续运行几小时后缓慢劣化。比如内存泄漏、连接池回收不及时、临时对象过多导致GC频率持续升高这些都需要稳定性测试才能暴露。我见过一个团队只做压力测试每小时只测10分钟结果每次测试都达标但上线跑了两天OOM了——就是因为长尾状态下的资源堆积根本没进过测试视野。所以选型时别只盯着压力测试一项。如果目标是排查性能瓶颈优先做负载测试如果要评估系统能接住多大的流量做容量测试如果要验证几天内的稳定性做稳定性测试。四类测试是互补关系而不是替代关系。2. 正式压测前必须做好的三件事环境隔离、数据造备、监控铺底压测结果要让人信服前置准备比压测本身更关键。很多压测报告被质疑数据不可信原因往往不在工具而在三类准备没做到位。2.1 压测环境和生产环境的差异是最容易踩的坑理想状态下压测环境要和生产环境在硬件配置、网络拓扑、依赖组件版本上完全对等但实际情况很难做到。比较实际的策略是明确记录差异并在结论中补偿。我在一家中型公司做压测时测试环境的应用服务器是4核8G生产是16核32G数据库配置也不一样。这种情况下如果直接拿测试环境的TPS当生产容量误差会非常大。我的做法是先在同一套压测方案里跑两个环境的基准结果算出一个经验换算系数——比如测试环境单机500 QPS生产单机2000 QPS系数就是4。之后每次优化验证都先看测试环境相对提升比例再换算到生产预估。虽然这个系数不够精确但比拿测试环境结果直接上线决策靠谱得多。还有一个容易忽略的坑是容器环境下的资源隔离问题。如果应用跑在Docker或Kubernetes里压测时要确认CPU限额、内存限额是否和生产一致有没有被其他容器的资源争抢干扰。我看过一个案例压测时应用的QPS忽高忽低排查半天发现是同宿主机上有另一个容器在做大量IO操作产生了资源竞争。所以压测前最好在高负载时段先做一次资源基线检测确认环境没有邻居噪声。2.2 压测数据怎么造才不失真压测数据失真对结果的误导比我见过的任何环境问题都更隐蔽。最典型的两种失真场景数据量太小导致索引失效问题没暴露。生产环境某张表可能有上千万行压测环境只有几万行。这时候SQL走全表扫描也很快索引问题完全看不出来。但同样的SQL上线后面对千万级数据量立刻变成慢SQL。数据分布不均匀导致缓存命中率失真。压测工具如果用随机参数打接口而生产环境的请求参数往往符合特定分布例如热点数据集中在少数几个ID上那测试出来的缓存命中率会偏离真实的缓存效果Redis单点压力也测不准。我的造数策略有两步第一步从生产库做脱敏抽样导入保证数据量和数据分布都接近真实第二步针对热点场景单独造一批集中分布的数据模拟真实请求倾斜。压测脚本里的请求参数不能全部随机而是按一定比例走热点参数这样才能还原真实的缓存命中和数据库访问模式。2.3 一套压测必看的监控指标清单监控没铺好就开始压测等于闭着眼睛开车。我压测时一定会同时盯住三个层面的指标应用层、JVM层、基础设施层。监控层面关键指标为什么要看应用层QPS、RT均值/P99/P999、错误率这些是结果的直接呈现P99比均值更敏感地反映用户体验JVM层GC频率与耗时、堆内存使用趋势、线程数高并发下GC停顿会造成RT尖刺内存缓慢增长预兆泄漏基础设施层CPU、内存、磁盘IO、网络带宽、连接数任何一项资源被打满都可能成为系统真实的瓶颈点工具选型上我的标配组合是Prometheus Grafana采集系统指标Arthas做线上诊断JFRJava Flight Recorder做深度JVM剖析async-profiler生成火焰图。压测开始前先确认这些工具的采集链路是通的不然压测中间发现问题要定位时才发现监控数据没记录下来那就白跑了。3. 压测执行节奏从单机探底到容量极限压测不是直接把并发线程数拉到5000看系统崩不崩那样得到的信息很有限。我习惯分三个阶段走每个阶段解决一个具体问题。3.1 基准测试先把系统的底摸清第一阶段是基准测试目标是确定系统的单线程或低并发性能上限。我用JMeter先设10个线程跑一轮观察每个请求的耗时和吞吐。这一步的作用是排除网络和环境干扰看清一个请求从进入到返回应用自身到底耗费了多长时间。基准测试里我会特别关注RT的构成拆分。如果发现一个接口平均耗时800ms而其中业务逻辑只占50ms、缓存读取占200ms、数据库查询占550ms那么后续压测的重点就非常清晰了——数据库访问是大头。这时候就算把应用QPS压到很高数据库一饱和整个链路立刻崩。相反如果业务逻辑本身消耗400ms就该先从代码优化入手而不是盲目调大连接池。3.2 梯度加压找到临界点而不是模糊的上限第二阶段做负载测试用阶梯式加压方式找到系统的临界点。我的做法是从100并发开始每轮递增50并发每轮持续3分钟观察TPS和RT的变化曲线。记录下两件事TPS停止线性增长的那个点。在并发数到达某个值之前TPS应该随着并发数近似线性上升一旦上升速度放缓或不再上升说明某个资源开始饱和。RT开始急剧上升的那个点。这是系统进入排队状态的信号比TPS拐点更灵敏。很多系统在TPS还没下降时RT已经翻了几倍用户体验已经变差了。这两条曲线交叉的区域往往就是系统的最佳工作区间。我会用这个区间的数据去推算容量评估比如在可接受的P99 RT内这个服务最多支撑多少QPS。3.3 稳定性测试长时间运行才暴露的GC和内存问题第三阶段是做稳定性测试我用能用到的最大资源跑4到8小时重点盯着几个趋势曲线堆内存是平稳波动还是一路爬升Young GC频率有没有越来越快Full GC有没有突然出现为什么必须跑这么久因为很多问题是积少成多的。比如一个接口每次请求都会创建一个缓存对象但解引用不彻底在低并发下这个对象很快被GC回收看不出异常但在高并发下对象创建速率大于回收速率堆内存就会螺旋上升几个小时后触发Full GCRT出现大面积尖刺。这种问题跑10分钟的短压测根本暴露不了。稳定性测试的判定标准我一般定三条错误率为0或可接受阈值内、P99 RT波动幅度不超过正常均值的20%、内存曲线没有持续上升趋势。三条全过才认为系统通过了稳定性验证。4. 问题定位的完整链路CPU、内存、线程、数据库四类典型瓶颈压测中最有价值的环节其实是问题定位。这一节我会分别拆解四类典型瓶颈的标准排查链路再用一个综合案例把整条思路串起来。4.1 CPU吃满但QPS上不去用火焰图找出热点代码CPU问题的典型特征非常直观top命令里看到应用进程CPU占用已经90%甚至100%但压测TPS还是上不去RT还在上涨。这说明CPU已经饱和请求在处理请求的计算上耗尽了所有时间片。我的标准排查链路是定位进程和线程。用top -Hp pid找到CPU占用最高的线程PID把这个PID记下来。把线程PID转成十六进制。JVM的线程栈里使用的是十六进制线程号执行printf %x pid转换。导出线程栈。执行jstack pid thread_dump.log在dump文件里搜索刚才转换出的十六进制线程号定位到具体线程。解读线程状态。如果看到多个线程都卡在同一个业务的代码行上说明这里是CPU热点如果线程一直处于RUNNABLE且循环执行某个JSON序列化或正则匹配那大概率这段逻辑走的是性能很差的实现。更进一步我推荐用async-profiler生成CPU火焰图。它的优势是不需要在代码里埋点直接采样Native栈和Java栈一眼就能看出哪个方法在最宽的调用栈上。火焰图的宽度就是CPU时间的占比宽度越宽、层叠越深的方法越值得优先优化。我遇到过最典型的例子一个参数校验方法里用了大量正则表达式匹配邮箱和手机号平时流量小感觉不到压测到500 QPS时CPU直接飙到90%。火焰图显示Pattern.matcher占了将近一半的CPU时间。替换成显式的字符遍历校验后CPU直接降了35%TPS翻了一倍。正则匹配是CPU热点的高频元凶遇到CPU问题先查正则。4.2 频繁Full GC和OOM用JVM监控和堆快照揪出元凶GC问题在压测中几乎必然会遇到但关键要区分正常的对象分配回收和异常的堆内存膨胀。我的定位链路是先看GC趋势。压测期间用jstat -gcutil pid 1000 1000每秒采样一次观察FGCTFull GC耗时、FGCFull GC次数、S0/S1/E各区使用率。如果Full GC次数快速上升且每次耗时都超过几百毫秒说明堆内存快被占满了对象在持续堆积。导出堆快照。执行jmap -dump:formatb,fileheap.hprof pid把当前堆内存快照导出来。注意在OOM还没发生时就要抢时间导出等OOM之后再导往往进程已经没了。用MAT或JProfiler分析。打开堆快照后第一眼看Dominator Tree支配树里最大的几个对象是谁再看Leak Suspects报告它会自动帮你圈出疑似泄漏的根路径。有一个实战案例很典型某服务压测时堆内存持续爬升Full GC频率从每小时2次变成每10分钟1次。MAT分析发现一个ThreadLocal里存的用户上下文对象占据了堆内存的40%。追问根源是业务代码在请求处理完没有调用remove()清理ThreadLocal而应用用的是线程池线程复用导致每个线程都吸附了一个上下文对象不释放。修复后加了一行finally { threadLocal.remove(); }堆内存曲线从上升变成平稳Full GC直接消失了。注意不要一看到GC问题就调堆大小参数。堆调大只是把溢出的时间拉后不解决对象累积的根因。先找到谁在持有对象再决定怎么改代码。4.3 线程大量阻塞连接池和锁竞争的排查方法线程阻塞的典型现象是TPS上不去但CPU利用率不高线程dump里的线程大多处于WAITING或BLOCKED状态。这说明请求没有在被计算而是在排队等资源。排查方式主要靠线程转储分析先抓现场。压测中连续执行2~3次jstack命令间隔5秒得到的dump文件对比分析。同一线程多次出现在相同位置说明它卡死在那里了。用Arthas快速定位。如果环境允许我强烈推荐用Arthas的thread命令。执行thread -n 3能看到CPU占用最高的前3个线程执行thread -b直接定位当前被阻塞的线程正在等哪把锁、锁被哪个线程持有。这是最省力的一步。区分两类阻塞场景锁竞争线程栈里能看到大量线程卡在synchronized或Lock的获取处。需要分析锁的持有时间为什么这么长临界区里有没有做耗时操作比如IO、远程调用、大循环。解决思路是缩小锁粒度、改用ReadWriteLock或ConcurrentHashMap等无锁结构。连接池等待线程卡在getConnection方法附近说明数据库或Redis连接池已经空了。这时不只是看应用日志还要去查数据库端的max_connections和当前活跃连接数确认瓶颈到底在连接池配置还是数据库本身的容量。连接池等待是我在压测里遇到最多的一种线程阻塞。很多团队把连接池的最大连接数往大了调以为就万事大吉结果压测时数据库先撑不住反过来拖垮应用。连接池的大小不是越大越好要结合数据库的最大连接数和业务的单个请求占用连接时长来综合定。4.4 数据库扛不住从慢SQL到连接数耗尽数据库问题在压测中的表现往往比应用自身更先暴露因为几乎每个业务接口都依赖数据库。排查我却建议先从数据库端入手而不是在应用端折腾。开启慢查询日志压测结束后把压测时段的慢SQL捞出来按执行次数和耗时排序。对慢SQL跑执行计划用EXPLAIN看有没有走索引、扫描行数是不是爆炸。我见过最多的压测才暴露的问题是查询条件里的字段没有索引或者查询用LIKE %xx导致索引失效小数据量测试时根本看不出来数据量大压测时立刻变成全表扫描。看数据库连接数。应用侧连接池打满数据库侧同样能看到大量连接堆积。用SHOW PROCESSLIST可以看到当前有哪些SQL在跑、跑了多久、锁等待多不多。如果发现大量Waiting for table metadata lock说明有人在做DDL操作没提交把业务查询堵死了。这里有一个容易被忽略的经验数据库性能问题的根源很多时候不在数据库而在应用怎么用数据库。比如一次请求里发了N次SQL查询而没有做批量处理或者先查一次再用结果循环查了N次N1问题。压测前用Arthas的trace命令追踪一下数据库调用次数比直接优化SQL性价比更高。4.5 一个综合案例压测时TPS只有预期一半问题在哪最后用一个我印象很深的案例把上面的方法串成一条完整的排查链路。当时我们压一个订单查询接口压测目标是单机800 QPS但实测跑到420 QPS左右就再也上不去了错误率开始升高RT从平均60ms飙到600ms。第一反应是代码有问题于是按流程走top一看应用进程CPU只有35%不像CPU瓶颈。jstack看线程栈发现大量线程阻塞在getConnection等待数据库连接。查连接池配置最大连接数64业务单个请求正常执行只要50ms理论上不该打满。再看数据库端SHOW PROCESSLIST发现几百个慢SQL在跑每条耗时1~2秒。关键转折点在那几条慢SQL上。正常业务查询不应该这么慢单独执行发现单条SQL很快但在压测并发场景下却变得异常慢。再看执行计划查询条件里的created_at字段有索引但压测脚本的查询时间范围是全量数据命中数据量太大MySQL选择了全表扫描——这是索引选择策略和统计数据在数据量临界点时的误判单测场景根本触发不了。我们做了两步修复第一步给SQL加了FORCE INDEX强制走索引并把查询范围按业务实际情况做了限制第二步在查询语句前直接优化了执行计划使用机制让MySQL的统计信息重新校准。优化后同样的压测方案TPS直接到了850 QPSP99 RT从600ms降到80ms。这个案例给我的最大启发是瓶颈定位不要停留在看CPU、看内存的面上线程栈指向的地方只是症状表现真正的根因往往在第三层第四层。5. 优化不是玄学从代码热点到架构取舍的落地顺序定位到问题之后优化要讲方法论。很多团队喜欢凭感觉改代码或者一上来就谈加机器、上缓存这都是本末倒置。我的优化顺序永远是从最廉价的代码级优化一步步走到架构级改造。5.1 先别急着优化让火焰图决定改哪里优化和排查之间有一道分界线排查是找哪里有问题优化是改影响最大的地方。性能优化的一个铁律是二八法则——80%的瓶颈集中在20%的代码路径上。如果不看火焰图就动手改业务代码很可能浪费几天时间优化了一段根本不热门的代码真正的热点还在原地。我拿到火焰图后的判断标准很简单从最宽的调用栈顶往下找看有没有可以用更廉价方式替代的操作。常见的热点从高到低排序序列化/反序列化、正则匹配、日志输出、集合排序、反射调用、字符串拼接。这些都是隐形开销单次执行毫秒级不到但在高并发下会被无限放大。5.2 代码层消除热点路径上的隐形开销代码级优化是性价比最高的手段不需要动架构改完立即见效。我总结几个高频场景减少重复计算循环里如果有对同一结果的重复获取提到循环外。看似简单我在真实代码里见过不下二十次。避免无意义的对象创建每次请求都new一个很大的临时对象如果这个对象可以复用就改成池化或静态字段。这个改动直接影响GC压力比调JVM参数有效得多。用批量操作替代循环单次操作for循环里逐条update数据库改成一条batch update网络IO次数从N次降到1次效果立竿见影。字符串拼接别用在循环里用StringBuilder避免产生大量中间字符串对象。这在JDK 8以前是绝对有效的手段在JDK 9编译器做了优化后效果差一些但循环内拼接仍然建议用StringBuilder。代码级优化有一个原则我要强调每次只改一处改完立刻重新压测。不要一次改十个点改完不知道是哪个点起了作用。性能优化本质上是个AB实验每一处改动都应该有单独的验证结果。5.3 并发层线程池参数、锁粒度与无锁化并发层面的优化核心是让资源利用率上来的同时不制造新的竞争热点。我通常会从线程池和锁两个方向入手。线程池参数不是配置一个corePoolSize和maxPoolSize就完事的。我压测时会看线程池的队列积压情况——如果队列持续增长说明线程数不够如果线程长期空闲而QPS没上来说明线程数多了或者瓶颈在别处。一个我实践下来比较稳妥的调参思路是先估出单个线程能处理的QPS基数再用目标QPS除以基数得到一个初始线程数再在压测中微调。线程不是越多越好过多线程反而会增加上下文切换开销CPU使用率上去了QPS却不涨就是过配置的信号。锁的优化优先级从高到低我排为无锁 读写锁 分段锁 最小粒度同步块。能用ConcurrentHashMap就不上synchronized大锁能拆细锁就不锁整个方法能读多写少就用ReadWriteLock。最常见的反例是一个高频的读方法为了一个不常变的配置更新整个方法都加了synchronized压测时读请求全部串行化QPS直接掉一个数量级。5.4 数据访问层减少行数、命中索引、批量化数据库优化的核心目标是让数据库做更少的工作而不是让数据库更强壮。数据访问层我按三个步骤操作只取需要的字段和行数。SELECT *在高并发场景下是灾难多余的字段传输浪费网络IO多出的行数放大数据库扫描成本。改成明确字段、加上LIMIT效果最直接。让索引真正命中。压测后把所有慢日志里的SQL拿一遍逐一检查EXPLAIN的type字段。ALL全表扫描是红线ref、range、eq_ref都算可接受const是最理想。组合索引的字段顺序要和查询条件匹配注意最左前缀原则。这里有一个常见的冤枉索引本身没问题但函数包裹了索引列比如WHERE DATE(create_time) 2024-01-01这时候索引完全失效改成区间查询create_time BETWEEN 2024-01-01 00:00:00 AND 2024-01-01 23:59:59就恢复正常了。批量化数据库访问。压测场景下最怕循环单查。把N次单条查询合并成一次IN查询把N次单条更新合并成batch update这种改动对数据库的连接占用和IO次数下降是数量级的优化。5.5 架构层缓存分层与异步化的边界走到架构层做优化说明代码层和并发层的余地已经不大了。但架构改造动辄涉及多个服务、中间件的协同改动我建议遵循一个原则先做风险最低、收益最明确的一步不要一上来就搞大重构。缓存分层本地缓存Caffeine只解决单机节点的热数据访问Redis缓存解决集群共享的数据访问。到底用哪一层取决于数据的变更频率和对一致性的容忍度。变更频繁的数据如果硬塞缓存反而会因为不断失效和回源引入新的延迟。我见过最成功的缓存优化是把一个查详情且很少变更的接口加了一层Caffeine本地缓存命中率80%以上数据库负载直接降了60%。异步化不是所有请求都必须同步返回结果。对于发送通知、记录日志、更新统计这类非核心操作可以用消息队列或者线程池异步执行把同步等待的时间从请求链路里摘掉。异步化的边界在于业务能否容忍最终一致。如果不能强行异步化只会引入数据不一致的线上事故。架构级优化的通用验证方法是改完后压测对比同一个指标的基线和优化后数值比如TPS提升比例、P99 RT下降比例、数据库连接数峰值下降比例。这些数据会实际告诉你架构改动到底值不值得。6. 把压测成果沉淀成团队资产性能基线与回归机制压测做完、问题优化完还不算结束。如果压测结果只存在某个人本地的报告里下一次项目上线前又要从零开始那就太浪费了。我习惯把压测的产出变成团队可复用的资产。6.1 建立性能基线档案每次压测结束我会把以下几项整理成一个脑图结构存的文档本次压测的环境规格机器配置、JDK版本、关键组件版本压测脚本和参数并发数、持续时长、数据准备情况关键性能指标TPS、P99 RT、错误率、GC情况、CPU峰值瓶颈定位过程发现的问题、定位方法、根因分析优化方案与验证结果每一处改动对应的前后数据对比这份档案的意义在于团队迭代三个月后再有人问这个接口现在能扛多少QPS不用重新压一遍直接查档案就有答案。同时下次再压测时用同一套基线数据做对比可以快速判断性能是变好了还是劣化了。6.2 让压测进入日常研发流程我在实践中最有效的做法是把性能压测接入到CI/CD流程里每次上线前跑一次轻量级的性能回归测试。这里的轻量级是关键词——完整压测的成本太高不适合每次都跑但可以用一个小时跑一个固定的基准场景对比基线的QPS和RT。只要新代码导致关键接口的TPS下降超过10%或者P99 RT上涨超过15%就阻断合并要求开发者先自查。这个机制在团队初期推行时会有点阻力但坚持跑两三个迭代后大家就会形成写代码时顺手注意性能的习惯因为没人想在上线前被压测脚本卡住。我最明显的感受是这个门槛设立了半年后线上因为性能劣化导致的事故率下降了八成。6.3 我个人踩过最深的坑和实验心得最后分享几个只有实际跑压测才会踩到的细节。先说深坑压测工具的瓶颈也可能是系统瓶颈。早期我们用JMeter打流量时发现目标服务的CPU还没怎么动TPS就上不去了。排查完才发现JMeter所在的施压机自己先扛不住了——线程数开太多压测工具本身的线程调度成了瓶颈。后来施压机改用多台部署或用wrk这类更轻量的工具才把问题澄清。再说一个原则压测前一定先把压测脚本在小流量下自测几遍。我有一次用JMeter跑压测脚本结果全链路报401排查发现是鉴权Token没处理好。这个错误浪费了我整个上午。后来我在脚本里单独加了一个冒烟测试步骤先小并发验证接口返回正常再上大并发正式压测这个习惯帮我省下大量白跑的时间。最后关于心态压测这件事不要追求一次压测就把所有问题都找出来。每一次压测的目标可以很小——这次只看某个接口的极限TPS下次只看稳定性下的内存趋势。性能优化本身是个持续迭代的过程每轮压测发现并解决一两个真问题比一次性做完所有检查更有现实价值。压测报告不是你给领导的PPT而是你下一次优化时最有用的起点。