做了这么多年性能压测工具换了一茬又一茬JMeter 一直留在我主力名单里。理由很简单开源免费纯 Java 实现装个 JDK 就能跑图形界面和命令行模式都能用。很多人第一次接触压力测试就是从 JMeter 开始的但真正能把它用顺手的却不多——大多数人是会点“添加线程组、添加 HTTP 请求、点运行”可一遇到并发上不去、报告看不懂、参数化出错就卡壳了。这篇文章我打算把 JMeter 做压力测试的完整流程捋一遍从环境安装、压测方案设计、编写脚本到执行压测、分析报告、排查常见问题一条龙讲清楚。之前有个项目是单节点 k8s 上的若依微服务整套环境迁移到阿里云 ECS迁移完以后就是用配套 JMeter 脚本做高并发测试验证云上环境真实承载能力这套流程我当时完整跑过一遍里面不少细节都是真金白银踩出来的。无论你是刚入行的测试新人还是被临时拉去负责压测的后端开发按这个顺序走能少走不少弯路。1. 压测前先想清楚你到底在测什么很多人一上来就打开 JMeter 开始点根本的问题还没问过自己这次压测的目标是什么是想验证系统能不能扛住预期峰值还是想找到系统的瓶颈点或者是想对比一下迁移前后两台机器的性能差异目标不同压测方案完全不一样。1.1 性能测试的三种基本形态别搞混拿“压力测试”这个关键词搜索的人很多但很多人分不清压力测试、负载测试和容量测试的区别。这三者经常被混着叫其实侧重点很不一样负载测试让系统在预期的正常负载下运行验证各项指标是否满足要求。比如系统设计目标是支持 500 并发那就压 500 并发看通过率和响应时间是否达标。压力测试逐步增加负载超过正常设计指标把系统压到极限甚至崩溃找出系统能承受的最大临界值。比如从 500 并发加到 2000 并发观察哪个点开始出现大量超时和报错。容量测试通常配合压力测试来做目的是确定系统在保证 SLA服务水平协议的前提下最多能支撑多少用户或多少业务量为后续扩容提供依据。我那次做若依微服务云上验证就属于“容量测试压力测试”结合的场景先通过逐步加压找到云上环境的承载上限再把这个上限和业务预期的峰峰值对比给出“够用”或者“需要扩容”的结论。测试类型选错了后面所有数据都没有参考价值这是压测新手最容易踩的第一个坑。1.2 制定压测方案的四步准备法实操之前我会先花半小时把方案写清楚别嫌这点时间浪费后面能省一整天。第一步确定关键指标。吞吐量TPS/QPS、平均响应时间、90% 或 95% 响应时间、错误率这四个是必须看的。吞吐量反映系统处理能力响应时间反映用户体验错误率直接决定这次压测算不算通过。第二步估算并发数。如果业务有历史数据直接取高峰时段在线用户数作为参考。没有历史数据时可以用经典估算公式平均并发数 C n × L / T其中 n 是考察时间 T 内的用户数L 是每个用户平均使用时长。举个例子某系统在 1 小时内有 6000 个用户访问平均每个用户使用系统 5 分钟那么平均并发 C 6000 × 5 / 60 500。峰值并发一般按平均并发的 3 到 5 倍估算你可以根据业务特点取系数。第三步准备测试数据。账号、订单、商品这些数据量要够尽量贴近生产环境的数据分布。用别人的压测脚本时尤其要注意很多脚本跑出来的数据不准就是因为测试库里的数据量只有几百条跟生产环境千万级的数据量完全不是一个数量级。第四步设计场景。单接口压测、全链路压测、混合场景压测目的不一样。如果只是想验证某个接口的瓶颈单接口压测就够如果要验证整套微服务环境就得走全链路把登录、查询、下单、支付这些核心接口串起来按比例混压。我在若依微服务迁移验证时用的就是混合场景按业务比例把几个核心接口一起压才能真实反映整套环境的承载能力。2. 环境准备从 JDK 到 JMeter 安装部署工欲善其事必先利其器。JMeter 本身不需要安装解压即用但对 JDK 版本有要求这块很多新手会在第一步就卡住。2.1 JDK 版本选择是第一个坑JMeter 5.x 最低要求 JDK 8但不同小版本有细微差异。比如 JMeter 5.5 官方要求 Java 8JMeter 5.6 开始对 JDK 版本的支持范围更宽。如果你的 JMeter 版本和 JDK 版本不匹配最常见的表现就是启动时提示 UnsupportedClassVersionError或者运行过程中一些插件莫名其妙的报错。实际项目中我推荐用 JDK 11 或 JDK 17原因很实际如果你用的 JMeter 版本较新JDK 8 在高并发下容易出现 GC 频繁、压测结果抖动的问题。而且新版 JMeter 重复利用了 JDK 11 的一些特性跑分布式压测时更稳定。安装完 JDK 后记得在命令行执行 java -version 确认版本没问题再继续下一步。很多人 JDK 装好了但没配环境变量导致双击 jmeter.bat 一点反应都没有十有八九就是这个问题。2.2 下载安装与目录结构速览JMeter 官网下载页有 Source 和 Binaries 两种包直接下载 Binaries 的 zip 包即可无需安装。下载完解压到指定目录比如 D:\apache-jmeter-5.6.3进入 bin 目录Windows 双击 jmeter.bat 启动图形界面Linux/Mac 运行 ./jmeter 启动解压后目录里几个关键目录要认识bin 目录存放启动脚本和配置文件lib 目录存放所有依赖 jar 包第三方插件也装在这里logs 目录是运行日志extras 目录提供了一些辅助脚本。我建议把 bin 目录加到系统环境变量 PATH 里这样后续用命令行跑压测时可以直接敲 jmeter -n -t xxx.jmx不用每次切到 bin 目录。2.3 三个配置改动让 JMeter 更好用以下三个改动用一次爽一次属于提升使用体验的必备操作。第一界面字体太小。新版 JMeter 在 Windows 高分屏下字体小得可怜。点击菜单 Options - Look and Feel - System改成系统风格后字体基本就是系统默认风格会舒服很多。如果想进一步调整字号可以在 bin 目录下的 jmeter.properties 里找 jsyntaxtextarea.font.size 和 jmeter.hidpi.mode 等配置项把字体设大一点。第二默认语言改成中文。在 jmeter.properties 里找到 language 配置项去掉注释改为 languagezh_CN重启后界面就是中文。我第一次用的就是中文界面对熟悉组件位置很有帮助但看网上资料时要留个心眼很多教程的截图是英文版组件英文名要能对上。第三加大 JVM 堆内存。JMeter 默认堆内存只有 1G压测时如果脚本里用了大量参数化或者监听器开得太多很容易内存溢出。找到 bin 目录下的 jmeter.batWindows或 jmeterLinux修改 HEAP 参数HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m如果压测机内存大可以设到 8G但注意堆内存也不是越大越好过大的堆会导致 GC 停顿变长。客户端压测机建议 8G 内存起步实测下来比较稳。3. 第一个压测脚本线程组、HTTP 请求与监听器环境搞定以后就可以开始搭建第一个压测脚本了。我习惯把压测脚本当作一个小项目来管理测试计划名称、线程组配置、HTTP 请求参数、监听器输出每一层都有明确的目的这样后续维护起来也方便。3.1 线程组参数并发、启动时间与持续时间线程组是整个压测脚本的核心容器所有请求都要放在线程组里执行。右键测试计划 - 添加 - 线程用户 - 线程组打开后重点关注三个参数线程数模拟的并发用户总数。注意它指的是“总线程数”配合下面的循环次数决定总请求量。Ramp-Up 时间所有线程在多少秒内全部启动完成。比如 100 线程Ramp-Up 设为 10 秒平均每秒启动 10 个线程。模拟真实场景时不要设为 00 代表瞬间全部启动对服务器冲击太大跟真实用户逐步进入的行为不符。循环次数每个线程执行脚本多少次。勾选“永远”并加上持续时间可以按时间维度控制压测时长这种写法更推荐。比如线程数 100勾选永远持续时间设为 300 秒JMeter 会持续以 100 并发跑 5 分钟时间到了自动停止数据也更容易统计。我常用两种线程组配置模板。短期摸底用线程数 目标并发Ramp-Up 并发数 / 20循环次数 1跑完一轮看吞吐量大概在什么水平。正式压测用线程数 目标并发勾选永远调度器配置持续时间 600 秒让系统在目标并发下稳定运行一段时间观察指标是否平滑。3.2 HTTP 请求配置与参数传参在线程组下添加 HTTP 请求这里要填的内容不多但每一项都很关键协议http 或 https服务器名称或 IP填域名或者 IP注意不要带 http:// 前缀端口号默认 80http和 443https如果服务跑在自定义端口要填上方法GET、POST、PUT 等路径接口路径参数GET 请求填参数POST 请求如果是表单格式也可以在这里填如果是 JSON 格式就在“消息体数据”里填新手经常犯的错误是把整个 URL 都填到“服务器名称或 IP”里。填服务器名只写域名或 IP路径和参数各就各位一是规范二是后面要做参数化时更方便。比如压测登录接口服务器填 app.example.com路径填 /api/login参数里填 username 和 password清晰明了。如果请求需要携带请求头比如 Content-Type: application/json 或者 Authorization 认证信息在线程组下添加 HTTP 信息头管理器在里面统一配置。注意请求头如果有公共的内容放在线程组级别可以让下面的所有请求都继承不用每个 HTTP 请求单独配置。3.3 监听器怎么选聚合报告、察看结果树与图形结果监听器负责收集和展示测试结果。常用的有三个察看结果树展示每个请求的详细数据包括请求内容、响应内容、响应时间。调试脚本阶段必开但正式压测时建议关掉因为它会把所有响应都暂存在内存里超高并发下内存一下子就爆了。聚合报告最核心的监听器汇总展示吞吐量、平均响应时间、中位数、90% 响应时间、最小最大响应时间、错误率等指标。正式压测时主要看这个报告。图形结果将响应时间和吞吐量等数据绘制成曲线图适合观察性能趋势。看整体走向比较直观但数据精度不如聚合报告。实战经验正式压测时我会在脚本里放一个聚合报告和图形结果但不会开察看结果树。压测结束后再单独查看日志文件或者把错误请求输出到文件里分析。因为察看结果树在高并发下对 JMeter 自身性能影响太大我在一次压测中就吃过这个亏开了察看结果树以后客户端 JMeter 首先扛不住CPU 跑满压测数据全偏了。3.4 命令行跑压测告别图形界面瓶颈用图形界面跑压测不是不行但 JMeter 本身也是 Java 程序界面渲染、结果树展示都要消耗资源。并发一高客户端自身先成为瓶颈。正确的做法是命令行模式跑压测jmeter -n -t test_script.jmx -l result.jtl -e -o report_dir其中 -n 表示非图形界面模式-t 指定脚本文件-l 指定原始结果输出文件jtl 格式-e 生成 HTML 报告-o 指定 HTML 报告输出目录。跑完后打开 report_dir 下的 index.html就能看到一个完整的 HTML 可视化报告图表比聚合报告更直观。命令行模式还有一个好处是可以做压力递增。先用 100 并发跑 5 分钟拿到一组数据再用 200 并发跑 5 分钟拿到另一组数据配合不同时间段的 jtl 文件可以看出系统吞吐量随并发变化的曲线定位瓶颈点。我压测时通常会跑 5 组数据从低到高逐步加码得到一条完整的性能曲线而不仅仅是单点数据。4. 模拟真实用户参数化与断言如果脚本里所有请求都带着同样的参数压出来的结果没有参考价值。真实场景下每个用户登录账号不同、查询订单不同、提交数据不同所以参数化是压测脚本必不可少的环节。Jmeter 参数化最常用的有三种方式CSV 参数化、数据库参数化、函数生成。4.1 CSV 参数化多用户不同账号登录最基础也最实用的参数化方式。准备一个 CSV 文件比如 users.csvuser1,123456 user2,123456 user3,123456在线程组下添加配置元件 - CSV 数据文件设置配置如下文件名CSV 文件的绝对路径文件编码UTF-8防止中文乱码后面会细说变量名称username,password逗号分隔对应 CSV 每一列分隔符逗号是否允许带引号False遇到文件结束符循环让测试继续运行循环读取 CSV 数据配置完成后HTTP 请求的参数里直接写 ${username} 和 ${password}JMeter 会为每个线程从 CSV 文件里取一行数据确保每用户使用唯一账号。注意线程数不要超过 CSV 里的数据行数太多否则后面线程会循环重复读取同一批数据不过只要测试目标不关注账号唯一性问题不大。4.2 从数据库取参数JDBC Request 参数化有些场景下账号和业务数据不在 CSV 里而是要从数据库实时查询。比如压测下单流程需要从订单表取一批真实订单号作为参数。这种情况下用 JDBC Request 比 CSV 更高效数据也最新鲜。流程分三步。第一步在线程组下添加配置元件 - JDBC Connection Configuration配置数据库连接信息。关键项Variable Name连接池变量名比如 dbpool后面 JDBC Request 里要用Database URLjdbc:mysql://数据库IP:3306/dbname?useUnicodetruecharacterEncodingutf-8JDBC Driver classcom.mysql.jdbc.Driver 或 com.mysql.cj.jdbc.DriverMySQL Connector/J 8.0 以上Username、Password数据库账号密码注意JDBC 驱动 jar 包要放到 JMeter 的 lib 目录下否则会报找不到驱动类。我遇到过很多次这个问题配置半天连不上最后发现是 jar 包没放对位置。第二步添加 JDBC Request。在线程组下添加 Sampler - JDBC Request配置Variable Name和连接池变量名保持一致填 dbpoolQuery TypeSelect StatementSQL 查询比如 SELECT order_id FROM orders WHERE statusCREATE LIMIT 10Variable Namesorder_id这个就是后续引用的变量名Result variable name可以留空也可以填一个变量存整个结果集第三步在后面的 HTTP 请求里使用 ${order_id_1} 引用第一条查询结果${order_id_2} 引用第二条结果以此类推。如果 Variable Names 填的是 order_idJMeter 会自动生成 order_id_1、order_id_2 直到 order_id_N 这样的引用变量。这里有个小细节如果查询返回多条数据而你想让不同线程取不同行需要用循环处理器配合计数器或者用 __V 函数动态拼接变量名。简单场景下直接用 ${order_id_1} 引用第一行就够了复杂场景再慢慢扩展。4.3 响应断言让脚本有基本判断力压测脚本如果只看请求发出去不管响应对不对很容易出现“假成功”服务器返回 500 错误页面也当成成功请求错误率数据完全失真。响应断言的作用就是校验服务器返回是否符合预期不符合的标记为失败。添加方式HTTP 请求下右键 - 添加 - 断言 - 响应断言。常用配置响应文本选项勾选“包括”在测试模式里填一个业务成功时必然返回的关键字段。比如登录接口成功时返回 code: 0就在测试模式填 code:0如果返回 JSON 且要精确校验可以用 JSON 断言需要插件支持加上断言后再跑一次聚合报告里的错误率百分比才有意义。我在实际压测中发现过不少系统在并发上去后开始返回 500但业务字段被重定向到登录页的情况如果没有断言这种严重问题根本不会暴露。4.4 Beanshell 断言处理复杂校验逻辑响应断言只能做简单的文本匹配如果校验规则比较复杂比如需要从响应里提取某个数值校验它是否大于预期值就要用 BeanShell 断言。虽然 JMeter 官方更推荐 JSR223 Groovy但 BeanShell 在 JMeter 中兼容性很好很多老脚本里都用到了它。import org.apache.jmeter.assertions.AssertionResult; String response new String(prev.getResponseData(), UTF-8); // 假设响应里返回了 {count: 5, status: ok} if (response.contains(\status\:\ok\)) { Failure false; } else { Failure true; FailureMessage 业务校验失败响应没有包含预期状态; }把这段代码粘贴到 BeanShell 断言的 Script 区域运行后如果符合条件就通过否则断言失败。注意 BeanShell 脚本性能不如 Groovy高并发下尽量少用非要处理复杂逻辑时优先考虑 JSR223 采样器 Groovy 脚本。5. HTTPS、文件上传等进阶场景基础脚本能跑通以后实际工作中面临的往往是五花八门的特殊场景接口是 HTTPS、需要上传文件、要录制浏览器里的操作流程。这些场景在 JMeter 里都有对应的处理方案。5.1 HTTP(S) Test Script Recorder录制浏览器操作有些项目没有现成的接口文档或者接口特别多手工一个个填 HTTP 请求太费劲。这时候可以用 JMeter 自带的 HTTP(S) Test Script Recorder代理录制功能把浏览器里的操作录制下来自动生成脚本。操作流程在测试计划下添加非测试元件 - HTTP(S) Test Script Recorder配置端口默认 8888也可以改成 8080 避免端口冲突点击“启动”按钮JMeter 会生成一个临时根证书在系统或浏览器里设置代理服务器为 localhost:8888浏览器里正常操作要录制的内容操作完成后停止录制在测试计划下就能看到录制生成的 HTTP 请求脚本按需修改参数这里有个很重要的点如果录制的是 HTTPS 网站浏览器会提示证书不受信任需要在系统里安装 JMeter 生成的根证书。JMeter 启动录制时会在 bin 目录生成 ApacheJMeterTemporaryRootCA.crt 之类的证书文件双击安装到“受信任的根证书颁发机构”即可。装好证书后浏览器就不会再拦截了。录制功能适合用来快速搭建脚本雏形但录制出来的脚本一般比较臃肿包含大量静态资源请求JS、CSS、图片正式压测前建议把静态资源请求全部删掉只保留核心业务接口。不然压测的大部分请求都是无效的静态文件服务器响应数据失真。5.2 HTTPS 压测的证书处理直接压测 HTTPS 接口时如果不做处理JMeter 会报 SSL 证书验证错误。处理方法有两种第一种把域名证书导入 JMeter 的信任库。从浏览器或服务器导出一个 .cer 或 .crt 证书然后用 keytool 命令导入keytool -import -alias 你的域名 -keystore D:\apache-jmeter-5.6.3\lib\security\truststore.jks -file 你的证书.cer操作时按提示输入默认密码 changeit导入完成后重启 JMeter 即可信任该证书。第二种临时忽略证书验证。在 JMeter 的 system.properties 文件里加一行javax.net.ssl.trustStore或者直接对 HTTP 请求的“实现”选择 HttpClient4并在 jmeter.properties 里设置server.rmi.ssl.disabletrue这个方法配置简单但只适合自己的测试环境生产环境压测还是推荐正规导入证书。5.3 上传文件接口压测文件上传接口的压测在 HTTP 请求里有一个“Files Upload”区域文件名称要上传的文件的完整路径参数名称上传接口中定义的 file 字段名MIME 类型根据文件类型填图片就填 image/png文本就填 text/plain上传文件的接口一般还会伴随其他业务参数比如文件分类、描述信息等这些参数照常填在“参数”区域。需要多个文件就用多个文件上传配置实测效果很稳定。一个注意点压测上传接口时文件大小和内容对性能影响很大。用 1KB 的小文件和 10MB 的大文件压出来的结果差别巨大。压测前要确认好业务真实场景的平均文件大小不要拿一个 1KB 文件去测生产环境 10MB 文件的真实承载能力。5.4 分布式压测一台客户端不够时怎么办单台压测机最高能发起多少并发取决于机器配置普通 8 核 16G 的机器跑到 1000 并发左右可能会出现客户端自身瓶颈。想要更高并发得用 JMeter 的分布式压测Master-Slave 模式。架构上一台 Master 机器负责调度和汇总结果多台 Slave 机器负责实际发送请求。配置要点每台 Slave 机器都要安装 JMeter并启动 jmeter-server 脚本Windows 是 jmeter-server.batMaster 机器上修改 jmeter.properties找到 remote_hosts 配置填上所有 Slave 机器的 IP 和端口逗号分隔remote_hosts192.168.1.101:1099,192.168.1.102:1099确认所有机器的 JMeter 版本一致JDK 版本一致避免 RMI 通信出问题命令行运行时加上 -R 参数指定远程主机jmeter -n -t test.jmx -l result.jtl -R 192.168.1.101:1099,192.168.1.102:1099分布式压测有几个隐蔽的坑。第一脚本里的 CSV 文件路径必须写成绝对路径而且每台 Slave 机器上都要有同样路径的文件。第二Slave 机器和 Master 机器的时间要尽量同步不然结果文件里的时间戳对不上。第三RMI 通信在 JMeter 高版本里默认启用 SSL如果 Slave 机器上证书有问题连不上可以设置 server.rmi.ssl.disabletrue 关闭 SSL但注意这仅限于内网测试环境。分布式压测看起来简单实际调试起来还是要花点时间建议提前一天把环境搭好第二天直接跑。6. 压测结果怎么解读报告分析与容量评估压测跑完以后一堆数字摆在面前但很多人只盯着“平均响应时间”这一个数。真正的性能分析是几个指标放在一起综合判断。6.1 聚合报告的核心指标解读聚合报告里的关键指标翻译成人话Samples总请求数等于线程数乘以循环次数Average所有请求的平均响应时间单位毫秒Median响应时间中位数比平均值更能反映典型响应水平90% Line / 95% Line / 99% Line分别表示 90%、95%、99% 的请求响应时间小于该值是判断极端慢请求的重要指标Min / Max最短和最长的响应时间Error %错误率Throughput吞吐量单位通常是 requests/sec也可以配置成更直观的 TPS看报告时我第一眼看的永远是 Error %只要错误率不是 0先查错误原因再谈其他。错误率在 0.1% 以内而且都是超时类的错可能是偶发网络抖动错误率超过 1%基本可以断定系统在并发下有明显的服务能力问题。第二步看 90% Line而不是平均数。平均响应时间容易被极端值拉高或拉低90% 线更贴近绝大多数用户的真实体验。比如平均响应时间只有 200ms但 90% 线到了 1.2 秒说明系统有大量慢请求被平均数掩盖了。6.2 从 jtl 结果文件生成可视化 HTML 报告命令行模式生成的 jtl 文件是原始数据直接用 Excel 也能打开分析但 JMeter 官方提供了更直观的 HTML 报告生成逻辑jmeter -g result.jtl -o html_report_dir-g 指定 jtl 文件-o 指定输出目录执行后就能生成一个完整的 HTML 报告包含吞吐量变化曲线、响应时间分布图等。这个报告可以直接发给团队其他人看比把聚合报告截图发群里专业得多。另外一个细节生成报告时如果提示目录已存在会报错所以要确保 -o 指定的目录不存在或者为空。我在脚本里一般直接在命令前面加一句清理命令比如 Linux 下的 rm -rf html_report mkdir html_reportWindows 下用 rmdir /s /q。6.3 用压测数据评估系统容量拿到多组不同并发下的压测数据后就可以做容量评估了。我的做法是画一张简单的表格把并发数、TPS、平均响应时间、90% 响应时间、错误率对应起来并发数TPS平均响应时间(ms)90%响应时间(ms)错误率1009501051800%30012002504800%50098051012002.3%从这个表格可以直观看到并发到 300 时系统还能维持较好的响应水平到 500 时 TPS 不升反降响应时间大幅上升错误率开始出现。这就说明系统的拐点大概在 300 到 500 之间容量评估结论就可以给出在保证 90% 响应时间低于 1 秒的前提下系统最大支持并发约 350 左右。注意一个常见误区很多人以为并发越高 TPS 越高实际上当系统资源耗尽后TPS 会达到一个峰值后开始回落同时响应时间和错误率暴涨。找到这个拐点比单纯追求一个好看的 TPS 数字重要得多。我当时验证云上若依微服务环境时就是把云上压测数据和迁移前的物理机数据做了拐点对比再结合业务预期的峰值流量才给出了是否需要扩容的明确结论。7. 实测踩过的坑常见问题排查速查表每个用过 JMeter 的人都有自己的“血泪史”下面几个问题是我在真实项目中反复遇到的整理成速查表供参考。7.1 JMeter 报错java.io.ioexception: error writing to server这个报错我在第一次压测 HTTPS 接口时就撞上了当时一脸懵。主要原因有三个服务端在客户端还持有连接时主动断开了连接、服务端负载过高无法及时响应、或者压测期间网络链路出现抖动。排查思路分三步走。第一步降低并发数量看错误是否消失如果消失说明服务端扛不住当前并发即使不是服务端瓶颈至少是连接建立过多。第二步检查 HTTP 请求配置把“KeepAlive”勾选去掉试试在高级里配置有时是长连接复用导致写入到已经被服务端关闭的连接上。第三步修改 JMeter 的 socket 超时设置在 HTTP 请求的高级区域把“响应超时”和“连接超时”适当调大比如调整到 60000ms。如果是压测目标服务是 Nginx 代理的还要检查 Nginx 的 keepalive_timeout 配置必要时把这个值调大。实际项目中这个报错 80% 的原因都是服务端主动断开连接调整超时参数综合对比后基本能定位。7.2 JMeter 本身内存不够用了现象是压测跑了几分钟JMeter 界面卡死命令行下查看日志提示 java.lang.OutOfMemoryError: Java heap space。果断去改 bin 目录下的 jmeter.bat / jmeter 脚本里的 HEAP 参数这个在前面提过改完重启生效。此外正式压测时检查一下脚本里有没有多余的监听器特别是察看结果树这种吃内存的正式压测时能关就关。如果脚本里用了大量的正则表达式提取器也会消耗很多内存尽量精简。7.3 压测结果数据偏差问题压出来的吞吐量很低但服务器资源占用也很低这时八成是客户端瓶颈而不是服务端瓶颈。检查一下压测机 CPU 和内存使用率如果压测机 CPU 已经 100%说明单台压测机能力到顶了需要上分布式压测或者换更高配置的压测机。还有一种情况是压测机和目标服务器在同一台物理机上互相争抢资源导致数据不准压测环境和被测环境一定要物理隔离。7.4 参数化乱码问题CSV 文件里的中文参数传到服务器端全部变成乱码。原因几乎都是编码不一致。检查三个地方CSV 文件本身编码必须是 UTF-8记事本另存为可以设置、CSV 数据文件设置里的文件编码填 UTF-8、jmeter.properties 里的 sampleresult.default.encoding 改成 UTF-8改完重启 JMeter。三步都确认了乱码问题基本不会出现。另外接口返回的中文也显示乱码那就把 jmeter.properties 里默认编码改掉或者在 HTTP 请求下加一个“后置处理器 - 用户定义的变量”统一设置 Content-Encoding 为 UTF-8。7.5 常见问题速查表问题现象大部分原因解决方案JMeter 双击没反应JDK 未安装或未配置环境变量确认 java -version 能执行补全环境变量连接不上数据库JDBC 驱动 jar 包缺失下载对应驱动放入 JMeter lib 目录HTTPS 报错证书不信任证书未导入信任库用 keytool 导入证书或禁用证书校验聚合报告错误率虚高未添加断言4xx/5xx 也算成功添加响应断言校验业务返回字段压测结果波动大压测机资源不足或环境共享压测机与被调环境物理隔离调大 HEAPHTML 报告生成失败输出目录已存在先清理输出目录再执行 -o 参数写在最后压测这件事的心得压测做久了你会发现JMeter 说到底只是工具真正值钱的是你拿到一堆数据后能不能给出一个大伙儿都信服的结论。我自己的体会是每次压测前花 20 分钟把方案写清楚压测结束后花半小时把报告整理规整比闷头多跑几轮脚本要有价值得多。这套流程在若依微服务云上迁移验证中帮我快速锁定了新环境的性能拐点后续团队再做性能优化时也有了明确的基准数据作为对照。如果你正打算开始学 JMeter建议从小接口练起一步一步把线程组、参数化、断言、报告这几个环节吃透遇到问题就对照速查表排查很快就能上手实战。