Java 17 现代基线：从 JDK 8 升级到 17 的原理与实践
Java 8 仍是维护企业存量系统必须掌握的基线，Java 17 则是现代 Spring Boot 3 应用的最低运行基线。本章不把 Java 17 简化成“多了 Record”，而是回答四件事：语言怎样变化、JVM 怎样变化、旧程序为什么可能失效、生产系统怎样安全升级。
一、学习目标
学完后应能：
- 区分源码级别、字节码版本、编译 JDK 和运行 JDK。
- 说清 Java 9 到 17 中对业务开发真正重要的变化。
- 正确使用 Record、密封类、文本块、Switch 表达式和模式匹配。
- 解释 JPMS 强封装为什么会让旧反射代码失败。
- 区分 Java 8 与 17 的默认 GC、容器感知、内存参数和诊断差异。
- 完成一条可回滚的 JDK 8 到 17 升级链路。
二、先建立正确的版本模型
| 名称 | 决定什么 | 典型证据 |
|---|---|---|
| 编译 JDK | 哪个 javac 和构建插件被执行 | mvn -v、javac -version |
--release | 目标 class 版本以及可使用的标准库 API | Maven Compiler Plugin 配置 |
| class major version | 运行 JVM 能否识别 class | Java 8 为 52，Java 17 为 61 |
| 运行 JDK | 生产环境真正执行 Jar 的 JVM | java -version、进程命令行 |
| 框架基线 | 框架最低要求的 Java 版本 | Spring Boot 3 最低 Java 17 |
只配置 source=8,target=8 并不等价于 --release 8：前者主要限制语法和输出字节码，若编译器本身是 17，代码仍可能误调用 Java 17 标准库；--release 8 同时限制可见的 Java SE API。
flowchart TD
A["源代码进入javac"] --> B["按release检查语法和标准库"]
B --> C["生成带major version的class"]
C --> D["目标JVM读取class头"]
D --> E{"运行JVM是否支持"}
E -- "支持" --> F["验证、链接、初始化"]
E -- "不支持" --> G["UnsupportedClassVersionError"]Maven 推荐明确配置：
<properties>
<maven.compiler.release>17</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>三、从 Java 8 到 17 的语言演进
3.1 Record：数据载体，不是所有对象的替代品
public record OrderSummary(long orderId, String status, long amountCent) {
public OrderSummary {
if (orderId <= 0) {
throw new IllegalArgumentException("orderId必须大于0");
}
if (amountCent < 0) {
throw new IllegalArgumentException("金额不能为负数");
}
}
}编译器会生成 final 字段、访问器、全参构造器、equals、hashCode 和 toString。Record 表达的是“值由全部组件共同定义”，适合接口 DTO、查询投影、领域值对象；它不是纯粹的 Lombok 缩写。
不应机械用于 JPA Entity：实体通常需要代理、无参构造、延迟加载和可变生命周期，而 Record 是 final、组件不可重新赋值。把两种模型混用，可能导致 ORM 无法代理或变更跟踪失效。
3.2 密封类：让类型分支成为可控集合
public sealed interface PayResult permits PaySuccess, PayRejected, PayPending {}
public record PaySuccess(String tradeNo) implements PayResult {}
public record PayRejected(String reason) implements PayResult {}
public final class PayPending implements PayResult {
private final String queryToken;
public PayPending(String queryToken) { this.queryToken = queryToken; }
public String queryToken() { return queryToken; }
}普通接口允许任意模块新增实现，调用方很难证明分支处理完整。密封层次把实现集合写进类型定义，适合支付结果、审批状态、协议消息等有限状态模型。它不适合需要第三方自由扩展的 SPI，否则扩展能力会被封死。
3.3 Switch 表达式：返回值并避免贯穿
static int priority(String level) {
return switch (level) {
case "URGENT" -> 100;
case "HIGH" -> 80;
case "NORMAL" -> 50;
default -> throw new IllegalArgumentException("未知级别: " + level);
};
}旧 switch 是语句，漏写 break 会意外进入下一分支；新写法可以产生值，并要求调用者明确处理默认分支。复杂分支可用 yield 返回结果。
3.4 instanceof 模式匹配：检查和绑定合并
static int textLength(Object value) {
if (value instanceof String text) {
return text.length();
}
return 0;
}变量 text 只在编译器能证明类型检查成立的控制流范围内可见，避免检查后再次强转。注意：Java 17 具备的是 instanceof 模式匹配；更完整的 Switch 模式匹配是后续版本能力，不能混写版本边界。
3.5 文本块：减少转义，不改变字符串语义
String query = """
SELECT id, status, amount_cent
FROM t_order
WHERE tenant_id = ? AND created_at >= ?
ORDER BY id DESC
""";文本块仍是 String。缩进、尾随换行会影响最终内容，涉及签名、SQL 快照或协议报文时必须测试实际字节，不能只看源码排版。
四、JPMS 与强封装：旧反射代码为什么会坏
Java 9 引入模块系统。模块不仅描述依赖，还区分：
exports：允许其他模块在编译期和运行期使用公开类型。opens：允许深反射访问包内成员。requires：声明读取另一个模块。
Java 17 强化了 JDK 内部 API 的封装。旧框架若通过 setAccessible(true) 访问未开放的 JDK 内部成员，可能抛出 InaccessibleObjectException。
flowchart TD
A["框架尝试深反射"] --> B["JVM检查模块边界"]
B --> C{"目标包是否opens"}
C -- "是" --> D["允许反射访问"]
C -- "否" --> E["InaccessibleObjectException"]
E --> F["优先升级依赖或改用公开API"]
F --> G["临时方案才评估add-opens"]--add-opens java.base/java.lang=ALL-UNNAMED 可以临时绕过限制，但它会扩大封装边界，不应成为永久修复。正确顺序是：定位哪个 Jar 在反射、升级组件、替换内部 API、最后才做有范围且有下线计划的临时开放。
五、JVM 与运行时的重要变化
5.1 默认 GC 变化
常见 HotSpot 配置中，Java 8 默认多见 Parallel GC，Java 9 起服务器场景默认转向 G1。升级后即使没有修改 GC 参数，停顿分布、吞吐、堆区布局和日志格式也可能变化。
G1 把堆划分为 Region，按预测收益回收一组 Region，目标是更可控地满足停顿目标；它不是保证每次停顿都小于 MaxGCPauseMillis。升级必须比较吞吐、P99、Full GC、分配速率和容器 RSS，不能只比较平均响应时间。
5.2 容器感知
现代 JDK 能识别 cgroup 的 CPU 和内存限制。堆不是容器内存的全部，还包括元空间、线程栈、直接内存、Code Cache、GC 数据结构和本地库。只设置 -Xmx 接近容器上限，会让进程被操作系统 OOM Kill，即使 Java 堆没有 OOM。
可使用百分比参数建立预算：
java -XX:InitialRAMPercentage=40 -XX:MaxRAMPercentage=65 -jar app.jar比例只是起点，最终要基于线程数、直接内存和真实 RSS 压测。
5.3 GC 日志语法
Java 8 常见：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/gc.logJava 17 使用统一日志：
-Xlog:gc*,safepoint:file=/logs/gc.log:time,uptime,level,tags:filecount=10,filesize=100M把 Java 8 参数原样复制到 17，可能报“不识别参数”或丢失预期日志。启动脚本也属于升级范围。
六、依赖与已移除能力风险
常见升级风险包括：
| 风险 | 表现 | 根因与处理 |
|---|---|---|
| Java EE/CORBA 模块不再随 JDK 提供 | ClassNotFoundException | 显式引入所需规范依赖；不要与 Jakarta 迁移混为一谈 |
| Nashorn 被移除 | 脚本引擎找不到 | 替换脚本引擎或消除隐式依赖 |
| 强封装 | InaccessibleObjectException | 升级依赖，减少 JDK 内部 API |
| 旧 GC 参数失效 | JVM 启动失败 | 用 java -XX:+PrintFlagsFinal 和统一日志核对 |
| TLS/算法默认值变化 | 老服务握手失败 | 修复证书和协议，不要长期降低安全基线 |
| Annotation Processor 不兼容 | 编译失败 | 升级 Lombok、MapStruct 和构建插件 |
七、JDK 8 到 17 生产升级 Runbook
- 盘点：记录 JDK 发行版、启动参数、Maven/Gradle、Agent、JNI、容器镜像和全部依赖。
- 建立基线：保存功能测试、吞吐、P95/P99、GC、RSS、CPU、线程和类加载数据。
- 只换运行时验证：若框架支持，先让原应用在 17 上运行，缩小“JDK变化”和“框架变化”的排查范围。
- 升级构建链：配置 Toolchains 或 CI 镜像，确保本地与流水线使用同一 JDK。
- 清理兼容问题：处理反射、移除模块、旧 Agent、旧插件和废弃 JVM 参数。
- 全链路回归：覆盖序列化、时区、TLS、文件编码、数据库驱动、MQ、定时任务和批处理。
- 压测比较：使用相同流量模型对比延迟、吞吐、GC 和内存，不凭感觉调参。
- 灰度与回滚：镜像标签、配置和数据库变更必须允许回退；按实例比例扩大流量。
flowchart TD
A["记录Java 8生产基线"] --> B["在隔离环境切到Java 17"]
B --> C["修复构建、反射、Agent和JVM参数"]
C --> D["功能与协议全量回归"]
D --> E["相同模型压测对比"]
E --> F["小流量灰度"]
F --> G{"错误率和资源是否达标"}
G -- "达标" --> H["逐步扩大流量"]
G -- "不达标" --> I["回滚并按证据定位"]八、商业场景：订单状态建模
Java 8 通常使用普通 DTO 和枚举；Java 17 可以用 Record 表达不可变快照、用密封类型约束处理结果。但数据库 Entity 仍保留普通类，避免把持久化模型、接口模型和领域结果强行合并。
一次合理的转换链是：
JPA Entity（可变持久化状态）
-> Domain Result（密封类型表达有限结果）
-> API Record（不可变响应快照）这样做的原因不是追求新语法，而是让每个模型承担单一职责。若一个 Entity 同时承担数据库映射、远程接口和业务状态机，字段变更会跨层扩散，懒加载对象也可能在 JSON 序列化时意外查询数据库。
九、升级故障从哪里取证
java -version
javac -version
mvn -v
java -XshowSettings:vm -version
jcmd <pid> VM.version
jcmd <pid> VM.command_line
jcmd <pid> VM.flags
jcmd <pid> GC.heap_info- 启动前失败：先看完整 JVM 错误、class major version 和启动参数。
- Spring 启动期失败：保存第一处
Caused by，再查依赖树，不要只看最外层异常。 - 流量进入后失败：按接口、Filter、序列化器、数据库驱动和 TLS 链路定位。
- 性能退化：对比同流量下 GC、Safepoint、JFR、CPU 火焰图和连接池等待。