如果你经常用 JMeter 做接口压测尤其碰上那些带签名、加密、时间戳的登录态接口JSR223 Sampler 和 JSR223 PreProcessor/PostProcessor 这套组件基本是绕不开的。Groovy 脚本一上你在测试计划里敲 JSR223 这三个字儿的频率会瞬间变高。但用归用我这两年几乎每一次把 BeanShell 换成 JSR223都会在脚本执行阶段卡上一段时间甚至有一次压测任务因为脚本里一个变量作用域写错了整个成功率直接掉到 30% 以下排查到凌晨才发现问题。这篇文章不打算讲那种“照着文档抄一遍”的用法而是把我实际踩过的坑、事后翻源码才搞明白的机制、以及在几个真实压测项目里沉淀下来的脚本写法原原本本整理出来。适合正在用 JSR223 做接口签名、参数构造、响应提取但总觉得脚本“能跑但不够稳”的同学。里面涉及变量作用域、编译缓存、性能和报错排查这些硬话题我会尽量用大白话拆清楚。1. JSR223 组件的基础认知三个组件到底差在哪很多人第一次接触 JSR223是被名字吓住的。其实拆开看就三件事JSR223 Sampler 是一个能执行脚本的取样器JSR223 PreProcessor 挂在某个取样器前面JSR223 PostProcessor 挂在后面。它们核心都是执行同一类脚本代码只是因为挂在测试计划里的位置不同能拿到的上下文对象不一样于是干的活也就不同。1.1 前置、后置、取样器它们的定位差异JSR223 PreProcessor 的核心职责是“在请求发出去之前把准备工作做掉”比如计算签名、生成随机数、往 vars 里塞参数。它本身不产生请求只是准备数据。JSR223 PostProcessor 的核心职责是“在请求响应回来之后把数据抽出来”比如从 JSON 里提取 token、校验响应码、把结果写回变量供后续请求使用。JSR223 Sampler 则是一个独立的取样器它既不发 HTTP 请求也不依赖其他取样器的响应纯粹执行一段脚本逻辑。我常用的场景包括造一批测试数据写到文件里、准备加密报文、或者临时算一个复杂的值塞到后面的请求里。它最大的价值是灵活性但最大的坑也在这里——因为太灵活了很多人会把大量业务逻辑塞进一个脚本里导致脚本变成了一个不可维护的黑洞。1.2 为什么我建议直接放弃 BeanShell统一用 Groovy早期 JMeter 用户习惯用 BeanShell 写脚本毕竟 JMeter 自带的示例基本都是 BeanShell。但我在一次高并发压测里明确感受到两者差距同样的计算逻辑BeanShell 的响应耗时比 Groovy 高了一个量级。原因是 BeanShell 是解释执行每次运行都要重新解析脚本Groovy 则支持编译缓存启动之后脚本会被编译成字节码复用执行效率高得多。从 JMeter 3.1 版本开始官方就明确推荐 JSR223 Groovy 的组合。Groovy 的语法与 Java 高度兼容Java 代码基本可以直接搬进来用同时它又是一门动态语言写起来比纯 Java 精简得多。所以我的建议是新写的脚本统一用 Groovy老脚本也趁早迁移别等压测现场出问题再动手。1.3 先说一个最常见的配置坑脚本语言默认是 BeanShell这个坑我估计十个用 JSR223 的人里有八个踩过。你新建 JSR223 Sampler脚本编辑框右下角有个语言下拉框默认选的是 BeanShell而不是 Groovy。如果你直接默认状态写 Groovy 语法很多代码看起来能跑但实际走的还是 BeanShell 的解释器性能上不去不说个别 Groovy 特有的语法还会直接报错。我第一次用 JSR223 写 Groovy 脚本时就是没注意到这个下拉框结果脚本里用了 Groovy 的 GString 和闭包语法BeanShell 解释器直接抛了一堆异常。后来排查半天才发现只是语言没切对。所以拿到 JSR223 组件的第一件事先把语言改成 Groovy养成肌肉记忆。2. 变量作用域脚本里那些“看起来能用”的数据到底怎么拿JSR223 脚本最让人头疼的不是语法而是上下文对象。很多人在脚本里写${变量名}或者直接用vars.get()但搞不清楚这些对象在什么阶段可用、数据到底存哪里了于是出现各种诡异的传参失败。2.1 vars、props、prev、ctx 分别干什么用我拿一个实际生活场景类比vars 就像是这个线程自己的笔记本每个线程各记各的互不干扰。props 是挂在公共黑板上的信息所有线程都能看到但要注意并发读写。ctx 是整个线程的完整上下文里面能拿到当前取样器、线程组、运行信息等等相当于一个“总控台”。prev 则是上一个或当前取样器的结果对象里面装着响应数据、响应码、耗时等信息。具体到每个 JSR223 组件里这些对象的可用性也不一样。JSR223 Sampler 里可以直接操作 SampleResult 对象JSR223 PostProcessor 里最常用的是 prev因为它拿到的是刚执行完的取样器结果JSR223 PreProcessor 里一般用 vars 和 sampler因为此时还没产生响应prev 指向的是上一个取样器的结果不是你当前这个请求的。2.2 脚本里别再随便写 ${name} 了我在这里吃了两次亏这是我认为整个 JSR223 使用中最隐蔽的坑${}在 JMeter 脚本里会被提前做变量替换。你在 Groovy 代码里写了一句return ${userId}本意是想拼一个字符串但 JMeter 在执行脚本之前已经扫描了这段脚本代码把${userId}替换成实际值。如果这个 JMeter 变量不存在它会原样保留随后 Groovy 又把${userId}当成 GString 插值再处理一次两套解析逻辑叠加结果完全不可控。我第二次遇到这个坑时调试了一个多小时才意识到问题脚本里有个 JSON 字符串模板{userId:${userId}}本意是用 JMeter 变量去替换但我在 Groovy 里又对它做了一次字符串拼接导致最终报文里出现了一层多余的转义字符。从那以后我的规矩是JSR223 脚本里一律不用${}方式取值全部改成vars.get(userId)或者直接传参。这样既能避免双重解析又能把脚本逻辑和 JMeter 的文本替换机制彻底隔离。2.3 前置处理器往变量里写数据后置处理器再读流程别搞反在压测场景里我经常需要用 PreProcessor 算出一个签名然后在后置处理器里根据请求结果再去更新这个签名。这里要特别注意的是PreProcessor 执行时请求还没有发出PostProcessor 执行时请求已经完成了。所以如果你的 PostProcessor 想读取 PreProcessor 里生成的数据完全没问题因为它们在同一个线程的同一轮迭代里通过 vars 存取即可。反过来就不行你想在 PreProcessor 里读取上一步请求的响应数据这里存在很大的不确定性。因为 PreProcessor 挂在当前请求上时prev 拿到的是“上一个取样器”的结果而不是当前这个请求的响应——当前请求压根还没发出去。所以如果你需要基于响应数据来生成签名正确的做法是把这个逻辑放在当前请求之前的某个取样器的 PostProcessor 里或放在该请求自己的 PostProcessor 里而不是挂在 PreProcessor 上。3. 缓存与性能为什么脚本越跑越慢越跑越卡如果你只写几个请求做调试JSR223 脚本的性能问题基本看不出来。但一旦放到压测场景里并发几百上千线程脚本里的每一行低效代码都会成倍放大。我在一次压测项目中就因为一个脚本里反复 new 了一个工具类导致老年代内存持续上涨最后触发频繁 Full GC压测结果惨不忍睹。3.1 编译缓存机制内嵌脚本和脚本文件的取舍JMeter 对 JSR223 脚本默认开启了编译缓存意思是同一份脚本内容编译一次后续线程直接复用编译结果。这是 Groovy 性能优于 BeanShell 的关键原因。但这里有个容易被忽略的点脚本内容一旦变化缓存就会失效并重新编译。如果你把脚本放在外部文件里每次修改文件后测试计划会自动加载新脚本但这会破坏编译缓存的效果因为 JMeter 每次都要重新读取和编译文件。内嵌脚本则相反——脚本代码直接写在组件里JMeter 能把它当作常量缓存起来运行时不会有文件 IO 和重复编译的开销。所以我的经验是生产压测环境尽量用内嵌脚本维护脚本时用一个独立的本地文件做版本管理压测前再同步进 JMX。分布式压测时尤其如此否则每台负载机上的脚本文件版本不一致压测结果没有任何参考价值。3.2 别在脚本里反复 new 对象这几个写法直接拉跨性能脚本在压测里是被反复执行的。如果你在脚本里每次执行都new一个大对象比如一个 JsonSlurper、一个 MessageDigest 实例甚至是一个线程池那这些对象的创建和销毁都会压在 JVM 的堆内存上。一个线程跑没问题五百个线程同时跑GC 压力立刻上来。更隐蔽的性能杀手是闭包。Groovy 的闭包用起来很爽但每次执行都会生成一个新的闭包对象。如果闭包里再捕获了外部变量这个对象会持有外部引用等于变相延长了变量的生命周期在长时间压测中极容易造成内存缓慢增长。我的做法是把频繁使用的工具方法写成静态方法放到 Groovy 脚本里直接调用如果一个脚本里需要多次解析 JSON就把 JsonSlurper 实例放到脚本的最外层作用域中复用而不是在方法内部反复创建。3.3 脚本缓存与线程安全并发下容易踩的第三个坑JSR223 脚本编译缓存是跨线程共享的这意味着多个线程会执行同一份编译后的脚本逻辑。如果你的脚本里有全局可变的静态变量或者引用了一个非线程安全的共享对象并发场景下就会出现数据覆盖和错乱。举个例子我在一个脚本里用了一个静态的 SimpleDateFormat 对象来格式化时间。单线程跑完全没问题压测时发现偶尔会出现解析异常就是因为 SimpleDateFormat 不是线程安全的多个线程同时调用它的 parse 方法导致内部状态错乱。后来我把时间格式化全部改成LocalDateTimeDateTimeFormatter问题立刻消失。所以在 JSR223 脚本里凡是能被多个线程同时访问的东西都要按线程安全的标准去设计能避免共享就避免共享。4. 报错与排查实录那些让人崩溃的“有效响应”和“假失败”JSR223 脚本排错是很多人最头疼的环节。最典型的两个现象一是接口明明返回了正确的数据但压测报告里却显示失败二是脚本里报了一个异常但取样器状态还是绿色通过。这两种情况我都经历过基本都和 SampleResult 的状态设置有关。4.1 脚本异常和取样器状态的关系JSR223 脚本如果执行抛出了未捕获异常JMeter 通常会把这次执行标记为失败并记录异常信息。但如果在脚本里自己捕获了异常又没有显式设置取样器状态那取样器可能仍然是成功的。这反而掩藏了接口真实的问题。更麻烦的是另一种情况接口返回了一个 JSON业务上明确表示“token 过期”但 HTTP 状态码是 200。如果你只用断言去检查 HTTP 状态码这个请求会被判为成功压测报告毫无意义。所以我后来统一在 PostProcessor 里做业务断言解析响应内容判断业务码如果不满足预期就主动调用prev.setSuccessful(false)并设置错误信息。4.2 手动控制 SampleResultsetSuccessful、setResponseMessage 的正确用法在 JSR223 PostProcessor 里prev指向当前取样器的 SampleResult 对象。你可以直接修改它。比如def response prev.getResponseDataAsString() def json new groovy.json.JsonSlurper().parseText(response) if (json.code ! 0) { prev.setSuccessful(false) prev.setResponseMessage(业务失败: ${json.msg}) prev.setResponseCode(500) }这段代码的意思是当接口返回的业务码不为 0 时强制把这次取样器标记为失败并附上错误信息。这样压测报告就能准确反映业务失败的情况而不是只看 HTTP 状态码。这里有个细节要注意setResponseCode()通常定义为字符串如果你传入的是数字类型部分 JMeter 版本会在结果树里显示异常。我习惯直接传入字符串比如500保证类型一致。4.3 常见报错速查表和排查思路我整理了自己在 JSR223 使用中遇到过的高频报错基本分成这么几类现象根本原因解决办法Script 执行报错提示No such property: vars for class net.sf.json.JSONObject脚本里引用了vars等对象但作用域写错比如在闭包里用了不正确的变量名检查变量名是否拼写正确确保在 JSR223 脚本的顶层使用报错Apparent variable xxx was declared in a scriptGroovy 中定义变量时用了def但后续引用时省略了类型声明作用域混乱统一使用def声明或直接用全限定名避免隐式变量冲突脚本返回结果不是期望的字符串多了一些[Ljava.lang.String;之类的信息脚本返回了数组或对象JMeter 将其 toString 输出在脚本末尾显式拼接字符串或使用SampleResult.setResponseData()压测时间一长JVM 内存持续上涨脚本中反复创建大对象、闭包、JsonSlurper 等把可复用对象提为静态变量减少不必要对象创建PreProcessor 里读不到当前请求的响应数据请求还没发出响应不存在prev指向的是上一个取样器把基于响应的处理改到 PostProcessor 中执行压测结果出现线程间数据串扰脚本使用了非线程安全的共享对象避免静态可变对象必要时加锁或使用线程安全类排查思路我总结为三步第一步打开 JMeter 安装目录下的 jmeter.log看有没有脚本异常堆栈第二步在脚本关键位置插入log.info()打印变量值确认逻辑走到哪一步第三步用单线程运行一次勾选“查看结果树”把脚本执行过程拆开看。4.4 log 别乱打压测时被日志刷爆也是故障这个坑其实很多人容易忽略。调试阶段为了看变量值我习惯在脚本里写一堆log.info()。压测脚本上线时忘了删结果压测现场 JMeter 控制台和 log 文件被刷爆负载机 CPU 都花在打日志上。我现在的做法是调试阶段用log.info()上线前全部改成log.debug()或者直接删掉。如果必须保留关键信息也只在异常分支里用log.warn()输出。压测时还应该把 JMeter 日志级别调成 ERROR避免正常执行过程中的中间日志刷屏。5. 完整实战一个加密登录接口的 JSR223 全过程前面讲了很多原理和坑下面用一个我实际做过的项目案例来串一遍一个登录接口请求体需要带时间戳和签名响应里返回 token 和用户信息。这个场景极其典型几乎每个做接口压测的人都会遇到。5.1 场景设计签名规则与整体脚本布局接口的签名规则如下把参数按照固定顺序拼接成字符串加上密钥计算 MD5再把结果小写输出。请求体是一个 JSON{ username: tester01, timestamp: 1718000000000, sign: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx }测试计划的结构是线程组 └─ HTTP 登录请求 ├─ JSR223 PreProcessor生成时间戳和签名 └─ JSR223 PostProcessor解析响应提取 tokenPreProcessor 负责在请求发出前把timestamp和sign写进 varsHTTP 请求的请求体里直接引用${timestamp}和${sign}。PostProcessor 负责拿响应里的 token存到 vars 里供后续请求使用。5.2 PreProcessor 完整脚本与逐行说明下面是我实际用到的一个版本去掉了业务敏感信息import java.security.MessageDigest // 生成时间戳单位毫秒 def timestamp System.currentTimeMillis().toString() // 拼接待签名字符串规则username timestamp secret def secret your-secret-key def raw tester01 timestamp secret // 计算 MD5 def md5 MessageDigest.getInstance(MD5) byte[] digest md5.digest(raw.getBytes(UTF-8)) def sb new StringBuilder() digest.each { b - sb.append(String.format(%02x, b)) } def sign sb.toString() // 写入变量供 HTTP 请求引用 vars.put(timestamp, timestamp) vars.put(sign, sign)这里有几个可以让脚本更健壮的细节System.currentTimeMillis()返回 long后面涉及到字符串拼接所以直接转成 String。MD5 计算完字节数组后需要把每个字节格式化为两位十六进制。注意负数字节的格式化要用%02x兜底否则会出现位数不够的情况。不要把 secret 硬编码到脚本里被压测机同步走的场景中。考虑到安全性可以把 secret 放到 props 中在启动脚本时统一注入。5.3 PostProcessor 完整脚本解析响应、提取 token、业务断言PreProcessor 负责“发出去之前”PostProcessor 负责“拿回来之后”。下面的脚本做三件事解析 JSON、提取 token、做业务断言如果业务失败则标记取样器失败。import groovy.json.JsonSlurper // 获取响应文本 def response prev.getResponseDataAsString() // 解析 JSON def json new JsonSlurper().parseText(response) // 业务断言code 为 0 表示成功 if (json.code ! 0) { prev.setSuccessful(false) prev.setResponseCode(500) prev.setResponseMessage(登录失败: ${json.msg}) log.warn(登录失败: ${json.msg}) } else { // 提取 token写入变量 vars.put(token, json.data.token) vars.put(userId, json.data.userId.toString()) }这段脚本的核心思路是不要把“响应是否成功”的判断交给 HTTP 状态码而是在业务层判断。接口返回 200 不代表业务成功只有 code 为 0 才算成功。用prev.setSuccessful(false)把失败采样标记出来压测报告自然就能反映真实结果。5.4 我在实际项目中总结的 JSR223 使用清单最后整理一份我现在写 JSR223 脚本时必过的检查清单照着做能避开大部分坑脚本语言统一选 Groovy不要用默认的 BeanShell。脚本中所有 JMeter 变量只通过vars.get()/vars.put()读写不直接写${}。不要重复创建 JsonSlurper、MessageDigest 等对象尽量复用。脚本不要跨线程共享非安全对象特别是 SimpleDateFormat。业务断言写在 PostProcessor 里显式设置成功/失败状态。压测前把log.info()改为log.debug()或删除。使用内嵌脚本而非外部文件分布式压测时保持一致。脚本执行异常时确保有日志输出不要吞异常。在修改 SampleResult 时保证响应码是字符串类型。如果一个脚本超过 50 行停下来想想能不能拆成更小的函数。我个人在后期项目中甚至会把签名算法、加密逻辑这类复用代码直接封装到一个 Groovy 类文件里通过 JSR223 的 init 阶段加载一次后续脚本只调用静态方法。这样做的好处非常明显脚本体积变小、可读性提高而且压测执行时不再需要反复解析同一段复杂逻辑。不过这种写法对脚本组织能力有一定要求建议先掌握本文的基础用法之后再去尝试。如果你最近正准备把测试计划里的 BeanShell 全部迁到 JSR223建议按上面的清单先改造一个接口跑一次压测对比一下 TPS 和响应时间。我当时的迁移结果是TPS 提升了接近 40%内存曲线也平稳了很多。踩过的坑不可怕把这些坑写下来变成自己的检查清单比你记住十个脚本示例都有用。