Java 大版本升级首先是兼容性工程。编译成功只能证明当前源码可被新编译器接受，线上还会遇到字节码版本、反射访问、代理库、容器镜像和垃圾回收参数等问题。升级计划要把这些风险拆成可回滚的验证项。
先画出真实运行边界
盘点本地开发机、构建节点、测试环境和生产容器各自使用的 JDK。确认启动脚本里的 JAVA_HOME、基础镜像标签和服务管理配置没有指向旧版本。一个服务的不同组件若混用运行时，问题通常会在发布后才出现。
还要列出框架、字节码增强、监控探针和 JNI 库。它们比业务代码更容易依赖内部 API 或特定字节码行为。
编译阶段应检查什么
使用目标 JDK 重新编译所有模块，并开启过时 API 与非法访问相关警告。依赖树中如果有停止维护的库，先确认其运行范围。不要为了压住警告直接打开宽泛的模块导出，这会把短期兼容变成长债。
多模块项目要让测试和打包也跑在新 JDK 上。只替换 IDE 的 JDK 不会覆盖 CI 与发布产物。
运行测试怎样安排
- 先跑单元和集成测试，覆盖序列化、反射和数据库连接。
- 用接近生产的容器启动服务，执行登录、消息、定时任务等关键路径。
- 做一段稳定性运行，观察内存、线程、文件句柄和异常日志。
- 在灰度环境比较延迟、吞吐和错误率，并保留旧镜像回退入口。
性能数据必须使用相同负载和配置比较。升级后默认垃圾回收器或容器内存识别方式变化，单次压测很容易得出错误结论。
参数迁移要特别谨慎
旧的 JVM 参数可能已废弃、改名或失去效果。启动时的警告应进入发布门禁。对内存、编码、TLS 和诊断参数逐项确认，不要把一整份历史配置原样搬过去。
如何处理失败
先区分编译错误、启动错误和业务路径错误。前两类通常能快速定位到 API 或依赖，业务路径错误则需要可复现请求和日志上下文。每修一类问题就补回归用例，避免下次升级重新踩到。
常见问题
能跳过中间版本吗
可以，但要把迁移说明按跨越的版本逐项检查，风险不会因为一次跳过而消失。
测试全绿就能全量发布吗
仍应灰度。外部流量、真实数据规模和宿主机限制常不在测试集里。