Maven运行含Thread.sleep/wait的JUnit5测试类最后一个用例随机失败原因

核心原因 #

1. 固定时长等待的调度抖动 #

Thread.sleep(2 * retryPeriod)只能保证线程至少休眠指定时长，受操作系统进程调度、JVM GC停顿、运行环境CPU负载影响，极端情况下会出现实际休眠时间刚达到甚至略小于retryPeriod的情况。此时熔断器的evaluateState方法中判断条件为(System.currentTimeMillis() - lastFailureTime) > retryPeriod，严格大于的判断逻辑会导致临界值时熔断器仍然停留在OPEN状态，调用直接返回失败，触发断言错误。

2. 变量可见性问题 #

熔断器中的state、failureCount、lastFailureTime等可变成员变量没有添加volatile修饰，JIT编译优化时可能会将变量值缓存到CPU寄存器，导致运行时读取到的是过期值，状态判断逻辑出错。

3. Maven测试环境的并行执行干扰 #

IntelliJ默认单线程顺序执行测试用例，而Maven Surefire插件如果配置了parallel=methods（很多项目会默认开启提升测试效率），同一个测试类的多个测试方法会并行执行。如果你的client、response等Mock对象是类级别的成员变量，不同测试方法修改Mock返回值的行为会互相干扰，最后执行的测试用例拿到的Mock返回值可能不符合预期。

修复方案 #

• 修改熔断器evaluateState方法的判断条件，将> retryPeriod改为>= retryPeriod，避免临界值判断错误
• 给熔断器的所有可变成员变量添加volatile修饰，保证多线程环境下的变量可见性：

  private volatile State state;
  private volatile int failureCount;
  private volatile long lastFailureTime;
  private volatile String lastFailureMessage;
  

• 替换固定时长Thread.sleep为轮询等待逻辑，避免调度抖动影响：

  // 替换原有的Thread.sleep逻辑
  long waitStartTime = System.currentTimeMillis();
  long maxWaitTime = 3 * retryPeriod;
  // 轮询直到等待时长达标
  while (System.currentTimeMillis() - waitStartTime < maxWaitTime) {
      Thread.sleep(100);
  }
  

• 调整Mock对象的作用域为测试方法级别，每次测试执行前通过@BeforeEach重新初始化Mock和熔断器实例，避免测试用例之间的行为干扰。

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