1. JMeter到底是干嘛的，为什么大家都在用
我第一次接触JMeter的时候，其实心里是有点懵的。那时候公司上线了一个新接口，测试组需要验证在300个用户同时刷的情况下，接口的平均响应时间能不能控制在800毫秒以内。手头没有什么趁手的工具，有人提议用JMeter，我当时的第一反应是——Apache出的那个Java工具？好像听过，但完全不知道从哪下手。
后来真正用起来才发现，这东西在接口测试和性能测试领域的地位，基本上相当于手机界的安卓——开源、免费、插件多、社区活跃。你不需要掏一分钱许可证费用，也不需要像LoadRunner那样装一堆重型组件，只要机器上有JDK，解压就能跑。更重要的是，它能做的事情远远超出“压测”这两个字：接口功能测试、数据库压力测试、FTP文件上传下载、JMS消息推送、WebSocket长连接、分布式压测，甚至还能配合Selenium做Web UI自动化测试。
这也就解释了为什么热搜词里会出现“jmeter接口测试”“jmeter性能测试步骤”“jmeter压测简单步骤”这些高频搜索。大家的需求其实非常一致：第一，想快速上手；第二，想知道怎么用它完成实际的接口和性能测试任务；第三，遇到证书、上传文件、MD5加密、JSON格式化这些具体场景时，能有一份现成的操作指南可以抄作业。
这篇文章我不打算给你堆一堆官网文档式的术语解释，而是基于我实际项目中踩过的坑和反复验证过的流程，把JMeter从安装配置到脚本设计、参数化、断言、压测执行、结果分析整条链路讲清楚。里面所有步骤都是可以直接复现的，参数怎么填、为什么这么填、填错了会出现什么症状，我都会说到。
2. 安装配置：JDK版本选不对，后面全是坑
2.1 JDK与JMeter版本匹配
很多人下载JMeter后双击启动脚本发现闪退，或者在命令行窗口直接报“Error: Could not create the Java Virtual Machine”，十有八九是JDK版本和JMeter版本不匹配。
JMeter 5.x系列要求Java 8及以上，JMeter 5.5开始推荐Java 11，到了JMeter 5.6+，官方已经明确建议使用Java 11或Java 17。如果你还在用JDK 1.7，那别想了，直接升级。我自己踩过的一个坑是：机器上装了JDK 8和JDK 17两个版本，环境变量JAVA_HOME指向了17，但JMeter版本是5.4.1，启动时虽然没报错，但跑某些插件（比如后面会讲到的WebDriver Sampler）时，一直提示类库冲突。后来把JMeter升级到5.6.3，问题才彻底消失。
推荐组合：JDK 11 + JMeter 5.6.3，这个组合在稳定性和插件兼容性上最均衡，也是我目前主力环境。
2.2 环境变量配置要点
下载JMeter（二进制包，不是源码包）后，解压到纯英文路径，这个很重要。路径里一旦出现中文或者空格，后续跑脚本时偶尔会出一些莫名其妙的问题，比如CSV文件路径解析失败、证书导出失败等。
配置环境变量时，你只需要做两件事：
- 新建JMETER_HOME，值为JMeter解压目录，比如
D:\apache-jmeter-5.6.3 - 在PATH变量里追加
%JMETER_HOME%\bin
然后打开命令行，输入jmeter -v，如果能看到版本信息，说明环境变量配好了。注意，配置完环境变量后，命令行窗口必须重新打开才会生效。
另外提一个容易被忽略的点：JMETER_HOME配好后，最好在系统变量里也确认一下CLASSPATH是否包含%JMETER_HOME%\lib\ext\ApacheJMeter_core.jar和%JMETER_HOME%\lib\jorphan.jar。虽然新版JMeter不强依赖CLASSPATH，但有些第三方插件在启动时会读这个变量，缺了它插件加载会失败。
2.3 启动模式选择
Windows下双击jmeter.bat会启动GUI模式，Mac/Linux下运行jmeter命令同样进入GUI。GUI模式只建议用来写脚本和调试，真正执行压测时一定用命令行模式：
jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir这个命令的意思是：以非GUI模式运行test_plan.jmx测试计划，将原始结果写入result.jtl，并自动生成HTML可视化报告到report_dir目录。我见过太多人直接用GUI模式去压测，结果压到一半GUI界面卡死，数据全丢。GUI模式本身会消耗不少内存和CPU，这些资源本来应该全部用于模拟请求。
3. 测试计划设计：从零搭建一个完整的脚本
3.1 测试计划的核心组成
一个JMeter测试计划，说白了就是一棵树。树根是测试计划节点，下面挂线程组，线程组下面挂Sampler（采样器）、配置元件、断言、监听器、定时器等。
这里我以一套标准的HTTP接口性能测试脚本为例，把每个核心节点的作用说明白。
- 测试计划节点：全局配置，比如用户自定义变量、全局HTTP请求默认值、全局断言。
- 线程组：模拟用户群体，控制并发数、循环次数、启动时间。
- HTTP请求默认值：统一管理协议、域名、端口、编码等公共信息，避免每个请求重复填写。
- HTTP请求：真正的接口调用，可以配置GET/POST/PUT/DELETE等方法和Body体。
- HTTP信息头管理器：管理Content-Type、Authorization、Cookie等请求头。
- CSV数据文件设置：实现参数化，从外部文件读取测试数据。
- 断言：校验响应结果是否符合预期。
- 聚合报告/查看结果树：查看测试数据和响应详情。
看起来节点很多，但实际上你只需要记住一个原则：从根到叶，逐级配置；公共配置上移，私有配置下移。
3.2 线程组参数到底怎么填
线程组有三个核心参数：线程数、Ramp-Up时间、循环次数。很多新手在这三个参数上犯迷糊，我举个具体例子。
假设你要模拟300个用户同时访问系统，且每个用户在1分钟内持续操作，那么可以这样设置：
- 线程数（用户数）：300
- Ramp-Up时间（秒）：60
- 循环次数：1
- 调度器配置：持续时间600秒
这里Ramp-Up时间的意思是在60秒内逐步启动这300个线程，而不是瞬间全部发起。这样做的好处是模拟真实场景中用户逐步进入系统的过程，避免启动瞬间对服务器造成瞬时冲击，导致结果失真。
如果你真的需要“瞬间并发”，可以把Ramp-Up时间设为0，这样JMeter会在测试启动的第一时间创建所有线程并同时发起请求。但要注意，这种方式对测试机本身的负载很大，300个线程同时启动对客户端机器内存和CPU都是考验。
关于“单用户1分钟”这个热搜词，我推测你遇到的需求是并发数不高，但需要持续压测1分钟。这种场景下，线程数设为1，调度器勾选持续时间，填入60秒，循环次数选“无限”，效果就是1个用户持续不断发送请求60秒。
3.3 HTTP请求配置的细节
添加一个HTTP请求后，你需要填写协议、服务器名称或IP、端口号、方法、路径、请求体等。
需要注意几个细节：
- 协议：默认是http，如果被测接口是https，必须改成https，否则会报证书相关错误。
- 服务器名称：填域名或IP，不要带
http://前缀，否则会报“UnknownHostException”。 - 端口号：http默认80，https默认443，如果你的服务不是默认端口，必须显式填写。
- Content-Type：POST请求通常需要设置请求头
Content-Type: application/json，如果接口只认application/x-www-form-urlencoded，你要看后端框架的接收方式。遇到明明参数传了，但后端一直收不到的Case，第一反应就查请求头。
举个例子，用JMeter模拟一个POST接口请求，请求体是一个JSON：
POST /api/user/login HTTP/1.1 Content-Type: application/json {"username": "test01", "password": "123456"}在JMeter里，HTTP请求的Body Data标签页里直接粘贴这段JSON：
{"username": "test01", "password": "123456"}信息头管理器里添加：
Content-Type: application/json很多接口还会要求请求头带Authorization、token、sign等字段，你可以在HTTP信息头管理器里统一维护。
4. 参数化：让脚本真正跑起来
4.1 用户自定义变量
如果你只有一个接口需要测试，且参数值固定不变，直接在测试计划节点右键添加“配置元件 -> 用户自定义变量”就可以了。
比如：
| 变量名 | 值 |
|---|---|
| host | 192.168.1.100 |
| port | 8080 |
| username | test_user |
| password | pass123 |
在HTTP请求里通过${host}、${port}的方式引用变量。这样做的好处是，当环境切换（从测试环境切到预发环境）时，只需要改这一处变量值，所有请求的host都会跟着变。
4.2 CSV数据文件参数化
真实业务场景下，你不会拿同一组账号去压测，因为服务器可能有防重登录校验、缓存机制等，导致测试结果不真实。正确做法是通过CSV文件准备多组测试数据。
假设你有一个users.csv文件，内容如下：
username,password user001,pass001 user002,pass002 user003,pass003在测试计划中添加“配置元件 -> CSV数据文件设置”，配置如下：
- 文件名：
path/to/users.csv - 文件编码：
UTF-8 - 变量名称：
username,password - 分隔符：
,（逗号） - 是否允许带引号：False
- 遇到文件结束符再次循环：True
- 线程共享模式：所有线程
配置好后，HTTP请求中直接使用${username}和${password}。JMeter会从CSV文件中按行读取数据，分配给不同线程或同一线程的不同迭代。
这里有一个容易踩的坑：CSV文件的路径不能有中文，否则在命令行模式下会读取不到文件。另外文件编码一定要和CSV实际编码一致，Windows下用Excel另存的CSV默认是GBK编码，如果你在JMeter里设置了UTF-8，中文会全部乱码。
4.3 函数助手实现动态参数
有些接口的参数是动态生成的，比如时间戳、随机数、UUID。这些可以通过JMeter的函数助手来生成。
点击菜单栏“选项 -> 函数助手对话框”，你会看到一系列函数。常用的有：
${__time(yyyy-MM-dd HH:mm:ss,)}：生成当前时间${__Random(1000,9999,)}：生成1000到9999之间的随机数${__UUID()}：生成UUID${__digest(MD5,${username}${password},,,)}：对字符串做MD5加密
这就是热搜词“jmeter md5加密”的答案。有的接口为了安全，要求请求参数中包含sign字段，它的生成规则可能是对某些参数拼接后做MD5。你可以这样处理：
- 在“用户自定义变量”中定义原始参数值，比如
appId=1001、secretKey=abc123 - 添加一个“BeanShell Sampler”或“JSR223 预处理程序”，在其中拼接字符串并计算MD5
- 把计算结果存入变量，供后续HTTP请求引用
更简单的方式是使用函数助手：
${__digest(MD5,${appId}${secretKey}${__time(yyyyMMddHHmmss,)},)}这种方式不需要写额外脚本，但只适合拼接逻辑不复杂的场景。
4.4 JDBC参数化
如果接口的入参需要从数据库里实时取样，比如从用户表里随机取一个注册手机号，那可以在测试计划里添加JDBC Connection Configuration和JDBC Request。
你需要在JDBC Connection Configuration里配置数据库URL、JDBC驱动类、用户名、密码。比如MySQL：
- Database URL：
jdbc:mysql://192.168.1.100:3306/test_db?useSSL=false&characterEncoding=utf8 - JDBC Driver class：
com.mysql.jdbc.Driver - Username/Password：数据库账号密码
提前把MySQL JDBC驱动jar包放到JMETER_HOME/lib/ext目录，重启JMeter才能生效。
添加JDBC Request后，写SQL查询语句，比如：
SELECT phone FROM user_table WHERE status=1 LIMIT 5;把结果变量名设为phoneData，然后在HTTP请求中通过${phoneData_1}引用第一行的值。这里下划线加数字代表取第几行数据，JMeter默认会把查询结果放在变量名_1、变量名_2这样带下标的变量中，同时变量名本身是总行数。
5. 断言：压测结果准不准，先看断言合不合理
5.1 常用断言类型
没有断言的请求十有八九是在耍流氓。因为HTTP协议层面返回200，并不代表业务成功。比如登录接口，用户名密码错误时返回也是200，但响应体里的code字段可能是10001。
JMeter里最常用的断言是“响应断言”，它支持对响应文本、响应代码、响应头、响应消息做匹配。我一般这样配置：
- 要测试的响应字段：响应文本
- 匹配规则：包含
- 测试模式：
"code": 0
这样只有当响应文本中包含"code": 0时，这个请求才被判定为成功，否则为失败。这么一套下来，聚合报告里的错误率才是真正有意义的业务失败率，而不是单纯的HTTP状态码错误。
对于JSON格式的响应，还可以使用“JSON断言”，它可以直接用JSONPath表达式提取字段值做校验。比如提取$.code判断是否等于0。JSON断言的好处是定位精确，不会因为响应里其他字段的原因产生误判。
5.2 断言失败的排查思路
断言失败时，不要急着改脚本，先看“查看结果树”里的请求和响应数据。
有一条路径非常有效：
- 在“查看结果树”里选中失败的请求
- 看“请求”标签页，确认参数值、请求头、URL是否完全正确
- 看“响应数据”标签页，确认后端返回了什么错误信息
- 用Postman或curl手动重放这个请求，看是否同样失败
如果手动重放成功但JMeter失败，大概率是变量取值的问题，检查CSV数据文件路径、变量名拼写、编码格式。如果手动重放也失败，那就是接口本身或测试数据的问题。
5.3 断言对性能测试的影响
性能压测时，断言的设置会影响压测结果的准确度。断言本身需要消耗JMeter自身的CPU和内存去解析响应内容。如果响应体很大，比如几MB的JSON，还做了密集的正则匹配，那么压测机的负载会明显上升，请求发送速率也会下降。
我的建议是：功能调试阶段开启完整断言，正式压测时只保留核心业务断言。如果压测机的CPU占用率超过80%，优先排查断言和监听器是不是太重了。
6. 实战案例：登录接口压测完整流程
6.1 场景描述
假设现在要对某个系统的登录接口做压力测试，接口信息如下：
- 地址：
https://test.example.com/api/login - 请求方式：POST
- 请求头：
Content-Type: application/json - 请求体：
{ "username": "test01", "password": "e10adc3949ba59abbe56e057f20f883e" }password是MD5加密后的值，加密规则是对明文密码做MD5。
6.2 脚本设计步骤
第一步，设置测试计划全局变量。添加“用户自定义变量”，定义host=test.example.com、port=443、protocol=https。
第二步，添加线程组。设置线程数为50，Ramp-Up时间为10秒，循环次数为100。
第三步，添加HTTP请求默认值，配置协议为${protocol}，服务器名称为${host}，端口号为${port}。
第四步，添加HTTP请求，方法选POST，路径填/api/login，Body Data粘贴JSON，其中密码字段可用MD5函数动态生成：
{"username": "test01", "password": "${__digest(MD5,123456,)}"}如果要对不同用户做参数化，把CSV文件配置好，username和password都改成变量引用方式。
第五步，添加HTTP信息头管理器，设置Content-Type: application/json。
第六步，添加响应断言，匹配规则为“包含”，测试模式填"code": 0。
第七步，添加查看结果树和聚合报告，先以1个线程1次循环跑一下，确认脚本能通。
6.3 命令行压测与生成报告
脚本调试通过后，用命令行模式执行压测：
jmeter -n -t login_test.jmx -l result.jtl -e -o report压测执行完后，打开report目录下的index.html，你能看到聚合报告、响应时间分布图、吞吐量趋势、错误率统计等丰富信息。
很多人遇到“jmeter resultcollector.action_if_file_exists 弹窗问题”，这个通常是在GUI模式下执行测试时，结果文件已存在，JMeter弹出确认框询问是否覆盖。这个问题在命令行模式下不会出现，因为命令行模式下如果指定了已有的jtl文件，JMeter会直接覆盖。如果你在GUI模式下执行压测时看到这个弹窗，原因是你已经加载了一个同名结果文件，可以在“测试计划 -> 添加监听器 -> 简单数据写入器”中，把结果文件配置为“每次运行开始时自动清除旧数据”。
7. 录制HTTPS脚本与上传文件场景
7.1 HTTPS脚本录制
有些时候我们面对的接口没有现成的接口文档，比如老系统、外包系统，只有页面可以操作。这时候就可以用JMeter的HTTP(S)测试脚本录制器来抓取浏览器发出的请求。
原理其实不复杂：JMeter启动一个本地代理服务器，浏览器把代理指向它，所有HTTP/HTTPS请求都会经过JMeter，JMeter把请求转成测试脚本里的采样器。
操作步骤：
- 在测试计划下添加“非测试原件 -> HTTP(S)测试脚本录制器”
- 全局端口默认8080，建议改成8888，避免端口冲突
- 添加“测试计划 -> 线程组”作为录制脚本的存放位置
- 点击“启动”按钮，开始录制
- 浏览器设置代理，主机填127.0.0.1，端口填8888
- 浏览器访问被测系统，进行正常业务操作
- 操作完成后，在JMeter里停止录制
这里有一个绕不开的问题：HTTPS证书。浏览器访问HTTPS站点时会验证证书，JMeter作为中间代理需要生成一个自签名证书，需要把这个证书导入浏览器信任列表。
热搜词里“jmeter安全证书”“jmeter录制https脚本”就是这么来的。
导入证书的步骤是：启动JMeter，打开浏览器设置里的证书管理，导入JMETER_HOME/bin目录下的ApacheJMeterTemporaryRootCA.crt，勾选“信任此证书”。
自动生成的证书在每次启动JMeter时可能会重新生成，如果之前导入的证书失效了，重新导入一次即可。
录制完后一定要做清理工作：删掉静态资源请求（css、js、png、fonts），因为压测时这些请求会额外增加服务器压力，通常不是我们关注的对象。
7.2 如何测试上传文件接口
上传文件接口在JMeter里需要把请求方法设为POST，然后在请求的文件上传标签页中配置：
- 文件名称：本地文件的完整路径，比如
D:\test_data\avatar.jpg - 参数名称：后端接收文件字段的名称，比如
file - MIME类型：根据文件类型填写，比如
image/jpeg
同时，不要手动设置Content-Type: multipart/form-data，JMeter会根据文件参数自动生成multipart请求头。如果你手动设置了，反而可能造成边界错误。
如果你想要测试多个文件上传，可以填多行文件列表，每一行对应一个文件字段。
7.3 JMeter测试人脸识别系统
热搜词里还有“jmeter人脸识别系统压力测试”，这个场景稍微特殊一些。人脸识别系统的接口通常接收的是图片的Base64编码串，而不是传统表单字段。
你需要先准备一张或多张测试图片，通过在线工具或脚本将图片转为Base64字符串。如果图片比较大，直接把Base64写进JMeter请求体里又长又不方便维护，建议的做法是：
- 把Base64字符串存入CSV文件，用CSV数据文件设置参数化。
- HTTP请求体直接引用参数，比如
{"image": "${base64Data}", "faceId": "face001"}。
另外一个需要特别注意的是，人脸识别系统通常是异构服务，可能是Java、Python、C++混编，底层还涉及GPU加速。压测时如果出现大量超时，先别急着下结论说系统性能不行，先排查是不是并发数已经超过了GPU的处理能力。
8. 压测结果的解读与社区高频问题
8.1 聚合报告关键指标怎么看
跑完压测后，很多人盯着聚合报告，只看“Average”就完事了，这是远远不够的。
你需要重点关注这几个维度：
- Samples：总请求数
- Average：平均响应时间
- Min/Max：最短/最长响应时间
- Std. Dev.：响应时间标准差，这个值越接近0，说明响应时间越稳定
- Error %：错误率，一般不超过0.1%才能算健康
- Throughput：吞吐量，单位通常是
/sec，也就是每秒处理请求数
实际项目中，平均响应时间500ms但TP90高达2秒的情况很常见。因为平均值会被大量快速请求拉低，掩盖部分慢请求的真实情况。所以更专业的做法是查看“聚合报告”中90% Line、95% Line甚至99% Line的值。
JMeter的HTML报告里已经有这些百分位数据，不用自己算。
8.2 如何确认系统并发数
这个问题的本质是：压测到多少并发，系统依然能保持稳定。
标准方法是“梯度加压”。不要一次性上500个线程跑半小时，那是蛮干。正确姿势是从低到高逐步加压，比如：
- 50并发，跑5分钟，记录各项指标
- 100并发，跑5分钟，记录指标
- 200并发，跑10分钟，观察瓶颈点
- 500并发，跑10分钟，确认极限点
每轮压测结束后，观察响应时间是否出现线性上升、错误率是否突变、吞吐量是否到达平台期。一旦响应时间明显恶化，且吞吐量不再提高，基本就找到了系统的支撑上限。
这个过程用JMeter实现并不复杂，只需要在同一个线程组里用“终极线程组”插件（jpgc - Ultimate Thread Group），它的配置界面可以按阶段设置线程数、启动时间、持续时间、停机时间，非常直观。
对了，这个插件需要先安装“JMeter Plugins Manager”，在插件管理器里搜索Ultimate Thread Group安装即可。“jmeter使用jp@gc - webdriver sampler”这个热搜词的jp@gc前缀，就是JMeter插件团体PerfMon出品的插件命名规则。
8.3 请求体响应体JSON格式化
调试接口时，响应体JSON一大坨没法看，这是很多人抓狂的点。
JMeter的“查看结果树”监听器自带简单的JSON格式化功能，点击响应数据上方工具栏里的JSON按钮，响应体会自动缩进。如果你觉得不够好用，可以在结果树里把响应数据保存为JSON文件，然后用任何编辑器的格式化功能。
还有一个小技巧：如果你在写JSR223断言或后置处理器，需要提取JSON字段时，推荐用JSON Extractor插件，比手写正则表达式稳定太多。在HTTP请求上右键 -> 添加 -> 后置处理器 -> JSON Extractor，配置JSONPath表达式（比如$.token），把结果存入变量，供后面的请求引用。这个用法非常适合做登录后获取token，再携带token调用其他接口的业务流。
需要注意JSONPath的语法和常见坑。$代表根对象，$.token取根对象下的token字段，$..token则在所有层级中查找第一个token字段。如果接口返回的是数组，比如$.data.list[0].id表示取data.list数组中第一个元素的id。很多时候大家配置完提取不到值，就是因为数组索引或路径层级写错了。
8.4 JMeter上传文件与MD5加密的配合场景
很多上传接口会在上传前对文件内容做MD5校验，用于确认文件在传输过程中没有被篡改，同时避免重复上传。
如果你遇到的是这种接口，需要分两步处理：先用BeanShell或JSR223后置处理器读取本地文件并计算MD5，再把MD5值作为请求的某个参数传入。
用JSR223 + Groovy脚本实现，逻辑非常简洁：
import java.security.MessageDigest def file = new File("D:/test_data/avatar.jpg") def md5 = MessageDigest.getInstance("MD5") def digest = md5.digest(file.bytes) def sb = new StringBuilder() digest.each { b -> sb.append(Integer.toHexString((b & 0xFF) | 0x100).substring(1, 3)) } vars.put("fileMd5", sb.toString())然后在HTTP请求的参数中引用${fileMd5}。
对于“jmeter怎么测试自己安装的虚拟机”这个热搜词，本质上和普通接口测试没有区别，无非是把服务器IP换成虚拟机的IP，确保JMeter所在机器和虚拟机之间的网络是通的，防火墙放行了对应端口。
8.5 常见问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 启动闪退 | JDK未安装或路径有误 | 检查JAVA_HOME，重新配置环境变量 |
| 请求返回404 | URL路径错误或服务未部署 | 用浏览器或Postman验证接口地址 |
| 请求返回401/403 | 缺少token或鉴权头 | 检查HTTP信息头管理器配置 |
| 响应数据中文乱码 | 编码格式不匹配 | 请求中配置Content-Type: application/json;charset=UTF-8，确保CSV文件编码正确 |
| CSV变量取值为空 | 文件路径错误或变量名拼写错误 | 检查绝对/相对路径，确认变量名与CSV表头一致 |
| 压测结果错误率高 | 断言的匹配规则与响应不一致 | 查看结果树，确认响应内容，调整断言 |
| 连接被重置 | 并发数超过程序最大连接限制 | 检查被测服务连接池配置 |
| 命令行跑完没有报告 | 缺少-e -o参数 | 加上-e -o report_dir重新执行 |
| JMeter自身CPU过高 | 断言太重或监听器太多 | 精简断言，使用命令行模式，移除图形监听器 |
9. 从入门到熟练的几条个人体会
最后聊几个我实际使用JMeter过程中的个人经验，这些东西是文档里不会写的。
第一，脚本的结构化程度决定了后期维护成本。我见过有人把所有接口的Host、端口、路径全写在HTTP请求里，换一套环境就要改几十处。正确的做法是把环境相关的信息全部收敛到配置元件里，脚本本身不做任何环境相关性处理。这样从测试环境切到预发环境，只需要修改一处。
第二，压测机的性能不能忽视。JMeter是Java应用，堆内存默认只有1GB，跑大规模压测时很容易OOM。在jmeter.bat或jmeter.sh里找到HEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"这一行，根据机器配置调整，比如改成-Xms4g -Xmx4g。但要注意，堆内存不是调越大越好，太大反而容易造成GC时间过长，影响压测准确性。
第三，脚本调试一定要用小并发，先通后快。我以前忍不住直接按最终压测规模跑，结果脚本一个参数错误，几千个线程全部请求失败，白忙活半天。正确流程是：单线程单次循环验证功能 -> 单线程多次循环验证稳定性 -> 小并发（10~20线程）验证多用户数据 -> 再上生产规模压测。
第四，压测报告要保存好原始jtl文件。HTML报告可以验证结果，但原始jtl是数据源头。有时候客户或领导会质疑压测数据，重新生成一份报告或者换个指标口径分析时，没有jtl就只能重新压一遍，时间成本太高。
第五，能用命令行就跑命令行，GUI窗口除了写脚本和看数据，其他时候少开。JMeter GUI本身很吃内存，压测时开着它，你统计的吞吐量和响应时间一半可能被它自己吃掉了。
JMeter这个工具，入门门槛是真的不高，装好JDK、解压、写个简单请求就能跑起来。但想用好，需要你对HTTP协议、业务逻辑、系统架构都有足够的理解。工具永远是手段，不是目的。希望这篇文章能帮你把JMeter这块拼图拼到自己的技能树里，后面真正遇到性能问题的时候，能拿着它找到系统真实的瓶颈。
