openjdk升级后junit测试失败通常暴露原有代码缺陷而非jdk不兼容；需按nullpointerexception、类加载失败、断言逻辑错误、偶发失败四类排查，重点检查tostring链式调用、模块反射限制、数组/集合比较方式及时间/状态隔离。
OpenJDK 升级后 JUnit 测试失败，不能直接归因于“JDK 不兼容”，绝大多数情况是旧代码/配置在新 JVM 行为下暴露了隐藏问题。先分类，再动手改。
看错误栈顶是不是 NullPointerException 且指向 toString
这是 JDK 升级后最典型的“假失败”信号。JDK 17+ 的 NPE 提示更具体（比如 "Cannot invoke 'String.length()' because 'xxx' is null"），但根源往往不在 toString 本身——它只是第一个触碰 null 的地方。Lombok 生成的 toString 不会因为字段为 null 就抛 NPE，除非你手动重写了它，或用了 @ToString(of = {...}) 指向了某个可能为 null 的字段并调用了其方法（如 status.getName()）。
- 检查被测对象中所有参与
toString输出的字段，尤其是那些带 getter 链式调用的（user.getAddress().getCity()） - 确认这些字段是否在测试 setup 阶段被正确初始化；Mockito 的
@Mock默认返回 null，不是空对象 - 临时把
toString调用从日志、断言消息、异常构造中移除，看测试是否通过——如果通过，就坐实是打印链路暴露了空值
运行时类加载失败：检查 NoClassDefFoundError 或 ClassNotFoundException
JDK 升级常伴随模块系统收紧（JEP 261）、默认禁用反射（JEP 396）、以及 sun.* / com.sun.* 包的彻底封禁。JUnit 测试若依赖老版反射工具（如某些 Mock 框架早期版本）、或手动加载字节码（ASM/CGLIB），容易在此处崩。
- 错误如
java.lang.NoClassDefFoundError: org/junit/jupiter/api/Extension，优先查 Maven 依赖树：mvn dependency:tree -Dincludes=org.junit.jupiter，确认junit-jupiter和junit-platform-launcher版本匹配（JDK 17+ 推荐 junit-jupiter 5.10+） - IDEA 中测试图标灰显或报 “No tests found”，检查
@Test是否来自org.junit.jupiter.api.Test，而非org.junit.Test（混用会触发 Vintage 引擎，但依赖缺失时直接静默失败） - 若用 Mockito，升级到 5.x（支持 JDK 17+ 模块系统），避免
mockito-inline在 JDK 17+ 上因--illegal-access=deny失效
断言失败但内容一致？重点查数组和集合比较
JDK 升级不会改变 Arrays.equals() 行为，但会影响测试断言的“可读性”和“默认比较逻辑”。常见现象是 assertEquals(array1, array2) 报错，提示 expected: [I@xxx，实际两个数组内容完全一样。
- 这是因为
assertEquals对数组做的是引用比较，不是内容比较；JDK 升级前后都如此，只是升级后你更可能在 CI 环境跑出这个错（本地 IDE 可能用了不同断言策略） - 必须改用
assertArrayEquals(array1, array2)，它内部调用Arrays.equals做逐元素比对 - 同理，对
List或自定义对象集合，别用assertEquals(list1, list2)依赖equals实现——确保该实现已正确定义；否则用assertIterableEquals（JUnit 5.6+）或Assertions.assertThat(list1).containsExactlyElementsOf(list2)（AssertJ）
偶发失败（Flaky Test）突然变多？检查时间/随机/并发敏感点
JDK 升级后线程调度、GC 行为、SecureRandom 实现（如从 SHA1PRNG 切到 DRBG）、甚至 System.nanoTime() 精度都可能变化，导致原本“刚好不翻车”的测试开始飘红。
- 超时类失败（如
@Timeout触发）：不要盲目加 timeout 值，先用-XX:+PrintGCDetails看 GC 是否变慢，或用jstack抓线程卡点 - 依赖当前时间的测试（如
LocalDateTime.now()）：一律用Clock.fixed(...)注入，禁止裸调系统时钟 - 测试间共享资源（临时文件、静态 Map、单例状态）：JDK 升级后类加载器行为微调，可能让“之前没冲突”的测试现在冲突，加
@TestInstance(TestInstance.Lifecycle.PER_METHOD)强制隔离
真正棘手的不是 JDK 升级本身，而是它像一面镜子，照出测试里长期被忽略的脆弱假设：null 检查缺失、时间依赖未隔离、数组比较写错、Mock 行为未声明。升级不是问题，是提醒你该修了。
