并发线程实际运行用户数超出配置定义值问题咨询

该异常是Concurrency Thread Group（JMeter并发线程组插件）的配置认知偏差、默认调度机制、监听器统计口径错配共同导致的，具体触发逻辑如下：

• 参数认知偏差：你当前配置的Ramp up step=4指爬升阶段总共分4个批次完成总并发量加载，结合总并发12、爬升时间120秒的配置计算，每批次间隔30秒、每批新增3个线程，和你预期的3个一组分配规则完全匹配，这部分基础配置本身没有错误。
• 默认调度机制生成冗余线程：Concurrency Thread Group默认开启Allow excess threads开关，设计初衷是避免线程阻塞、接口响应超时导致实际并发达不到配置值，调度器会临时创建最多为目标并发值1.5~2倍的临时线程补位。如果单线程单次业务迭代的耗时超过30秒的批次间隔，前序线程还在执行任务时新批次线程已经启动，加上临时补位的线程不会立刻销毁，就会观测到17、21个存活线程。这部分临时线程不会长期占用并发配额，调度稳定后会自动回收，但会导致线程数观测值虚高。
  注意不要把JVM中存活的线程总数等同于实际运行业务的活跃用户数，两者统计口径完全不同
• 监听器统计口径偏差：旧版本的线程数统计监听器，会把处于初始化、等待调度、连接销毁状态的非活跃线程全部计入“运行用户数”，统计值比实际执行业务请求的活跃线程数高30%~70%属于常见现象。

• 调整线程组核心调度配置：打开Concurrency Thread Group高级设置栏，取消勾选Allow excess threads选项，将Max held threads参数值设为12（和配置的总并发数一致），从调度逻辑上禁止额外临时线程创建。
• 修正监听器统计口径：升级JMeter插件管理器至最新版本，使用最新版Active Threads Over Time监听器，统计时选择Active Threads (executing samples)指标，该指标仅统计正在执行业务采样请求的线程，会自动过滤非活跃状态的无效线程，统计结果和实际业务运行用户数完全匹配。
• 验证爬升逻辑：测试计划中添加Debug Sampler，先跑10分钟小流量验证，确认每30秒新增3个活跃业务线程，最终稳定运行的业务线程数维持在12，无超额情况后再开展全量压测。
• 排除统计干扰：如果测试计划下挂载了多个线程组，统计时注意过滤其他线程组的线程数据，避免将其他组的线程计入当前并发组的运行用户数。

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