必须验证三类运行时行为差异——类加载路径、商业特性依赖、JVM参数兼容性；否则90%概率生产环境凌晨三点告警，需重点检查sun.*类调用、JAXB移除、JFR参数兼容性及vendor硬编码逻辑。
直接结论：必须验证三类运行时行为差异——类加载路径、商业特性依赖、JVM参数兼容性。不验证就切，90%概率在生产环境凌晨三点收到告警。
检查是否调用了 Oracle 专有 API 或 sun.* 类
很多老项目隐式依赖 sun.misc.Unsafe、sun.nio.ch.DirectBuffer 或 Oracle 特有的 com.sun.crypto.provider 实现。OpenJDK 8 起默认限制这些类的反射访问，运行时抛 IllegalAccessException 或 NoClassDefFoundError。
实操建议：
- 启动时加参数：
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=vm.log，观察日志中是否有sun.*加载失败记录 - 用
jdeps --jdk-internals your-app.jar扫描依赖（JDK 9+），输出含sun.*的行必须人工确认是否可替换 - 若用到了
javax.xml.bind（JAXB），注意 JDK 11+ 已移除，需显式添加jakarta.xml.bind-api和org.glassfish.jaxb.runtime依赖
确认 Java Flight Recorder 和 JMC 是否被启用
-XX:+FlightRecorder、-XX:+UnlockCommercialFeatures 这类参数在 OpenJDK 8 和部分早期 OpenJDK 11 构建中会直接导致 JVM 启动失败，报错：Error occurred during initialization of VM — Could not start JFR。
实操建议：
- 搜索全部配置文件（
application.properties、startup.sh、CI/CD 脚本），删掉所有含UnlockCommercialFeatures的 JVM 参数 - 若监控强依赖 JFR，改用 Temurin 或 Corretto 发行版（它们从 JDK 11 起已内置开源 JFR）
- 检查 Spring Boot Actuator 的
/actuator/jfr端点是否启用——它底层会尝试调用 JFR，OpenJDK 8 下该端点会 500
验证系统属性和 vendor 相关逻辑
有些代码会根据 java.vendor 或 java.vm.name 做分支判断，例如：
if (System.getProperty("java.vendor").contains("Oracle")) {
useOracleSpecificCipher();
}
这类逻辑在 OpenJDK 下直接跳过，可能引发加密失败或连接超时。
实操建议：
- 全局 grep
java\.vendor、java\.vm\.name、System\.getProperty，逐个检查分支逻辑是否安全 - 运行
java -XshowSettings:properties -version 2>&1 | grep -E "(vendor|vm.name)"，确认实际值（OpenJDK 输出java.vendor = "N/A"或发行商名如"Eclipse Foundation"） - 避免硬编码判断，改用功能探测：比如用
Security.getProviders()查是否有特定 Provider，而不是看 vendor 字符串
最容易被忽略的是：某些国产中间件（如东方通 TONGWEB、金蝶 Apusic）的启动脚本里，会用 java -version 输出字符串匹配 "Oracle" 来决定是否启用某模块。这种脚本不改，换完 JDK 就挂——得去 bin/ 目录下翻 shell 脚本。
