从 8 / 11 迁移到 17

先确认版本坐标01

JDK 17 是 LTS，class 文件版本 61，默认 G1。升级前先把源码、编译工具、运行时和依赖的版本对齐；class 文件版本不匹配通常表现为启动即失败。

$ java -version
openjdk version "17.0.13" 2024-10-15 LTS
OpenJDK Runtime Environment Corretto-17.0.13.11.1 (build 17.0.13+11-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.13.11.1 (build 17.0.13+11-LTS, mixed mode, sharing)

用 --release 17 编译，而不是只改 -source / -target。--release 会同时约束语法、字节码版本和可用的标准库 API 快照，避免编译到 18+ 才有的 API。

移除与弃用：先分清「现在就不能用」和「以后不能用」02

RMI Activation 的移除只影响 java.rmi.activation 和 rmid，普通 RMI（java.rmi）仍在。升级时先用 jdeps / 编译错误找出引用，再删启动脚本里的 rmid。

$ java --list-modules | grep rmi
java.management.rmi@17.0.13
java.rmi@17.0.13
jdk.naming.rmi@17.0.13

$ ls $JAVA_HOME/bin | grep rmid
# 无输出：rmid 已随 JEP 407 移除

强封装与反射：先升级库，再加参数03

JDK 16 的 JEP 396 把默认策略改为拒绝，但仍可用 --illegal-access=permit 放行；JDK 17 的 JEP 403 移除了这个开关，JDK 内部包从此一律强封装。

import java.lang.reflect.Field;

Field f = String.class.getDeclaredField("value");
f.setAccessible(true);

type=InaccessibleObjectException
msg=Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module @...

报错要这样读：被访问的成员在 java.base 模块的 java.lang 包里；该包没有向调用方模块 opens。classpath 上的代码属于未命名模块，所以目标通常写 ALL-UNNAMED。

# 临时放行：把 java.base/java.lang 打开给 classpath 代码
java --add-opens java.base/java.lang=ALL-UNNAMED -cp out ReflectDemo
# opened=true

# 17 上这个选项只会被忽略
$ java --illegal-access=permit -cp out ReflectDemo
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0
type=InaccessibleObjectException
msg=Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module @...

• --add-opens 是运行时参数，只影响反射的深度访问，不改变编译期可见性。
• --add-exports 影响编译期与运行期的静态访问：让未导出的 public 类型可见。
• 每加一个参数都要记录原因、作用模块和移除计划；它们会掩盖真正的升级问题。
• sun.misc.Unsafe 等少数内部 API 仍通过 jdk.unsupported 导出，但这是兼容通道，不是鼓励使用。

工具与参数：把问题在启动前找出来04

jdeps 找静态引用 JDK 内部 API 的类，jdeprscan 找使用了已弃用 / 待移除 API 的类；两者互补，都不能发现纯反射访问。

# 找出依赖 JDK 内部 API 的类
jdeps --jdk-internals -R build/libs/app.jar

# 找出使用了「已弃用 / 将被删除」API 的类
jdeprscan --release 17 --for-removal build/libs/app.jar

# 编译时把 removal 警告暴露出来
javac --release 17 -Xlint:removal -d out $(find src -name "*.java")

$ jdeps -J-Duser.language=en --jdk-internals out/ExportDemo.class
ExportDemo.class -> java.base
   ExportDemo -> sun.nio.ch.DirectBuffer   JDK internal API (java.base)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.

# 确认最终生效的 GC 与暂停目标
java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|MaxGCPauseMillis"
#   uintx MaxGCPauseMillis = 200  {product} {default}
#    bool UseG1GC          = true {product} {ergonomic}

升级检查清单05

1. 把本地、CI、容器、构建插件统一到 JDK 17，确认 class 文件版本为 61。
2. 用 --release 17 编译，并开启 -Xlint:removal；先让所有 removal 警告可见。
3. 跑 jdeps --jdk-internals -R 与 jdeprscan --release 17 --for-removal，列出内部 API 与待移除 API。
4. 清理 JVM 参数：CMS、MaxPermSize、--illegal-access；确认 UseBiasedLocking 只是警告而非硬失败。
5. 处理强封装：升级依赖，替换 sun.* / jdk.internal.*；确需兼容时才加最小范围 --add-opens。
6. 确认 Security Manager 用法：17 仍可运行但有警告，计划在升级到 18+ 前移除。
7. 检查 RMI Activation、Applet、AOT 等移除 / 弃用项，删除对应代码与启动脚本。
8. 跑完整测试与压测，观察 GC 日志、启动时间、反射错误和依赖加载。

迁移完成的标准不是「能启动」，而是「启动参数干净、没有依赖 JDK 内部 API、测试与压测通过、回滚路径明确」。

版本边界BOUNDARY

这张表比 API 本身更值得记。写代码时先确认你的运行时版本。

费曼自检SELF CHECK

先合上页面，用自己的话回答，再展开对照。能讲出因果和反例，才算真正掌握。