Clock MockClock 模拟时间流逝测试限时抢购逻辑【时间旅行】

先给出一个核心结论：MockClock 不能直接用来替换系统时间。原因很简单，System.currentTimeMillis() 是 JVM 底层通过 native 调用直接读取操作系统时钟的，像 Mockito 这样的普通 mock 框架根本拦不住它——毕竟它不是对象方法，而是静态 native 调用。强行用 PowerMock 这类工具去 mock 静态方法，不仅会破坏测试的隔离性，而且到了 JDK 9+ 环境，模块系统的限制很容易让它直接翻车。

MockClock 为什么不能直接替换系统时间

真正靠谱的做法是：把时间获取的逻辑抽离成一个可注入的依赖，然后用 MockClock 或 ManualClock 来替代。Spring Boot 2.6+ 默认就支持 Clock 的注入，但如果你手里的老项目里到处都是硬编码的 new Date() 或 Instant.now()，那就必须先动手改代码。 改起来需要遵循几个要点： - 所有时间相关操作——比如 Instant.now()、LocalDateTime.now()——都必须显式传入 Clock 实例，写成 Instant.now(clock) 这种形式。 - Spring 项目里，建议声明一个 @Bean @Primary Clock clock() { return Clock.systemUTC(); }，然后在测试时通过 @TestConfiguration 把它替换成 Clock.fixed(...) 或 MockClock。 - 记住一个坑：ja va.time.Clock 是不可变的，每次你想把时间“往前推”，都得新建一个实例，千万别想着去 mutate 原来的 Clock 对象。

MockClock vs ManualClock：选哪个做限时抢购测试

这里需要澄清一个常见误解。MockClock 并不是 JDK 自带的类，通常来自测试库（比如 io.github.resilience4j:resilience4j-test）或者你自己写的实现。至于 ManualClock，它是 org.mockito.internal.util.MockUtil 提供的，而且已经标记为弃用。实际项目里更常用的是 Clock.fixed(Instant, ZoneId) 或 Clock.offset(Clock, Duration)。 限时抢购的核心验证目标就是：时间窗口内允许下单，超时瞬间必须拒绝。重点不在于模拟时间的“流逝过程”，而在于精确控制“当前时刻”的值。所以： - 用 Clock.fixed(Instant.parse(“2024-01-01T10:00:00Z”)) 来测试边界点——比如开抢瞬间、截止前 1 毫秒、过期后 1 毫秒——这种方式最可靠。 - 如果需要连续推进时间，比如模拟用户从进页面到下单花了 800 毫秒，那用 Clock.offset(baseClock, Duration.ofMillis(800)) 更轻量，不用一次次 new 新的 Clock。 - 那些第三方提供的 MockClock 类，除非它明确支持线程安全的 setInstant() 操作，否则尽量避开。因为多线程并发抢购测试里，时间跳变必须全局可见且原子，不然会出大问题。

测试中 Clock 注入失败的典型现象

这类错误往往不会直接报编译异常，而是测试通过了但业务逻辑根本没跑对。最常见的两个表现：抢购接口始终返回“活动未开始”，或者超时后仍然能下单成功。根本原因通常只有一个——Clock 没生效，实际跑的仍然是系统时钟。 排查的时候可以按这个顺序来： - 检查被测类是不是真的接收了 Clock 参数（构造器注入、setter 注入、方法参数都算），而不是在内部偷偷写了 Instant.now()。 - 确认测试上下文里 @Autowired Clock clock 拿到的确实是你配置的 mock 实例，而不是默认的 Clock.systemDefaultZone()。加个断点或者打印一行 System.out.println(clock.toString()) 就能看出来。 - 在 Spring Boot WebMvcTest 场景下，@MockBean Clock 可能不会生效，因为 Controller 层依赖的 Service 用的是一个不同 Bean Scope 的 Clock。这时候优先用 @Import(TestClockConfig.class) 来显式覆盖。 - 别忘了 LocalDateTime.now() 和 Instant.now() 的默认版本依赖的是系统时钟，必须显式传参，写成 LocalDateTime.now(clock) 和 Instant.now(clock)。

并发抢购测试里时间推进的陷阱

单线程环境下推进时间很简单，但真实抢购场景是多个线程同时争抢库存。如果每个线程各用各的 Clock 实例，那就失去了“全局一致当前时间”的意义——A 线程看到 10:00:00.000，B 线程看到 10:00:00.001，这种差异会导致预期外的并发行为。 正确的做法是让所有线程共享同一个 Clock 实例，并且确保它们都基于这个实例来获取时间： - 用 Clock.fixed(...) 时，所有线程自然共享同一个固定时刻，最适合测试“瞬时状态”下的并发逻辑。 - 用 Clock.offset(...) 来模拟耗时操作时，必须保证 offset 是相对于同一个 base clock 计算的，而且 base clock 不能是 ticking 类型的，必须是 fixed 或 system。 - 绝对不要在 Runnable 或 Callable 里面 new Clock，尤其要避免 Clock.systemUTC() —— 这相当于一秒切回真实时间，之前做的所有 mock 工作全部失效。 - 如果业务代码里用了 ScheduledExecutorService 来做倒计时推送，那得用 new ScheduledThreadPoolExecutor(1, r -> {...}) 并手动控制触发时机，否则这个线程池不认你的 Clock。 说到底，限时逻辑的脆弱点从来不在算法本身，而是在于时间源是否真正可控。哪怕只有一个地方漏掉了 new Date()，整个时间旅行计划就会立刻脱轨。