用JMeter做压测的这些年我手机里存的报错截图快赶上照片数量了。每回脚本跑不起来群里就有人甩一张红色日志出来问咋回事来来回回都是那几个经典问题。这次不聊高深理论也不贴大段官方文档就纯把常见报错一条条拎出来说说它们长什么样、根子出在哪、我是怎么收拾的。内容按真实使用顺序来排先环境启动再资源内存然后网络连接接着响应取值最后是脚本逻辑。无论你是刚上手JMeter的测试新人还是已经跑了几个月压测的工程师都可以直接把这篇文章当成一张排查地图来用。1. 前置环境光启动JMeter就能卡住的那些坑JMeter启动阶段的问题看起来小儿科但真遇到了很耽误事。很多人解压完JMeter双击bat文件窗口一闪就没了或者日志里冒出一屏红色异常这时最容易慌了手脚。其实这类问题根源很集中无非就是Java版本不匹配或者启动方式不对。1.1 Java版本不符JMeter直接闪退最常见的报错长这样UnsupportedClassVersionError: org/apache/jmeter/XXX has been compiled by a more recent version of the Java Runtime这句话说白了就是JMeter编译时用的Java版本比你机器上跑的Java版本新当前JVM不认它的class文件。JMeter每个大版本对JDK版本都有最低要求像5.x系列基本要Java 8以上近几个版本官方建议用Java 11甚至Java 17长期支持版。你要是装了个老JDK启动这关就过不去。我的排查套路很简单先在命令行敲一句java -version看清楚当前默认Java到底是哪个版本。很多时候机器上装了不止一个JDK环境变量或者Path里的顺序乱了JMeter启动脚本找到的是个老版本。尤其Windows下双击jmeter.bat时闪退根本看不到报错我建议先开一个cmd窗口手动切到JMeter的bin目录执行jmeter.bat -v这样所有报错都留在控制台里逐行看过去问题基本就暴露了。确认是版本问题就装一个长期支持版JDK把JAVA_HOME环境变量指过去。注意设置完环境变量要重新开终端不要在当前窗口直接跑读不到新配置。更稳一点的做法是在jmeter.bat顶部直接把JAVA_HOME路径写死这样就算以后别的软件把环境变量改乱了JMeter也不受影响。1.2 GUI跑大并发CPU先被工具自己吃掉还有一种问题不算“报错”但遇到的人非常多在图形界面里直接开几千并发JMeter自己CPU飙到100%窗口卡到拖不动最后跑出来的数据也没法信。为什么会这样因为在GUI模式下JMeter需要把每个取样器的结果实时刷新到界面查看结果树、聚合报告这些监听器还要把所有响应数据收进内存做统计。线程越多工具自身的开销越大相当于压测队伍还没上场工具先把自己累趴了。所以这里我强烈建议分场景处理调试脚本用GUI真正的压力测试用命令行模式。我日常执行压测的命令是jmeter -n -t 压测脚本.jmx -l result.jtl -e -o html报告目录这条命令跑完后会直接生成一份HTML图形报告吞吐率、响应时间、错误率都有。平时脚本里放的监听器在命令行模式下影响很小基本不拖性能。另外提醒一句压测机资源是有限预算跑大并发时尽量不要在同一台机器上开着浏览器、微信、网盘这些吃内存的东西把CPU和内存全让给JMeter结果才有参考意义。2. 压测过程中最常见的内存与资源问题进程刚起来脚本也跑通了接下来真正头疼的是压测过程中冒出来的异常。内存类报错在JMeter里出现频率极高尤其是长时间跑稳定性测试的时候几乎每隔一阵子就会有人在群里发同样的截图。这类问题处理起来并不难但前提是得懂一点点JVM的基本概念不然容易瞎调。2.1 OutOfMemoryError: Java heap space这个报错很多人跑着跑着就撞上了尤其GUI模式下开着查看结果树跑长时间压测响应数据不断被塞进内存堆空间很快就顶不住。报错信息里已经写得很明白Java堆内存不够用了。我之前遇到的一次典型场景是跑了一个小时稳定性测试聚合报告和结果树同时开着然后JMeter直接停止采样日志里刷出一堆java.lang.OutOfMemoryError: Java heap space。原因其实就两个一是堆内存给得不够大二是JMeter把太多数据留在了内存里。解决办法分两步。第一步调JMeter的启动堆内存在bin目录下找到jmeter.batWindows或者jmeterLinux/Mac里面有一行类似set HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m这是我见到的默认配置1G堆在现在动辄几百线程的场景下实在不够看我一般会改成set HEAP-Xms2g -Xmx4g -XX:MaxMetaspaceSize512m-Xms是初始堆大小-Xmx是最大堆大小。注意最大堆不是越大越好得看压测机物理内存有多大留一部分给操作系统和网络栈别把整台机器都填满。第二步更重要就是减少无谓的内存占用。GUI模式下能关的监听器尽量关掉结果树尤其别长时间开着看数据。长时间压测收集结果用命令行模式配合简单的写文件监听器就够了数据先落到磁盘压测结束后再打开分析这样JMeter进程内存占用会平稳很多。2.2 GC overhead limit exceeded这个报错和堆内存溢出有亲缘关系但对新手来说更迷惑。出现的信息是java.lang.OutOfMemoryError: GC overhead limit exceeded从JVM机制上说GC是垃圾回收器在打扫堆内存里的无用对象。如果堆填得差不多满了GC就会不停工作回收效果却很差回收一点又立刻填满。JVM遇到连续垃圾回收占用了大量CPU时间但释放内存却很少的情况就会主动抛这个错防止程序彻底无响应。我遇到GC报错时第一反应不是继续加内存而是先看看脚本里有没有把大量数据留在内存里的组件。比如循环次数很大的循环控制器里面套CSV数据源或者正则表达式匹配了超大响应文本都会造成对象堆积。先用命令看一下GC情况jstat -gcutil 进程PID 1000这个命令每秒输出一次GC统计如果看到FGCFull GC频率特别高而且老年代空间一直居高不下基本就是对象释放不了。处理建议有三条清理脚本里不必要的监听器减少响应数据处理改成命令行模式跑最后才考虑加大堆内存。另外如果脚本本身有内存泄漏写法比如在循环里使用BeanShell不断创建大对象那加再多内存也没用得先把代码改对。2.3 聚合报告吞吐率突然变低这可能不算报错但绝对算问题。很多人跑压测时发现一个诡异现象并发数不断往上加聚合报告里的TPS却低得离谱甚至比低并发时还低。这时候可以先去压测机上看看CPU和内存占用再用top或者任务管理器看一眼JMeter进程状态。我之前排查过一次类似问题脚本本身很简单但压测机是个配置一般的Windows笔记本开了两千并发后笔记本CPU直接打满网络连接数也到了极限JMeter自己都跑不动了TPS自然上不去。所以压测机配置不够的时候优先考虑降低JMeter自身开销用命令行模式关掉不必要的功能或者直接换一台配置更好的压测机。还有人为了模拟用户思考时间在脚本里加了固定定时器或常数吞吐量定时器结果TPS被定时器卡死高并发也冲不上去。这种情况不算故障是脚本本身限流了看脚本里有没有这类组件就行。3. 网络与连接层连接拒绝、端口耗尽、连接超时如果说内存问题是JMeter自己的毛病那网络层面的问题就有点“甩锅”性质了。很多时候脚本运行报错其实是底层网络连接出了问题。这类报错信息五花八门但归结起来就那么几类。3.1 Address already in use 端口被占满这个报错在Windows上跑高并发短连接时非常容易遇到日志里写着java.net.BindException: Address already in use: connect用大白话解释一下TCP连接需要有源端口系统给客户端分配一个临时端口连接结束后端口不会马上释放而是进入TIME_WAIT状态要等一段时间才能重新使用。Windows默认TIME_WAIT比较长如果你用JMeter发起大量短连接瞬间把可用端口全占光了新连接就没有端口能用于是报Address already in use。我在某次压力测试时跑到一半就遇到这个当时一看系统连接状态TIME_WAIT状态的连接有几万个。解决办法从几个方向入手压测请求尽量开启Keep-Alive让HTTP连接复用减少短连接数量这是最省事的做法。Windows系统层面调大可用端口范围在管理员命令行执行netsh int ipv4 set dynamicport tcp start1025 num64510然后把注册表里的TcpTimedWaitDelay调小比如从默认240秒调到30秒减少TIME_WAIT占用时间。Linux压测机也可以调大端口范围sysctl -w net.ipv4.ip_local_port_range1024 65000这里提醒一句调整系统参数后最好重启JMeter进程让连接池重新初始化。3.2 Connection refused 目标端口根本不理你java.net.ConnectException: Connection refused: connect这个报错字面意思很明确客户端发起的连接被目标机器拒绝了。听到这个错误我一般从下面几个原因排查。第一目标服务真的没起来或者没监听对应端口。先用curl测试一下接口能不能通比如curl -v http://目标地址:端口/路径如果curl也报连接失败那就是服务端或者网络问题先别怀疑JMeter。第二防火墙或安全组把端口挡了这个在云环境里特别常见配置了安全组规则但漏放压测机IP结果本机测试没问题从压测机跑就报拒绝。第三目标服务的连接队列满了比如Tomcat的acceptCount配得比较小并发一上来内核accept队列塞满新连接直接拒绝。这种时候看服务端日志会有相关记录需要调大服务端的accept队列和线程池配置。我遇到过最迷惑的一次是压测机和被测服务在同一台机器上curl探测完全正常JMeter却报Connection refused。后来发现JMeter脚本里填的IP是域名解析到了内网其他机器那个机器根本没开服务。所以排查时第一件事就是确认地址和端口写的对不对。3.3 Connection reset / Read timed out 连接断掉、响应太慢还有两类高频网络报错一是java.net.SocketException: Connection reset另一个是java.net.SocketTimeoutException: Read timed outConnection reset通常是服务端主动关闭了连接。最常见的情况是服务端设置了较短的KeepAlive超时客户端连接池里还留着这个连接下次请求时连接其实已经失效了一读写就报reset。处理思路是把JMeter的HTTP请求设置为连接复用策略匹配服务端的KeepAlive超时配置或者干脆在请求头里加Connection: close让每个请求都新建连接牺牲一点性能换稳定。也有人通过调整JMeter的httpclient连接池属性来处理比如在jmeter.properties里设置httpclient4.retry.count1让请求失败后自动重试一次能减少不少偶发报错。Read timed out则是响应超时服务端处理太慢超过了JMeter里设置的响应超时时间。这种情况要区分是偶尔发生还是大面积发生。偶尔发生可以适当调大响应超时比如从默认的几十秒改成120秒大面积发生就说明服务端确实扛不住了这时候该做的是看后端性能瓶颈而不是头铁加超时时间。4. 响应提取与编码JSON、正则、乱码三连坑前面几个问题搞定后脚本基本能跑顺手了但接下来还有一坑等着从响应里取数据。接口压测几乎都会涉及参数关联比如登录之后拿Token下单之后拿订单号。这些动态数据取不出来后续请求全废。这部分的报错不会直接弹红而是变量取出来是空的请求参数变成一堆undefined排查起来反而更费劲。4.1 JSON提取器看起来正常结果却是nullJSON Extractor是现在用得最多的提取器但它翻车概率不低。最典型的现象是配置界面看起来完全正确运行后Debug Sampler里变量却是null或者一直等于你填的“默认值”。出现这种情况我第一件事就是打开查看结果树先把实际响应内容复制出来粘贴到JSONPath Tester里一条条验证表达式。写错JSONPath是高发问题比如接口返回是{data: {list: [{id: 1, name: 张三}]}}有人想当然写成$.data.list.id这显然取不到要写成$.data.list[0].idlist是数组必须带下标。还有一些返回嵌套多层一次定位不到可以用模糊定位$..id先看看能不能取到值再逐步收窄。另一个容易忽略的地方是JSON Extractor有个“Match No.”参数默认0代表随机匹配。如果响应里匹配到了多个值那就可能每次取到的都不一样业务逻辑就乱了。需要固定取第一个时要把Match No.设为1。还有那个“默认值”字段提取失败时不会报错而是默认值很多人调试时看到变量等于默认值以为是提取成功其实根本没取到。我建议调试阶段把默认值故意填一个醒目的错误内容比如ERROR这样一眼就能看出提取有没有成功。4.2 正则表达式写对了变量还是空空如也老项目、非JSON接口用正则提取的场景依然很多正则提取器的坑也比较经典。最常见的翻车原因是对特殊字符处理不当。比如要从版本号1.2.3里提取正则写成(1.2.3)这个点号在正则里是“任意字符”的意思不是小数点本身很可能匹配出1x2y3这种奇怪内容运气好点能匹配上运气不好直接取不到。正确写法是1.2.3小数点要转义。还有一个坑是捕获组和模板的配合。正则提取器里填“模板”时$0$代表整个匹配到的内容$1$代表第一个括号里捕获的内容。如果你写了两个括号但模板填的是$2$取到的自然是第二个分组要是括号套括号分组编号还会变化很容易取错。所以建议非必要不加多余括号或者用(?:)这种非捕获分组来避免干扰。另外贪婪匹配也容易出问题。比如提取HTML里和之间的内容正则写成(.)它默认会贪婪匹配到最远的闭合标签如果页面里有多个title标签或类似结构结果就会偏离预期。要改成(.?)非贪婪模式匹配到最近的闭合标签为止。还有一个细节匹配数字如果填0代表随机取一个匹配项如果响应里有多个符合条件的内容取到的可能不是你要的那个。调试时先手动查一下响应里到底有几个匹配项再决定匹配数字填几。4.3 响应中文乱码断言怎么都匹配不上接口返回的中文在查看结果树里显示成乱码这是不少人崩溃的瞬间。其实乱码的本质是编码不匹配。服务端返回的是GBK编码JMeter默认按ISO-8859-1或UTF-8解析两边对不上必然乱成一团。解决办法要看响应头里的charset字段。如果响应头写了charsetGBKJMeter在正常情况下应该能识别但有些服务端响应头没写或者写得不标准JMeter就会猜错。最简单的办法是在HTTP请求取样器里设置“内容编码”字段如果接口返回GBK就填GBK返回UTF-8就填UTF-8这样请求体和响应体都会按这个编码处理。对于已经在跑的脚本也可以加一个后置处理器用BeanShell动态设置响应编码prev.setDataEncoding(UTF-8);这里把UTF-8换成实际的服务端编码即可。另外断言时如果匹配中文失败先检查是不是乱码导致文本不一致。我见过好几个人断言写“包含成功”但接口实际返回的是“success”中文断言自然匹配不上。这种问题不怪JMeter怪没看真实响应内容。用查看结果树复制实际返回的文本再决定断言怎么写别靠猜。5. 脚本逻辑与参数化陷阱不只是报错更是隐蔽问题最后一类问题最隐蔽表面看没有红色报错但结果就是不对。它藏在脚本逻辑和参数化配置里需要一点一点排查才能发现。我把最常见的几个列出来很多都是我踩过得出的经验。5.1 跨线程组变量传不过去有个经典场景第一个线程组负责登录提取出登录后的Token第二个线程组负责业务请求想用${Token}引用第一个线程组里提取的变量结果发现永远是空。这不是提取器的问题而是JMeter变量作用域的机制导致的。JMeter变量是线程内隔离的每个线程在自己的生命周期里保存变量线程结束变量就没了。跨线程组默认根本不共享。解决办法是用属性来传值。在第一个线程组的提取器后面加一个BeanShell后置处理器props.put(Token, vars.get(Token));然后在第二个线程组里用${__P(Token)}来引用。也可以用函数${__setProperty()}一步到位。要注意属性是全局的如果多个线程各自提取了不同的Token往同一个属性里写后者会覆盖前者并发高的时候会出现串数据。这种情况适合把提取出来的值写到CSV文件或者用“用户定义的变量”提前初始化再配合不同线程编号组装参数避免互相覆盖。5.2 断言失败但响应内容明明是对的响应断言标红但点开查看结果树响应数据明明就是200内容也正常。这种“灵异事件”通常出在断言的匹配方式上。我见过最多的原因是响应里确实有目标文本但前后多了空格、换行、转义字符导致精确匹配失败。响应断言的匹配规则有好几种“包括”的意思是从文本里找子串只要包含就算通过“相等”的意思是完全一致一个字节都不能差。很多人默认用了“相等”实际接口返回带了尾巴比如JSON最后有换行符断言就翻车了。想不太严格优先选“包括”断言文本尽量短选一段稳定不变的关键内容比如接口返回{code:0}就断言code:0别把大段完整响应贴进去。还有一点要注意响应断言默认会匹配主样本如果请求里带了子请求、重定向断言会不会把子请求结果也算进来会。如果不需要检查子请求把“应用到”范围改成“主样本”减少误判。5.3 CSV参数化文件读不出来、读不全、读乱码CSV Data Set Config是参数化的常用组件但它在细节上的坑能让人抓狂。最常见的三个问题变量一直是空、运行几行就停、中文参数乱码。先说为什么变量一直是空。检查点有三个文件路径、文件编码、分隔符。文件路径如果写的是相对路径它是相对JMeter启动目录来解析的不是相对脚本文件位置。假如你双击启动JMeter时工作目录是bin那你写相对路径就很容易找不到文件。我的建议是直接用绝对路径或者把文件路径放到JMeter属性里运行时用${__P(csvPath)}指定这样脚本换机器也不用改来改去。文件编码问题也常见CSV文件如果是Windows记事本默认保存的很可能是ANSI编码而JMeter读取时按UTF-8解析中文必然乱码。解决办法是用编辑器另存为UTF-8无BOM格式注意一定不要带BOM带BOM会让第一列第一个参数前面多一个不可见字符拼进URL里报错都找不到原因。“跑了几行就停”通常是并发数和数据行数匹配不上。CSV配置里有两个参数Recycle on EOF文件读完后是否重新循环和Stop thread on EOF文件读完后是否停止线程。如果Recycle选FalseStop选True那么文件读完之后所有线程直接结束并发量没跑满压力就不够。压测场景一般把Recycle开成True让数据循环使用需要严格数据唯一时保证数据行数大于线程数一次性使用到底。5.4 动态Token类接口固定参数跑一次就废很多系统有CSRF Token或签名机制第一次请求页面拿到Token第二次提交业务必须带上这个Token。如果直接把Token写成固定值跑一次可以跑第二第三次就发现服务端返回校验错误。这类问题要用关联来解决思路很简单先用提取器从前置请求响应中取出Token再在后置请求里引用。如果一个流程里有多个请求要携带同一个Token建议把提取到的值存入用户自定义变量或者用属性传递。比如vars.put(csrfToken, 提取到的值);后面的请求引用${csrfToken}即可。需要注意并发场景下高并发时多个用户共享同一个Token会被服务端识别为异常这时候需要让每个用户独立走一遍“获取Token”的前置请求保证Session和Token一一对应。配合HTTP Cookie管理器JMeter会自动化保存Cookie实现每个线程独立的会话状态。我试过用固定Token跑200并发结果服务端把一大半请求判断为非法访问直接在网关层拒了。换成用户独立获取Token后一切恢复正常。所以动态参数问题本质上不是JMeter不会用而是测试数据准备要符合业务语义。写到这里我和JMeter报错死磕的经历差不多就完了。还是要说一句心里话这类工具出问题最怕的不是报错本身而是没有排查顺序。我后来养成习惯遇到任何诡异问题先翻jmeter.log再看压测机资源占用然后从网络层到数据层到脚本逻辑一层层筛绝大多数问题都能落回这几个大类里。刚开始最菜的那段时间几乎每个报错都要折腾半天多踩几次坑之后看到报错反而有一种老朋友见面的感觉。希望这份汇总能让你少走点弯路至少在下一次看到那些大红字的时候心里有个底。
用JMeter做压测的这些年我手机里存的报错截图快赶上照片数量了。每回脚本跑不起来群里就有人甩一张红色日志出来问咋回事来来回回都是那几个经典问题。这次不聊高深理论也不贴大段官方文档就纯把常见报错一条条拎出来说说它们长什么样、根子出在哪、我是怎么收拾的。内容按真实使用顺序来排先环境启动再资源内存然后网络连接接着响应取值最后是脚本逻辑。无论你是刚上手JMeter的测试新人还是已经跑了几个月压测的工程师都可以直接把这篇文章当成一张排查地图来用。1. 前置环境光启动JMeter就能卡住的那些坑JMeter启动阶段的问题看起来小儿科但真遇到了很耽误事。很多人解压完JMeter双击bat文件窗口一闪就没了或者日志里冒出一屏红色异常这时最容易慌了手脚。其实这类问题根源很集中无非就是Java版本不匹配或者启动方式不对。1.1 Java版本不符JMeter直接闪退最常见的报错长这样UnsupportedClassVersionError: org/apache/jmeter/XXX has been compiled by a more recent version of the Java Runtime这句话说白了就是JMeter编译时用的Java版本比你机器上跑的Java版本新当前JVM不认它的class文件。JMeter每个大版本对JDK版本都有最低要求像5.x系列基本要Java 8以上近几个版本官方建议用Java 11甚至Java 17长期支持版。你要是装了个老JDK启动这关就过不去。我的排查套路很简单先在命令行敲一句java -version看清楚当前默认Java到底是哪个版本。很多时候机器上装了不止一个JDK环境变量或者Path里的顺序乱了JMeter启动脚本找到的是个老版本。尤其Windows下双击jmeter.bat时闪退根本看不到报错我建议先开一个cmd窗口手动切到JMeter的bin目录执行jmeter.bat -v这样所有报错都留在控制台里逐行看过去问题基本就暴露了。确认是版本问题就装一个长期支持版JDK把JAVA_HOME环境变量指过去。注意设置完环境变量要重新开终端不要在当前窗口直接跑读不到新配置。更稳一点的做法是在jmeter.bat顶部直接把JAVA_HOME路径写死这样就算以后别的软件把环境变量改乱了JMeter也不受影响。1.2 GUI跑大并发CPU先被工具自己吃掉还有一种问题不算“报错”但遇到的人非常多在图形界面里直接开几千并发JMeter自己CPU飙到100%窗口卡到拖不动最后跑出来的数据也没法信。为什么会这样因为在GUI模式下JMeter需要把每个取样器的结果实时刷新到界面查看结果树、聚合报告这些监听器还要把所有响应数据收进内存做统计。线程越多工具自身的开销越大相当于压测队伍还没上场工具先把自己累趴了。所以这里我强烈建议分场景处理调试脚本用GUI真正的压力测试用命令行模式。我日常执行压测的命令是jmeter -n -t 压测脚本.jmx -l result.jtl -e -o html报告目录这条命令跑完后会直接生成一份HTML图形报告吞吐率、响应时间、错误率都有。平时脚本里放的监听器在命令行模式下影响很小基本不拖性能。另外提醒一句压测机资源是有限预算跑大并发时尽量不要在同一台机器上开着浏览器、微信、网盘这些吃内存的东西把CPU和内存全让给JMeter结果才有参考意义。2. 压测过程中最常见的内存与资源问题进程刚起来脚本也跑通了接下来真正头疼的是压测过程中冒出来的异常。内存类报错在JMeter里出现频率极高尤其是长时间跑稳定性测试的时候几乎每隔一阵子就会有人在群里发同样的截图。这类问题处理起来并不难但前提是得懂一点点JVM的基本概念不然容易瞎调。2.1 OutOfMemoryError: Java heap space这个报错很多人跑着跑着就撞上了尤其GUI模式下开着查看结果树跑长时间压测响应数据不断被塞进内存堆空间很快就顶不住。报错信息里已经写得很明白Java堆内存不够用了。我之前遇到的一次典型场景是跑了一个小时稳定性测试聚合报告和结果树同时开着然后JMeter直接停止采样日志里刷出一堆java.lang.OutOfMemoryError: Java heap space。原因其实就两个一是堆内存给得不够大二是JMeter把太多数据留在了内存里。解决办法分两步。第一步调JMeter的启动堆内存在bin目录下找到jmeter.batWindows或者jmeterLinux/Mac里面有一行类似set HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m这是我见到的默认配置1G堆在现在动辄几百线程的场景下实在不够看我一般会改成set HEAP-Xms2g -Xmx4g -XX:MaxMetaspaceSize512m-Xms是初始堆大小-Xmx是最大堆大小。注意最大堆不是越大越好得看压测机物理内存有多大留一部分给操作系统和网络栈别把整台机器都填满。第二步更重要就是减少无谓的内存占用。GUI模式下能关的监听器尽量关掉结果树尤其别长时间开着看数据。长时间压测收集结果用命令行模式配合简单的写文件监听器就够了数据先落到磁盘压测结束后再打开分析这样JMeter进程内存占用会平稳很多。2.2 GC overhead limit exceeded这个报错和堆内存溢出有亲缘关系但对新手来说更迷惑。出现的信息是java.lang.OutOfMemoryError: GC overhead limit exceeded从JVM机制上说GC是垃圾回收器在打扫堆内存里的无用对象。如果堆填得差不多满了GC就会不停工作回收效果却很差回收一点又立刻填满。JVM遇到连续垃圾回收占用了大量CPU时间但释放内存却很少的情况就会主动抛这个错防止程序彻底无响应。我遇到GC报错时第一反应不是继续加内存而是先看看脚本里有没有把大量数据留在内存里的组件。比如循环次数很大的循环控制器里面套CSV数据源或者正则表达式匹配了超大响应文本都会造成对象堆积。先用命令看一下GC情况jstat -gcutil 进程PID 1000这个命令每秒输出一次GC统计如果看到FGCFull GC频率特别高而且老年代空间一直居高不下基本就是对象释放不了。处理建议有三条清理脚本里不必要的监听器减少响应数据处理改成命令行模式跑最后才考虑加大堆内存。另外如果脚本本身有内存泄漏写法比如在循环里使用BeanShell不断创建大对象那加再多内存也没用得先把代码改对。2.3 聚合报告吞吐率突然变低这可能不算报错但绝对算问题。很多人跑压测时发现一个诡异现象并发数不断往上加聚合报告里的TPS却低得离谱甚至比低并发时还低。这时候可以先去压测机上看看CPU和内存占用再用top或者任务管理器看一眼JMeter进程状态。我之前排查过一次类似问题脚本本身很简单但压测机是个配置一般的Windows笔记本开了两千并发后笔记本CPU直接打满网络连接数也到了极限JMeter自己都跑不动了TPS自然上不去。所以压测机配置不够的时候优先考虑降低JMeter自身开销用命令行模式关掉不必要的功能或者直接换一台配置更好的压测机。还有人为了模拟用户思考时间在脚本里加了固定定时器或常数吞吐量定时器结果TPS被定时器卡死高并发也冲不上去。这种情况不算故障是脚本本身限流了看脚本里有没有这类组件就行。3. 网络与连接层连接拒绝、端口耗尽、连接超时如果说内存问题是JMeter自己的毛病那网络层面的问题就有点“甩锅”性质了。很多时候脚本运行报错其实是底层网络连接出了问题。这类报错信息五花八门但归结起来就那么几类。3.1 Address already in use 端口被占满这个报错在Windows上跑高并发短连接时非常容易遇到日志里写着java.net.BindException: Address already in use: connect用大白话解释一下TCP连接需要有源端口系统给客户端分配一个临时端口连接结束后端口不会马上释放而是进入TIME_WAIT状态要等一段时间才能重新使用。Windows默认TIME_WAIT比较长如果你用JMeter发起大量短连接瞬间把可用端口全占光了新连接就没有端口能用于是报Address already in use。我在某次压力测试时跑到一半就遇到这个当时一看系统连接状态TIME_WAIT状态的连接有几万个。解决办法从几个方向入手压测请求尽量开启Keep-Alive让HTTP连接复用减少短连接数量这是最省事的做法。Windows系统层面调大可用端口范围在管理员命令行执行netsh int ipv4 set dynamicport tcp start1025 num64510然后把注册表里的TcpTimedWaitDelay调小比如从默认240秒调到30秒减少TIME_WAIT占用时间。Linux压测机也可以调大端口范围sysctl -w net.ipv4.ip_local_port_range1024 65000这里提醒一句调整系统参数后最好重启JMeter进程让连接池重新初始化。3.2 Connection refused 目标端口根本不理你java.net.ConnectException: Connection refused: connect这个报错字面意思很明确客户端发起的连接被目标机器拒绝了。听到这个错误我一般从下面几个原因排查。第一目标服务真的没起来或者没监听对应端口。先用curl测试一下接口能不能通比如curl -v http://目标地址:端口/路径如果curl也报连接失败那就是服务端或者网络问题先别怀疑JMeter。第二防火墙或安全组把端口挡了这个在云环境里特别常见配置了安全组规则但漏放压测机IP结果本机测试没问题从压测机跑就报拒绝。第三目标服务的连接队列满了比如Tomcat的acceptCount配得比较小并发一上来内核accept队列塞满新连接直接拒绝。这种时候看服务端日志会有相关记录需要调大服务端的accept队列和线程池配置。我遇到过最迷惑的一次是压测机和被测服务在同一台机器上curl探测完全正常JMeter却报Connection refused。后来发现JMeter脚本里填的IP是域名解析到了内网其他机器那个机器根本没开服务。所以排查时第一件事就是确认地址和端口写的对不对。3.3 Connection reset / Read timed out 连接断掉、响应太慢还有两类高频网络报错一是java.net.SocketException: Connection reset另一个是java.net.SocketTimeoutException: Read timed outConnection reset通常是服务端主动关闭了连接。最常见的情况是服务端设置了较短的KeepAlive超时客户端连接池里还留着这个连接下次请求时连接其实已经失效了一读写就报reset。处理思路是把JMeter的HTTP请求设置为连接复用策略匹配服务端的KeepAlive超时配置或者干脆在请求头里加Connection: close让每个请求都新建连接牺牲一点性能换稳定。也有人通过调整JMeter的httpclient连接池属性来处理比如在jmeter.properties里设置httpclient4.retry.count1让请求失败后自动重试一次能减少不少偶发报错。Read timed out则是响应超时服务端处理太慢超过了JMeter里设置的响应超时时间。这种情况要区分是偶尔发生还是大面积发生。偶尔发生可以适当调大响应超时比如从默认的几十秒改成120秒大面积发生就说明服务端确实扛不住了这时候该做的是看后端性能瓶颈而不是头铁加超时时间。4. 响应提取与编码JSON、正则、乱码三连坑前面几个问题搞定后脚本基本能跑顺手了但接下来还有一坑等着从响应里取数据。接口压测几乎都会涉及参数关联比如登录之后拿Token下单之后拿订单号。这些动态数据取不出来后续请求全废。这部分的报错不会直接弹红而是变量取出来是空的请求参数变成一堆undefined排查起来反而更费劲。4.1 JSON提取器看起来正常结果却是nullJSON Extractor是现在用得最多的提取器但它翻车概率不低。最典型的现象是配置界面看起来完全正确运行后Debug Sampler里变量却是null或者一直等于你填的“默认值”。出现这种情况我第一件事就是打开查看结果树先把实际响应内容复制出来粘贴到JSONPath Tester里一条条验证表达式。写错JSONPath是高发问题比如接口返回是{data: {list: [{id: 1, name: 张三}]}}有人想当然写成$.data.list.id这显然取不到要写成$.data.list[0].idlist是数组必须带下标。还有一些返回嵌套多层一次定位不到可以用模糊定位$..id先看看能不能取到值再逐步收窄。另一个容易忽略的地方是JSON Extractor有个“Match No.”参数默认0代表随机匹配。如果响应里匹配到了多个值那就可能每次取到的都不一样业务逻辑就乱了。需要固定取第一个时要把Match No.设为1。还有那个“默认值”字段提取失败时不会报错而是默认值很多人调试时看到变量等于默认值以为是提取成功其实根本没取到。我建议调试阶段把默认值故意填一个醒目的错误内容比如ERROR这样一眼就能看出提取有没有成功。4.2 正则表达式写对了变量还是空空如也老项目、非JSON接口用正则提取的场景依然很多正则提取器的坑也比较经典。最常见的翻车原因是对特殊字符处理不当。比如要从版本号1.2.3里提取正则写成(1.2.3)这个点号在正则里是“任意字符”的意思不是小数点本身很可能匹配出1x2y3这种奇怪内容运气好点能匹配上运气不好直接取不到。正确写法是1.2.3小数点要转义。还有一个坑是捕获组和模板的配合。正则提取器里填“模板”时$0$代表整个匹配到的内容$1$代表第一个括号里捕获的内容。如果你写了两个括号但模板填的是$2$取到的自然是第二个分组要是括号套括号分组编号还会变化很容易取错。所以建议非必要不加多余括号或者用(?:)这种非捕获分组来避免干扰。另外贪婪匹配也容易出问题。比如提取HTML里和之间的内容正则写成(.)它默认会贪婪匹配到最远的闭合标签如果页面里有多个title标签或类似结构结果就会偏离预期。要改成(.?)非贪婪模式匹配到最近的闭合标签为止。还有一个细节匹配数字如果填0代表随机取一个匹配项如果响应里有多个符合条件的内容取到的可能不是你要的那个。调试时先手动查一下响应里到底有几个匹配项再决定匹配数字填几。4.3 响应中文乱码断言怎么都匹配不上接口返回的中文在查看结果树里显示成乱码这是不少人崩溃的瞬间。其实乱码的本质是编码不匹配。服务端返回的是GBK编码JMeter默认按ISO-8859-1或UTF-8解析两边对不上必然乱成一团。解决办法要看响应头里的charset字段。如果响应头写了charsetGBKJMeter在正常情况下应该能识别但有些服务端响应头没写或者写得不标准JMeter就会猜错。最简单的办法是在HTTP请求取样器里设置“内容编码”字段如果接口返回GBK就填GBK返回UTF-8就填UTF-8这样请求体和响应体都会按这个编码处理。对于已经在跑的脚本也可以加一个后置处理器用BeanShell动态设置响应编码prev.setDataEncoding(UTF-8);这里把UTF-8换成实际的服务端编码即可。另外断言时如果匹配中文失败先检查是不是乱码导致文本不一致。我见过好几个人断言写“包含成功”但接口实际返回的是“success”中文断言自然匹配不上。这种问题不怪JMeter怪没看真实响应内容。用查看结果树复制实际返回的文本再决定断言怎么写别靠猜。5. 脚本逻辑与参数化陷阱不只是报错更是隐蔽问题最后一类问题最隐蔽表面看没有红色报错但结果就是不对。它藏在脚本逻辑和参数化配置里需要一点一点排查才能发现。我把最常见的几个列出来很多都是我踩过得出的经验。5.1 跨线程组变量传不过去有个经典场景第一个线程组负责登录提取出登录后的Token第二个线程组负责业务请求想用${Token}引用第一个线程组里提取的变量结果发现永远是空。这不是提取器的问题而是JMeter变量作用域的机制导致的。JMeter变量是线程内隔离的每个线程在自己的生命周期里保存变量线程结束变量就没了。跨线程组默认根本不共享。解决办法是用属性来传值。在第一个线程组的提取器后面加一个BeanShell后置处理器props.put(Token, vars.get(Token));然后在第二个线程组里用${__P(Token)}来引用。也可以用函数${__setProperty()}一步到位。要注意属性是全局的如果多个线程各自提取了不同的Token往同一个属性里写后者会覆盖前者并发高的时候会出现串数据。这种情况适合把提取出来的值写到CSV文件或者用“用户定义的变量”提前初始化再配合不同线程编号组装参数避免互相覆盖。5.2 断言失败但响应内容明明是对的响应断言标红但点开查看结果树响应数据明明就是200内容也正常。这种“灵异事件”通常出在断言的匹配方式上。我见过最多的原因是响应里确实有目标文本但前后多了空格、换行、转义字符导致精确匹配失败。响应断言的匹配规则有好几种“包括”的意思是从文本里找子串只要包含就算通过“相等”的意思是完全一致一个字节都不能差。很多人默认用了“相等”实际接口返回带了尾巴比如JSON最后有换行符断言就翻车了。想不太严格优先选“包括”断言文本尽量短选一段稳定不变的关键内容比如接口返回{code:0}就断言code:0别把大段完整响应贴进去。还有一点要注意响应断言默认会匹配主样本如果请求里带了子请求、重定向断言会不会把子请求结果也算进来会。如果不需要检查子请求把“应用到”范围改成“主样本”减少误判。5.3 CSV参数化文件读不出来、读不全、读乱码CSV Data Set Config是参数化的常用组件但它在细节上的坑能让人抓狂。最常见的三个问题变量一直是空、运行几行就停、中文参数乱码。先说为什么变量一直是空。检查点有三个文件路径、文件编码、分隔符。文件路径如果写的是相对路径它是相对JMeter启动目录来解析的不是相对脚本文件位置。假如你双击启动JMeter时工作目录是bin那你写相对路径就很容易找不到文件。我的建议是直接用绝对路径或者把文件路径放到JMeter属性里运行时用${__P(csvPath)}指定这样脚本换机器也不用改来改去。文件编码问题也常见CSV文件如果是Windows记事本默认保存的很可能是ANSI编码而JMeter读取时按UTF-8解析中文必然乱码。解决办法是用编辑器另存为UTF-8无BOM格式注意一定不要带BOM带BOM会让第一列第一个参数前面多一个不可见字符拼进URL里报错都找不到原因。“跑了几行就停”通常是并发数和数据行数匹配不上。CSV配置里有两个参数Recycle on EOF文件读完后是否重新循环和Stop thread on EOF文件读完后是否停止线程。如果Recycle选FalseStop选True那么文件读完之后所有线程直接结束并发量没跑满压力就不够。压测场景一般把Recycle开成True让数据循环使用需要严格数据唯一时保证数据行数大于线程数一次性使用到底。5.4 动态Token类接口固定参数跑一次就废很多系统有CSRF Token或签名机制第一次请求页面拿到Token第二次提交业务必须带上这个Token。如果直接把Token写成固定值跑一次可以跑第二第三次就发现服务端返回校验错误。这类问题要用关联来解决思路很简单先用提取器从前置请求响应中取出Token再在后置请求里引用。如果一个流程里有多个请求要携带同一个Token建议把提取到的值存入用户自定义变量或者用属性传递。比如vars.put(csrfToken, 提取到的值);后面的请求引用${csrfToken}即可。需要注意并发场景下高并发时多个用户共享同一个Token会被服务端识别为异常这时候需要让每个用户独立走一遍“获取Token”的前置请求保证Session和Token一一对应。配合HTTP Cookie管理器JMeter会自动化保存Cookie实现每个线程独立的会话状态。我试过用固定Token跑200并发结果服务端把一大半请求判断为非法访问直接在网关层拒了。换成用户独立获取Token后一切恢复正常。所以动态参数问题本质上不是JMeter不会用而是测试数据准备要符合业务语义。写到这里我和JMeter报错死磕的经历差不多就完了。还是要说一句心里话这类工具出问题最怕的不是报错本身而是没有排查顺序。我后来养成习惯遇到任何诡异问题先翻jmeter.log再看压测机资源占用然后从网络层到数据层到脚本逻辑一层层筛绝大多数问题都能落回这几个大类里。刚开始最菜的那段时间几乎每个报错都要折腾半天多踩几次坑之后看到报错反而有一种老朋友见面的感觉。希望这份汇总能让你少走点弯路至少在下一次看到那些大红字的时候心里有个底。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
