Java 性能压测完整讲解

关注

原创 2026-09-15 10:09:08 193 阅读 AI 写同款· GEO 优化 ›

JMeter性能测试入门：从零搭建环境到执行首个压测脚本性能测试是确保软件系统在高负载下稳定运行的关键环节，其核心原理是通过模拟多用户并发操作来评估系统的响应时间、吞吐量和资源消耗。在众多性能测试工具中，Apache JMeter凭借其开源免费、图形化界面友好和强大的扩展能力，成为工程师进行接口测试、负载测试和压力测试的首选工具。JMeter基于Java开发，通过线程组模拟虚拟用户，结合丰富的取样器、监听器和断言元件，能够灵活构建接近真实场景的测试模型，有效发现系统瓶颈。对于Web服务、API接口和微服务架构，使用JMeter进行性能验证可以提前识别容量限制和性阅读详情

（适配你的场景：JMeter 压测 + SpringBoot + OceanBase，含指标、瓶颈定位、报告写法）

核心思路：压测不是只看 TPS，要区分：瓶颈在 Java 应用、数据库、网络，还是业务逻辑（热点锁）。你之前遇到的：TPS 暴跌、RT 暴涨、数据库连接被主动断开、100% 错误，就是典型的业务锁瓶颈，不是 JVM 本身瓶颈。

一、压测的核心目标

找到系统安全并发水位：多少并发下系统稳定，错误率 0，RT 可控
识别瓶颈：是 JVM、线程池、连接池、SQL、数据库锁、网络？
找到雪崩拐点：并发持续运行，什么时候开始出现超时、错误
验证极限能力：短时间峰值、长时间持续运行的表现（区分瞬时峰值和可持续水位）

重点区分两个概念：

瞬时峰值：短时间高并发可以扛住；
可持续水位：长时间跑，不会出现排队堆积、超时雪崩。你的热点接口就是典型：200 并发短时可以跑，长时间运行直接雪崩。

二、压测关键指标（JMeter + Java 服务，全部要关注）

1. JMeter 侧指标（客户端）

表格

指标	含义	判断标准
Samples	总请求样本数	压测持续时间越长样本越多
Average	平均响应时间	反映整体耗时，容易被长尾掩盖
Median (中位数)	50% 请求耗时	大部分请求真实耗时
P90/P95/P99	90%/95%/99% 请求耗时	最重要！看长尾，排队、锁等待会把 P99 拉高
Min/Max	最小 / 最大响应时间	Max 暴涨代表出现严重排队阻塞
Error%	错误率	业务要求一般 0%；>0 代表已经出现故障
Throughput(TPS)	每秒完成请求数	并发上涨，TPS 不再上涨，代表已经触达瓶颈

你的现象：并发 200 不变，TPS 不涨，P99、Max 持续上涨，错误率从 0→100%，就是排队堆积，业务雪崩。

2. Java 应用侧指标（JVM + 应用）

JVM 堆内存、GC 情况

YoungGC、FullGC 频率；FullGC 频繁，会造成 STW，RT 飙升、TPS 抖动
堆内存占用：持续上涨不回收 → 内存泄漏

线程指标

业务线程池：活跃线程、队列等待任务数；队列堆积代表线程池不够
JDBC 连接池 (Hikari)：活跃连接、pendingConnections（等待获取连接的队列）

pendingConnections>0：拿不到数据库连接，请求排队，RT 上涨。

CPU

应用 CPU 高：业务代码、循环、序列化、复杂计算；
应用 CPU 很低：大量阻塞等待（等待数据库锁、IO），就是你当前场景。

你这次压测：Java 服务 CPU 不高，但是 RT 暴涨，说明线程都在阻塞等待数据库行锁。

3. 数据库侧指标（OceanBase）

资源：CPU、内存、IO；
会话：活跃会话、锁等待事件 row lock wait；
事务：长事务、事务重试、回滚次数；
数据库参数：ob_trx_timeout事务超时、row_lock_wait_timeout行锁等待超时。

重点：数据库 CPU 不高，但是大量 row lock wait，就是热点行锁瓶颈，不是数据库硬件扛不住。

三、压测常见瓶颈分类（对照你的场景）

类型 1：JVM 瓶颈（Java 代码本身）

现象：CPU 很高，频繁 FullGC，TPS 上不去，RT 抖动。原因：内存泄漏、大量对象创建、复杂计算、序列化反序列化过重。排查：jstat、jmap、arthas。

类型 2：应用线程池瓶颈

现象：业务线程池队列堆积，活跃线程打满。原因：线程池 core/max 设置过小，请求排队。

