跑性能测试的时候最怕的就是脚本跑到一半突然冒出来一个看不懂的报错。今天要聊的Begin size 0 is not equal to fixed size 5就是这类问题的典型代表脚本前几分钟还跑得好好的结果并发一上来日志开始疯狂刷这段报错而且它不像 NPE 那样会告诉你在哪一行、哪个组件只丢给你一句规模对不上就没了下文。这篇文章会把这个问题彻底拆开讲清楚它背后的触发原理、最容易踩的四个场景、从日志到脚本的完整排查流程以及一个真实压测中的修复案例帮你在下次遇到时能快速定位几分钟内解决。适合正在用 JMeter 做接口测试、性能压测的同学尤其是脚本里用了正则提取器、JSON 提取器、Beanshell 或者 CSV 参数化的朋友。1. 先从根源说起这个报错到底在说什么1.1 拆解报错信息Begin size 0 与 fixed size 5 的真实含义先把这个报错拆成两半看。前半句Begin size 0说的是实际要处理的数据在还没开始处理的时候大小是 0。换句话说某个集合、数组或者数据集在运行时是空的一个元素都没有。后半句fixed size 5说的是程序里写死了一个固定大小为 5 的目标容器或预期结构。比如代码里new String[5]、正则配置了 5 个变量、或者某个接口约定固定返回 5 个字段这些都是固定大小的来源。当程序尝试把前者空数据装入后者固定大小 5时就会抛出一句Begin size 0 is not equal to fixed size 5。说白了就是我预期要 5 个数据结果你给了我 0 个这个活儿没法干。这个报错有个很明显的特点它本身不携带组件信息不会直接告诉你谁在等 5 个数据。所以很多人第一次遇到会本能地去搜这句话结果发现网上答案都很零散越看越迷糊。我的建议是别纠结这句话本身先去想一个问题你的 JMeter 脚本里哪里写死了 5这个 5 是正则提取器的模板数量是脚本里new出来的数组长度还是你从某个接口响应里固定的字段个数找到这个 5问题就解决了一半。因为这个报错的本质就是一次数据结构规模校验失败它的核心原因是预期规模和实际规模不一致而不是某个功能坏了。当你把它当成规模对不上的问题来看排查思路就清晰了。1.2 为什么偏偏是 size 5固定大小的常见来源这个5不是凭空冒出来的它是脚本里某个位置明确写死的数字。我在实际排障踩坑中总结了一下最常见的固定大小来源有下面几种每一种都对应一类 JMeter 使用场景。固定大小的来源具体表现典型场景正则表达式提取器模板数配置了$1$到$5$期望取 5 个匹配组从响应中提取多个订单号、商品 IDJSR223/Beanshell 脚本中的数组String[] data new String[5]硬编码长度脚本里组装请求报文、做数据变换CSV 参数化的字段列数脚本引用col_5但 CSV 文件只有 3 列用户登录参数化、多字段数据驱动接口响应约定的固定字段登录接口约定返回 token 4 个权限位接口之间存在强依赖下游获取上游字段正则提取器是重灾区。我在团队里看过不少脚本正则提取器里模板写了$1$$2$$3$$4$$5$意思是从一段响应里提取 5 段内容分别存成var_1、var_2、var_3、var_4、var_5。但如果响应数据里只匹配到了 1 段甚至 0 段那么var_2到var_5就是空白的。这时脚本后面的 Beanshell 或者 JSR223 断言只要引用了这些变量就会触发上面那个规模校验错误。另外CSV 参数化也容易出现类似问题。你有没有遇到过这种情况CSV 文件只准备了 20 行测试数据但线程组里配了 50 个线程每个线程循环 5 次这样一来总共需要 250 条数据但文件只有 20 条跑到第 21 次就取不到值了。如果这时候脚本里有一个固定大小的数组或者固定个数的变量引用那么报错就是迟早的事。所以一看到Begin size 0我第一反应不是去看报错那一行代码而是先去梳理整个脚本里的数据流向看看哪一个环节的数据规模可能撑不住。2. 最常见的四个触发场景你中招了没有2.1 正则提取器匹配数量不足时硬取固定下标先讲正则提取器因为这是最普遍的场景。假设你有一个登录接口响应返回了一串 JSON你想提取其中 token 字段下面的多个值比如 permissions 数组里的权限码。正则表达式提取器配置了变量名perm模板$1$匹配数字-1表示匹配全部。那么 JMeter 会自动生成perm_matchNr来记录总匹配数同时生成perm_1、perm_2、perm_3等变量每个对应一个权限码。问题就出在后续脚本。有些同学图省事直接在后续的 JSR223 断言里写死了perm_5想当然地认为权限码一定有 5 个。结果某次压测时服务端调整了权限策略某个测试账号只返回了 2 个权限码。perm_5直接变成 null而代码里偏偏有一个固定大小为 5 的数组在等它瞬间就爆出Begin size 0 is not equal to fixed size 5。这个场景的核心教训是提取器的匹配结果数量永远不要假设它固定不变。测试数据变了、接口响应变了、账号权限变了匹配数量随时可能变化。正确的做法是使用perm_matchNr来动态获取实际匹配数量再循环处理而不是写死访问perm_5。在后面的排查实操部分我会给出具体的动态循环写法。2.2 Beanshell/JSR223 脚本中数组转换不做判空第二种场景是在脚本里手工操作数据。JMeter 中经常用 JSR223 Sampler 或者 JSR223 断言来处理一些复杂逻辑比如把请求返回的数据转成数组再逐项校验。很多人写脚本的时候会下意识地写类似这样的代码String[] expected new String[5]; def actual vars.get(dataList).tokenize(,); expected actual.toArray(new String[5]);这段代码看起来没什么问题但注意一个隐藏风险如果dataList这个变量是空的比如接口在异常情况下没有返回这个字段那么actual就是一个空列表actual.toArray(new String[5])在执行时就会出现规模不匹配的问题。因为空列表的大小是 0而你传入的目标数组大小固定是 5。可能有人会说toArray方法在传入数组大小足够时会正常返回空列表也可以转成大小为 5 的数组元素全是 null。但问题在于JMeter 底层的某些集合工具类在转换时会对 begin size 和 fixed size 做严格校验一旦不一致就会直接抛异常。所以这不是普通 Java 编码习惯能覆盖到的地方而是 JMeter 特有的坑。我的经验是在脚本里做任何数组转换之前先判断一下源数据是否为空。如果为空要么跳过这段逻辑要么给一个默认值不要硬转。2.3 CSV 参数化数据行数与线程配置不匹配第三种场景跟 CSV 参数化有关这类问题通常在长时间压测时才会暴露。比如你做了一个用户登录压测脚本用 CSV Data Set Config 从 users.csv 里读取用户名和密码文件里有 100 行测试数据。线程组配置是 20 个线程每个线程循环 20 次这刚好需要 400 条数据明显超出文件范围。默认情况下CSV Data Set Config 在读取到文件末尾后会重新从第一行开始读取Recycle on EOF默认为 true但如果你不小心把Recycle on EOF设置成了 false或者勾选了Stop thread on EOF那么读取完 100 行之后后面的 300 次循环拿到的参数就是空值或EOF。这时候如果脚本里恰好有一个固定大小为 5 的数组或者下游接口校验了固定数量的参数就会报出这个错。我见过一个比较极端的案例同事用 CSV 参数化做下单接口压测CSV 里有商品 ID 和数量两列但脚本里引用了 5 个变量除了商品 ID 和数量还引用了city_1、city_2、city_3三个字段CSV 文件里根本没有这三列。脚本跑起来后前几个请求正常后面开始陆续报错最终定位到就是这个原因。所以说CSV 参数化的列数和脚本中引用的变量数必须严格对应数据行数也要提前估算好否则压测中报错是必然的。2.4 后端接口异常导致 JSON 提取落空第四种场景也是最隐蔽的一种就是后端接口在压力下偶发异常导致响应结构变化JSON 提取器落空。这个问题我在压测过程中遇到过很多次而且它非常难排查因为问题不在脚本而在服务端。举个例子压测一个下单接口它依赖登录接口返回的 token。脚本的逻辑是先调用登录接口用 JSON Extractor 提取$.data.token存到变量token里下单接口再使用这个 token。前几分钟一切正常但并发量升高后登录接口开始偶发 500 或者超时返回的内容变成{code:500,message:server error}根本没有data.token这个节点。JSON Extractor 提取不到token变量就不存在了下游下单接口拿到的 token 是空的于是后面的断言、参数组装就连环出错。如果你的脚本里恰好有固定大小 5 的依赖结构比如登录接口除了返回 token 还返回 5 个权限码服务端异常时权限码一个都没返回那就会直接触发Begin size 0 is not equal to fixed size 5。这种场景的本质是上游接口的异常响应没有被脚本兜住导致下游变量链断裂。排查时要把目光从报错点往上游移动找到那个本来应该给数据却给了空数据的接口。3. 排查这个报错的完整实操流程跟着做就行3.1 第一步锁定报错出现的取样器和监听器堆栈遇到这个报错我建议先不要瞎猜直接去看 JMeter 的日志。JMeter 运行时会往bin目录下的jmeter.log写日志里面会记录每个取样器的报错堆栈这是定位问题最直接的信息源。在 Linux 环境下可以进入 JMeter 的 bin 目录执行tail -f jmeter.log | grep -A 50 Begin size这样能实时过滤出和这个报错相关的日志块重点是看堆栈的前几行它通常会指出异常是从哪个取样器、哪个后置处理器抛出来的。在 Windows 环境下可以直接用文本编辑器打开jmeter.log用 CtrlF 搜索关键字Begin size然后往上看上下文找到是哪个线程组、哪个取样器在执行时报的错。我记得有一次排查就是在堆栈里看到JSONPathPostProcessor的字样才把范围缩小到 JSON 提取器上。所以说日志一定要先看它能帮你省掉大半的无效排查时间。另外如果你用了 Beanshell 或者 JSR223 脚本建议在脚本里主动加一些日志输出比如log.info(当前变量值: vars.get(xxx))这样日志信息会更完整后面定位问题会轻松很多。3.2 第二步用调试取样器抓取变量实际值如果日志里的堆栈信息不够直观下一步就是确认所有变量在报错那一刻的实际值。JMeter 自带一个特别好用的组件叫 Debug Sampler调试取样器它能打印出当前线程所有的 JMeter 变量帮你一眼看出哪个变量是空的或者没被创建。添加方式很简单在测试计划中选中需要排查的线程组右键菜单选择AddSamplerDebug Sampler添加之后双击进入配置页把JMeter Variables和JMeter Properties这两个选项勾上其他保持默认。然后运行脚本添加 View Results Tree察看结果树监听器选中刚才的 Debug Sampler在响应数据里就能看到一份完整的变量列表。拿到这份变量列表后重点观察两个信息。一是xxx_matchNr这类变量它表示正则或 JSON 提取器实际匹配到的数量如果它是 0 或者小于预期的 5就说明是提取落空的问题。二是具体的xxx_5、xxx_4这些带下标的值如果它们根本不在列表里也说明匹配数量不足。这个调试方法几乎适用于所有 JMeter 变量相关的报错排查我建议把 Debug Sampler 当作固定弹药平时调试脚本时就加上排查完再删掉非常实用。3.3 第三步精准修复的三种代码写法根据前面两步定位到的原因修复思路通常有三种写法。第一种是判空保护这也是最通用的方案。在 JSR223 断言或采样器脚本里凡是使用提取变量之前先判断变量是否存在、是否为空。这里我推荐用 Groovy 脚本JMeter 5.x 之后 JSR223 默认支持 Groovy性能也比 Beanshell 好很多示例如下def value vars.get(perm_5) if (value ! null !value.isEmpty()) { // 正常逻辑使用 value log.info(perm_5 的值为: value) } else { // 兜底逻辑跳过或使用默认值 log.warn(perm_5 为空跳过本次校验) }第二种是动态长度遍历适用于需要处理多个匹配结果的场景。不要写死访问xxx_5而是用xxx_matchNr动态判断实际数量然后循环处理。示例代码def count vars.get(perm_matchNr) if (count null) { count 0 } def total Integer.parseInt(count) for (int i 1; i total; i) { def current vars.get(perm_ i) log.info(第 i 个权限码: current) // 在这里做后续处理 }第三种是给提取器配置默认值。在正则表达式提取器、JSON Extractor、CSS/JQuery Extractor 等组件的配置界面里都有一个Default Value字段。这个字段的作用是当提取不到任何内容时用默认值填充变量避免变量缺失。我习惯把默认值设成空字符串或者NOT_FOUND这样下游即使取到默认值也不会让整个变量链断掉同时还能通过断言判断值是否为NOT_FOUND来做兜底。注意如果设成空字符串仍然需要结合判空代码使用否则空字符串参与业务逻辑一样会出问题。4. 一个完整的修复案例从复现到解决的全程记录4.1 复现场景接口列表压测中的空响应讲一个我实际处理过的案例这样更有参考价值。当时我们在压测一个电商项目的下单接口脚本结构是这样登录接口获取 token 和用户权限列表然后下单接口携带这些信息下单。登录接口的响应里权限列表一共有 5 个字段包含用户等级、积分倍率、优惠券类型等脚本用一个正则提取器把这 5 个字段分别提取为level、pointRate、couponType、memberTag、channelCode五个变量。压测配置是 50 个线程持续运行 10 分钟。刚开跑的前 2 分钟一切正常大约从第 3 分钟开始聚合报告里的错误率开始往上飙最终冲到 15% 左右。查看日志主要报错就是Begin size 0 is not equal to fixed size 5。当时的第一反应是脚本的正则表达式写错了但检查过正则本身和响应样本并没有发现明显问题。后来仔细看结果树发现报错的取样器都是下单接口而登录接口的响应体里有一部分响应的data字段是空的没有权限列表数据。也就是说服务端在并发压力下出现了偶发的空响应。这个问题比较隐蔽因为登录接口本身返回的 HTTP 状态码是 200JMeter 不会把它当作请求失败但实际上响应体里的关键字段已经缺失了。这也解释了为什么错误率不是从 0 突然飙高而是慢慢上升——因为服务端是逐渐开始出现空响应的而且空响应比例越来越高。4.2 修复过程与最终脚本示例定位到根因之后我做了两处修复。第一处是在登录接口后面加了一个响应断言核心是校验data节点下是否包含权限列表字段。如果断言失败就说明这一次登录请求没有拿到有效数据后续断言和下单请求可以直接跳过避免产生一堆无效请求和误导性的报错。当然了在压测场景下更合理的选择其实是让登录接口保持稳定如果后端偶发空响应可以通过断言提前感知并统计而不是让错误在下游蔓延。第二处修复是在 JSR223 断言里用动态遍历替代固定下标。原来的代码里写死了访问 5 个权限字段我改成用matchNr判断实际数量并且对每个具体变量做了判空处理。改完之后的最终关键脚本如下def ls vars.get(permissions_matchNr) def total (ls ! null !ls.isEmpty()) ? Integer.parseInt(ls) : 0 if (total 5) { log.warn(权限字段匹配数量不足实际数量: total) // 这里根据业务决定是跳过还是采样 prev.setSuccessful(false) prev.setResponseMessage(权限列表不完整) } else { for (int i 1; i total; i) { def item vars.get(permissions_ i) if (item null || item.isEmpty()) { log.warn(权限字段为空下标: i) prev.setSuccessful(false) break } } }这样改完之后脚本的逻辑变成先检查匹配数量如果不足 5 个直接标记该请求失败并记录原因如果数量正常再逐个检查变量是否有值。这样就不会出现空数据去匹配固定大小 5的规模冲突了。顺便说一下prev.setSuccessful(false)是 JSR223 断言里比较常用的一个操作它能把当前取样器标记为失败方便在聚合报告里统一统计这个技巧在压测脚本里经常用到。4.3 修复后的验证与压测结果影响脚本修改完成后我没有直接上 50 并发而是先用 10 个并发跑了 3 分钟做验证。确认日志里不再出现Begin size报错之后再恢复 50 并发跑完整轮压测。修复后的压测结果对比如下指标修复前修复后请求错误率15% 左右0.2% 以下平均响应时间因错误请求拖慢恢复正常日志中 Begin size 报错频繁出现完全消失结果可参考性不可用可用这里要特别提醒一下如果脚本本身存在变量依赖链的漏洞那么压测结果中会混入大量因脚本问题导致的错误请求这些数据会严重干扰你对系统性能的判断。你可能看到错误率 15%以为是后端扛不住实际上只是脚本在空数据场景下处理不当。所以在压测之前花一点时间把脚本的容错做好比压测完之后花大量时间分析无效数据要划算得多。这也是我在团队里反复强调的一个观点压测脚本本身的正确性决定了压测结果的有效性这个环节不能省。5. 日常避免这类问题的六个习惯越早养成越好5.1 提取器统一配置默认值别让空值裸奔不管用正则提取器还是 JSON Extractor只要这个变量的值在后续会被使用就一定要配置Default Value。这个默认值可以是空字符串也可以是一个有语义的占位符比如NOT_FOUND。配置了默认值之后即使提取落空变量也不会缺失下游引用时至少不会直接触发规模校验错误。我见过很多脚本正则提取器里默认值一栏是空白的这是很大的隐患。5.2 脚本里少写死固定大小多用动态判断写 JSR223 脚本时凡是和数据规模相关的逻辑尽量不要硬编码。比如获取匹配数量优先用matchNr动态判断组装数组时优先根据实际数据量来创建数组长度。不要图省事写String[5]这种固定长度。数据规模是动态的特别是接口返回的列表、权限、标签这类字段后端随时可能调整数量脚本一旦写死就容易埋雷。这一点在压测脚本里比单元测试代码更要重视因为压测场景下变量值的不确定性更高。5.3 压测前先小并发验证再上量很多人一上来就直接 100 并发、200 并发去跑结果脚本问题导致大量报错最后还要花时间排查是脚本问题还是系统问题。我的习惯是新脚本或者修改过的脚本先设置 5 到 10 个线程跑一轮确认没有脚本层面的报错再逐步加压。这个小步骤只需要多花几分钟但能省掉后面大量排查时间。尤其是涉及多接口依赖、提取器、CSV 参数化的场景小并发验证基本都能提前暴露这类问题。5.4 善用日志与调试取样器保留现场压测过程中建议把日志级别调成 INFO 或 DEBUG并在脚本关键位置添加log.info输出。同时在排查问题场景时Add Debug Sampler 是一个非常有效的手段它能一屏打出所有变量让你快速定位哪个变量是空值。不要小看这个习惯每次压测报错时有日志和没有日志排查速度差了一个量级。JMeter 的脚本本身就是测试代码养成在关键环节打日志的习惯受益是长远的。5.5 对下游强依赖的变量做空值兜底如果 A 接口返回的数据要被 B 接口使用A 请求失败或者响应异常时B 接口有没有兜底方案这是脚本设计时必须考虑的问题。我的建议是对这类强依赖的链路要么在上游接口做断言拦截要么在下游脚本里做判空处理。不要让空值在脚本里一路传递下去最后在一个意想不到的地方爆出来。这个原则同样适用于多线程的测试场景因为不同线程之间变量相互独立一个线程的数据缺失不会影响其他线程但如果每个线程都偶发缺失整个压测的错误率就会显得特别高。5.6 定期检查测试数据文件CSV 参数化的数据文件在压测前后都要检查一遍。检查维度包括数据行数是否充足、列数是否与脚本引用一致、文件末尾是否有空行、编码格式是否正常。我在实践中踩过一个小坑CSV 文件是 UTF-8 编码但 Windows 记事本默认是 ANSI另存之后脚本里读取中文参数就会乱码间接导致后续处理异常。这些小细节平时不起眼压测时都会变成拦路虎。数据文件的维护要多花一点心思最好每次压测之前列一个检查清单逐项确认。6. 最后再分享一个实用小技巧在上面这些场景里最让我受益的一个操作是在脚本开头添加一个 JSR223 Sampler 作为变量健康检查点。它不发起任何实际请求只是把当前线程的关键变量统一打印到日志里。比如这样log.info( 变量健康检查开始 ) log.info(token vars.get(token)) log.info(permissions_matchNr vars.get(permissions_matchNr)) log.info(permissions_1 vars.get(permissions_1)) log.info(permissions_2 vars.get(permissions_2)) log.info( 变量健康检查结束 )把这个 Sampler 放在依赖链路的中间节点每当出现莫名其妙的报错时翻日志就能直接看到上一环节的变量状态。这个小技巧我后来分享给了团队里好几个同事他们反馈排查效率提升明显。总的来说JMeter 脚本报错并不可怕关键是有一套系统的排查思路和良好的脚本编写习惯把边界情况提前处理掉压测结果才真正可信。