JMeter执行脚本遇java.lang.RuntimeException：循环迭代API未执行

这种现象绝非Parallel控制器的正常行为，Parallel控制器完全支持线程组的循环迭代逻辑，第二次循环未执行且抛出java.lang.RuntimeException，本质是脚本配置或并行执行逻辑存在问题，而Transaction Controller未出现异常是因为它是串行聚合请求，不会暴露并行场景下的线程安全、依赖冲突等问题。

以下是具体排查方向：

• CSV参数化配置问题：检查CSV Data Set Config的共享模式与文件内容：
  • 如果共享模式设为"所有线程"，需确保CSV文件至少有2行参数（匹配循环次数）；若行数不足，第一次循环读取后第二次会抛出读取异常，中断线程。
  • 若共享模式设为"当前线程"，确认是否勾选了循环读取选项，避免文件读完后停止输出参数。
• Parallel控制器内部请求的依赖冲突：Parallel控制器会并行启动子线程执行内部请求，如果请求之间存在变量依赖（比如A请求的响应变量被B请求引用，但并行执行时A还未完成，B就去读取变量），会直接抛出RuntimeException，导致整个线程的后续循环终止。而Transaction Controller是串行执行，依赖关系能按顺序满足，因此不会触发异常。
• 异常堆栈定位具体问题：不要忽略java.lang.RuntimeException的堆栈信息，查看日志中异常的具体触发点（比如是CSV读取失败、变量引用为空，还是HTTP请求本身的错误），这是定位问题的核心依据。
• JMeter版本兼容性：部分旧版JMeter的Parallel控制器存在循环迭代的bug，建议升级到5.6.x及以上的稳定版本重试。

验证建议：

• 简化脚本：暂时移除Parallel控制器，改为串行执行，确认循环2次是否正常。若正常，说明问题出在并行执行逻辑上。
• 添加Debug Sampler：在Parallel控制器内部和线程组根节点添加Debug Sampler，查看每次循环的变量值、参数读取情况，定位参数传递或读取的异常点。
• 单独测试并行请求：将Parallel控制器内的请求单独提取出来，验证每个请求在并行场景下能否独立获取参数并正常执行。

内容的提问来源于stack exchange，提问作者Tushar Chaudhary