类型 3：数据库连接池瓶颈 (Hikari)

现象：pendingConnections持续大于 0；原因：连接池最大连接数不够，大量线程等待拿 DB 连接。

类型 4：数据库资源瓶颈（CPU/IO 打满）

现象：数据库 CPU、IO 跑满，SQL 执行慢。原因：缺少索引、大 SQL、全表扫描。

类型 5：业务锁瓶颈（你遇到的场景！重点）

数据库 CPU、IO 都不高，但是大量row lock wait行锁等待； Java 服务 CPU 很低，线程全部阻塞等待数据库锁；并发不增加，但是 RT 持续上涨，持续运行后触发事务超时，数据库主动 kill 会话，连接断开，全部请求超时。

这个是业务逻辑瓶颈，不是硬件瓶颈。现象：数据库集群没有宕机，但是会话被主动断开。

四、完整压测执行流程（标准步骤）

环境准备

隔离测试环境，不要和生产共用；
预热：先跑几分钟，JVM 预热、缓存加载；
记录基线：低并发下，RT、TPS、GC、数据库指标作为基准。

阶梯加压（推荐）

阶梯加压：100 →150 →200，每一档持续跑足够时间，观察指标。每一档：观察：TPS 是否稳定，P99 是否上涨，错误率是否为 0，数据库锁等待。当发现 P99 持续抬升，代表已经进入排队状态（软雪崩）。

持续稳定性压测（关键！你做的这个）

到达临界并发后，不增加线程，保持固定并发持续跑。观察：会不会随时间，RT 持续上涨，最终出现超时错误（硬雪崩）。很多人只测短时间，看不到这个问题。

出现异常后，立刻停止压测

一旦错误率 > 0，不要继续硬跑，避免大量事务回滚，污染测试环境。

复盘分析

看 JMeter 指标；
看 JVM GC、线程池、Hikari 连接池；
看数据库审计视图 GV$OB_SQL_AUDIT，看等待事件、错误码；
区分瓶颈位置。

五、压测报告结构（可直接套用）

1. 测试目的

验证接口在不同并发下的性能表现，识别系统瓶颈，确定安全并发水位。

2. 测试环境

应用版本、JVM 参数；
数据库版本、参数；
压测工具 JMeter。

3. 测试场景

阶梯加压 + 固定并发持续稳定性压测。

4. 测试结果

各并发下 TPS、RT (P95/P99)、错误率；
关键现象：例如 200 并发持续运行，发生锁排队，触发数据库事务超时，会话被断开，全部请求超时。

5. 瓶颈定位

示例（你的场景）：数据库集群 CPU、IO 资源未耗尽，瓶颈为单行热点行锁竞争；Java 线程大量阻塞等待数据库锁，不是 JVM、硬件资源瓶颈。数据库集群未宕机，连接断开为 OB 事务超时保护机制，主动终止长事务会话。

6. 容量结论

安全水位：XX 并发，可以长时间稳定运行；
危险水位：XX 并发，短时可运行，长时间持续会发生雪崩，不建议业务常态化使用。

7. 优化建议

热点行优化：分片打散、接口串行排队、限流；调优连接池、事务超时参数等。

六、常用排查工具（Java 性能）

Arthas（线上 / 压测环境首选）

thread：查看线程状态，大量 WAITING/BLOCKED，说明阻塞等待数据库；
gc：查看 GC 情况；
dashboard：概览 CPU、内存、线程。

jstat：看 GC 统计
jmap：dump 堆内存，排查内存泄漏
数据库侧：GV$OB_SQL_AUDIT 看 SQL 等待事件、错误码。

七、常见误区（踩坑点）

❌ 只看平均 RT，忽略 P99；

平均 RT 好看，P99 暴涨，代表大量请求排队，已经有隐患。

❌ 只测短时间压测，不做持续稳定性压测；

热点锁场景短时间没事，跑久了才会雪崩。

❌ 看到报错就认为数据库宕机；

集群活着，只是会话被超时 kill。

❌ 并发越高 TPS 越高；

到达瓶颈后，并发继续增加，TPS 不再上涨，RT 暴涨，错误率上升。

八、结合你的实际案例总结

接口是单行热点更新： 100 并发：稳定； 150 并发：出现锁排队，P99 抬升，错误率 0； 200 并发：短时可以运行，持续跑，锁队列不断堆积；事务等待超过ob_trx_timeout，数据库主动 kill 会话，连接断开，全部请求超时，TPS 暴跌。瓶颈：业务行锁竞争，不是 JVM、不是数据库硬件资源