面经策

从 Java 8 升级到 21，常见的兼容性坑有哪些？（javax→jakarta、内部 API 封装、默认 GC 变化） ​

  • 标签：Java、新特性

🏛 业务架构师 ​

Java 8 → 21 升级的常见兼容性坑与应对（2026 年实战清单）：

  1. javax → jakarta 命名空间：Spring Boot 3 强制 jakarta.*（Servlet/Validation/Persistence）——所有相关 import、传递依赖（老版本 Hibernate Validator、Swagger 2）必须升级。这是最大工程量所在：先升级依赖树（mvn dependency:tree 扫描 javax 引用），逐个找 jakarta 兼容版本；Swagger 2→SpringDoc 这类要换库；
  2. JDK 内部 API 强封装（JDK 16~17 起）：sun.misc.Unsafe、sun.nio.* 等内部 API 默认禁止反射访问——老框架（旧版 Netty、Kryo、某些连接池、APM Agent）运行时报 InaccessibleObjectException。对策：先升依赖到兼容版本（正道）；应急用 --add-opens java.base/... 打开模块（过渡手段，要记技术债）；
  3. 默认 GC 变化：8 的 Parallel GC → 21 默认 G1——停顿模式改变，个别对吞吐敏感的批处理可能"变慢"。对策：升级后压测对比，必要时显式 -XX:+UseParallelGC（批处理）或顺势调优 G1；
  4. 移除的 API：Nashorn JS 引擎（15 移除——老规则引擎脚本要迁 GraalJS）、CORBA/EE 模块（11 移除）、SecurityManager 弃用——逐项排查 usage；
  5. 字节码与 Agent 兼容：Lombok、ASM-based 工具（动态代理、热部署 Agent）需升级到支持新版 class file 的版本；
  6. 三方中间件客户端：老版本 Kafka/Redis 客户端可能用内部 API——全部升到近两年版本。

我的升级方法论：一次目标到位（别逐版本爬）→ 依赖先行（先升齐依赖再动 JDK）→ 自动化回归测试兜底 → 灰度引流对比（性能与错误率双看板）。商业账：企业级应用典型改造 2~6 人周，换来虚拟线程吞吐、GC 与内存优化、安全补丁、框架生态续命——2026 年这笔账几乎笔笔划算，拖得越久利息越高。

🏗 系统架构师 ​

Java 8 → 21 升级的兼容性坑，我按"坑类型 × 修复策略"给实战清单：

  • javax → jakarta 命名空间（最大工程量）：Jakarta EE 9 起整体迁移（javax.servlet/persistence/validation → jakarta.*）——Spring Boot 3 的硬门槛。修复：全量改 import（机械重构）+ 依赖树排查（旧 javax.annotation-api 混入会编译通过运行失败——用 maven-enforcer 统一）；GAV 版本对齐（Spring 6 / Hibernate 6 / Tomcat 10+）；
  • 内部 API 封装（JDK 9 模块化遗留）：sun.misc.Unsafe、sun.nio.* 等内部类被强封装（JDK 16+ 默认拒绝反射访问）——老 ORM/序列化/字节码库（旧版 Jackson、Kryo、 cglib）运行时报 InaccessibleObjectException。修复：升级依赖到支持新 JDK 的版本（首选）；临时 --add-opens 白名单（记录技术债，逐步消除）；
  • 默认 GC 变化：8 的 Parallel → 9+ 默认 G1——吞吐型服务的 GC 行为突变（老调优参数失效：-XX:+UseParNewGC 直接拒启）。修复：先显式指定旧 GC 平滑迁移，再评估切 G1/ZGC；8 的 CMS 已移除（JDK 14），CMS 参数必须清理；
  • 其他高频坑：
    • 移除的 API：Thread.stop、SecurityManager 弃用路径、Nashorn（JS 引擎，JDK 15 移除）→ 迁 GraalJS/独立引擎；
    • 字体/图像：headless 服务器的 AWT 依赖（Cglib/验证码库）→ 依赖 fontconfig 的容器镜像补齐；
    • TLS/加密：默认禁用老算法（TLS1.0/1.1、弱密钥）——对接老系统的兼容测试；
    • 字符编码：JDK 18 起默认 UTF-8（file.encoding）——Windows 开发环境与生产的读写行为差异；
    • 日志框架：JDK 9 后 JUL 桥接变化 + 老版本 Log4j1 无 JDK17 支持 → 统一升级。

升级策略（架构师打法）：先升依赖后升 JDK（框架先到支持位）；jdeps 扫描内部 API 依赖；每跳 LTS 全量回归（CI 矩阵 8/17/21 并行跑一段时间）；灰度切流观察 GC/延迟/内存基线。

💻 全栈开发专家 ​

从 Java 8 升 21 的兼容性坑，我按「最容易炸」排序（带队迁移过两个百万行级工程）：

1. javax → jakarta（最大面积）： JDK 本身没这事，是 Spring Boot 3 强制：javax.servlet/persistence/validation 全迁 jakarta.*。IDE 一键迁移能覆盖 90%，剩下的是传递依赖——老版本第三方库内部 import javax 的（老 swagger、老 commons-fileupload、老 hibernate-validator）必须升级，mvn dependency:tree | grep javax 逐一排雷。

2. 内部 API 强封装（JDK 16/17 锁死）： sun.misc.Unsafe、sun.nio.* 等 reflective access 从「警告」变「拒绝」。典型受害者：老 Netty、老 cglib、反射工具（老 Spring 在高版本 JDK 生成的 cglib 代理）、APM agent。对策：升级库版本（生态基本都发了适配版）；应急 -–add-opens java.base/...（仅过渡，写进启动脚本时标注 TODO）。

3. 默认 GC 变化： 8 的 Parallel（吞吐优先，停顿大）→ 9+ G1（停顿可控）。表现：老应用升 21 后「吞吐略降、CPU 略升」很常见——不是变慢了，是 GC 目标变了。批处理/离线任务想保吞吐：-XX:+UseParallelGC；通用服务保持 G1 并重新压测 GC 参数（8 时代的 CMS 参数全部失效清理，别带病迁移）。

4. 其他高频项：

  • 移除的 API：SecurityManager（17 弃用/24 移除）、Thread.stop、Nashorn JS 引擎（15 移除——有内嵌 JS 脚本的换 GraalJS）；
  • 默认字符集：JDK 18 起 file.encoding=UTF-8——Windows 下读写本地文件的老代码乱码（显式传 charset）；
  • 强封装 JAR（9 的 multi-release 变化）与 --illegal-access 默认拒绝；
  • Lombok/MapStruct 注解处理器版本升级（老版本在新 javac 上直接编译失败）；
  • String.format/国际化行为微调（CLDR 数据，Locale 相关输出变化——对账系统重点回归）。

迁移节奏实战：先 8→17 跑稳（Spring Boot 3 门槛），再 17→21 开虚拟线程（成本几乎为零、收益后置）——两步走风险最小。