关键在于识别“看似只读、实则写入”的行为路径并确认全局变量是否被多线程非原子地读-改-写，常见于MeterSphere后置脚本等场景，根因是状态意外共享。
排查断言接口中隐式改动全局变量引发的并发计算错乱，关键在于识别“看似只读、实则写入”的行为路径，并确认该变量是否被多个线程非原子地读-改-写。这类问题在 metersphere 后置脚本、postman 测试集或自研测试框架中高频出现，表面是计算结果不准，根因往往是状态意外共享。
锁定可疑的全局变量
先聚焦那些容易被误用为“临时存储”的全局可变对象：
- 脚本级定义的计数器（如 counter = 0）、列表（results = []）、缓存映射（cache = {}）
- 被多次复用的单例工具实例（如 formatter = new SimpleDateFormat(...)、jsonParser = new JsonParser()），它们内部状态可能在并发调用中被污染
- 通过 vars.put("key", value) 注入的全局变量，在多线程执行时若未加锁或隔离，会相互覆盖
验证是否发生跨线程写入
不能只看变量声明位置，要追踪实际执行流：
- 在断言代码中搜索 =、+=、.add()、.put()、.setXXX() 等写操作，确认它们是否出现在并行触发的接口回调里
- 检查测试计划是否启用了“并发执行”或“多线程调度”，例如 MeterSphere 的“场景并发数＞1”或 JMeter 的 ThreadGroup 设置
- 用日志打点：在每次写操作前后输出 [threadName] before: val=xxx → after: val=yyy，运行 20+ 次观察值是否跳变或重复
区分隐式修改与显式意图
很多错乱源于“以为只是读，其实触发了副作用”：
- 调用 list.contains(x) 后紧接着 list.add(x) —— 这个组合不是原子操作，两个线程可能同时通过 contains 判断，再一起 add，造成重复
- 使用非线程安全的格式化器（如 SimpleDateFormat.parse()）—— 内部字段被并发修改，导致解析出错或抛异常
- 对全局 map 执行 map.get(k) == null ? map.put(k, v) : map.get(k) —— 读-判-写三步分离，竞态窗口明显
快速验证与修复方向
不需重写整个逻辑，优先做最小干预：
- 把脚本级变量改为函数内局部变量（如把 counter 移到断言函数体开头），切断跨线程共享
- 将 SimpleDateFormat 替换为 DateTimeFormatter（Java 8+ 不可变）或封装进 ThreadLocal
- 用原子容器替代普通集合：如 ConcurrentHashMap 替代 HashMap，AtomicInteger 替代 int counter
- 对必须共享的状态，加同步块或使用 synchronized(map) 包裹临界区（仅限低并发、简单场景）
