简介：本文系统梳理 Java 9 至 Java 17 的关键演进：模块化、var、Switch 表达式、文本块、记录类、密封类等语言新特性，以及垃圾收集器与容器化适配等运行时优化，并给出向 Java 17 平滑迁移的实用建议，帮助开发者理解升级收益、避开常见兼容性陷阱。

一、背景：为什么现在必须关注 Java 9~17

Java 8 是一个里程碑式的版本：Lambda 表达式让函数式编程随大数据浪潮进入主流视野，Stream API 让开发者只关注“要什么结果”而不必纠缠“如何遍历”，再加上全新的日期时间 API、增强的并发工具、客户端图形界面库以及脚本交互引擎等改进，Java 语言与类库仿佛获得新生。也正因如此，大量存量系统长期停留在 Java 8。

但停滞不是长久之计。Java 之父近期在访谈中直言：新版本在性能、安全性与扩展效率上全面占优，是时候做出改变了；从 Java 8 迁移到 Java 9 确实是发展史上少有的一次较大跨越，但此后的版本更替大多十分平滑——安装新版本，程序基本照常运作。

更现实的推动力来自生态层面：业界主流的企业级开发框架已相继宣布，其新一代版本将以 Java 17 作为最低运行要求。这意味着，如果想继续使用框架的新特性与安全补丁，升级已从“可选项”变成“必选项”。而升级路上被跳过的每一个版本，都可能藏着影响兼容性的细节。

还有一个容易被忽视的变化：自 Java 9 起，JDK 改为每六个月发布一个新版本，并每隔数年提供一个长期支持（LTS）版本。Java 11 与 Java 17 就是继 Java 8 之后最重要的两个 LTS 版本。理解这中间被跳过的内容，是顺利升级的前提。

二、Java 9：模块化开启，语法小步快跑

2.1 模块系统（JPMS）

Java 9 最大的特性是引入模块化：将类型与资源封装进模块，仅显式导出允许其他模块访问的公共包，思想上前端工程中的 export/import 颇为相似。若模块中的某个包既未导出也未开放，即表示设计者不希望它在模块之外被使用——这类内部包未来可能被修改甚至删除，无需另行通知。

module com.example.payment {
    requires java.net.http;             // 声明依赖
    exports com.example.payment.api;    // 对外暴露的包
    opens   com.example.payment.model;  // 允许反射访问
}

模块化带来三大收益：

可靠封装：深度反射不再能随意越权访问平台内部实现；
依赖清晰：模块层面禁止循环依赖，架构边界更加明确；
精简运行时：配合 jlink 工具可按需裁剪出只含所需模块的定制运行时镜像，显著缩小容器镜像体积。

需要强调的是，对绝大多数仍以类路径（classpath）方式运行的传统应用，模块化并非强制：不编写 module-info.java，应用照常工作，这为渐进式迁移留出了空间。

2.2 语法与 API 增强

接口私有方法：接口内可定义 private 方法，用于抽取多个默认方法间的公共逻辑；
Try-With-Resources 增强：try 块外声明、事实上不可变的变量可直接放入 try 括号，无需再引入临时变量；
@SafeVarargs 注解适用范围扩大到 private 方法；
集合工厂方法：List.of(…)、Set.of(…)、Map.of(…) 一行创建不可变集合；
Stream 与 Optional 增强：新增 takeWhile、dropWhile、iterate 三参重载，Optional 增加 ifPresentOrElse、or、stream 等方法；
JShell：JDK 自带的交互式编程环境（REPL），适合快速验证 API 行为；
G1 成为默认垃圾收集器，取代服役多年的并行收集器；
进程 API 改进（ProcessHandle），HTTP/2 客户端以孵化模块登场。

三、Java 10 与 11：类型推断落地，LTS 稳固根基

3.1 var：局部变量类型推断

Java 10 引入 var，由编译器根据右侧表达式推断类型，消除冗长声明：

var orders = new HashMap<String, List<Order>>();

注意其边界：只能用于带初始化器的局部变量、增强 for 循环变量等场景，不能用于字段、方法参数与返回值——这保证了类型信息在 API 边界上依然显式可见。

3.2 Java 11：新节奏下的第一个 LTS

HTTP Client 转正：java.net.http 标准化，原生支持 HTTP/2 与异步调用；
var 可用于 Lambda 参数；
String 增强：isBlank、lines、strip、repeat 等高频方法补齐；
Files.readString / writeString 简化小文件读写；
单文件源码直接运行：java Hello.java，降低脚本化使用门槛；
移除历史遗留的 Java EE 相关模块与 CORBA，客户端图形库也与 JDK 解耦；内置 JavaScript 引擎进入废弃流程并在后续版本移除；
ZGC（实验性）、无操作收集器 Epsilon 登场；飞行记录器（JFR）能力内置并开源；TLS 1.3 支持。

四、Java 12~16：现代语法密集落地

这一阶段是语言现代化最密集的时期，多数特性经过两轮预览后转正。

4.1 Switch 表达式（Java 14 转正）

int days = switch (month) {
    case JAN, MAR, MAY -> 31;
    case FEB -> 28;
    default -> 30;
};

箭头语法免写 break、支持返回值，编译器还会检查分支穷举性，逻辑遗漏在编译期即可暴露。

4.2 文本块（Java 15 转正）

String json = """
    {
      "name": "demo",
      "version": 1
    }
    """;

多行字符串不再需要拼接与转义，SQL、JSON、HTML 模板的可读性大幅提升。

4.3 记录类 Record（Java 16 转正）

public record Point(int x, int y) {}

一行声明即获得构造器、访问器与 equals/hashCode/toString，是对“纯数据载体”的官方建模，可替代大量样板代码。

4.4 instanceof 模式匹配（Java 16 转正）

if (obj instanceof String s) {
    System.out.println(s.length()); // 无需强制转换
}

4.5 其他要点

密封类 15 预览、17 转正；
“有用的 NullPointerException”可直接指出哪个变量为空；
移除 CMS 收集器；ZGC 与 Shenandoah 在 15 达到生产可用；
外部内存访问 API 持续孵化，为逐步替代不安全的内部接口铺路。

五、Java 17：LTS 上的收敛与强化

密封类定稿：sealed + permits 精确控制继承树，与 Record、模式匹配组合后，“受限的代数数据类型”式建模成为可能；
JDK 内部 API 强封装收官：默认拒绝非法的深度反射访问，此前依赖内部实现的老库需要升级或临时放宽参数；
伪随机数体系重构：统一 RandomGenerator 接口，算法选择更丰富、可替换；
移除实验性 AOT/JIT 编译器、RMI Activation 等历史包袱；
新增 macOS ARM 支持；外部函数与内存 API、Switch 模式匹配等继续向前演进。

六、垃圾收集与运行时的“隐性升级”

升级收益远不止语法层面：

G1 自 9 起为默认收集器，10 支持并行 Full GC，并持续优化空闲时将内存归还操作系统；
ZGC 的设计目标是将停顿控制在毫秒级甚至亚毫秒级，且与堆大小基本无关，适合大堆低延迟场景；Shenandoah 思路类似；
容器感知：JVM 能正确识别容器配额，按容器限制而非宿主机资源计算堆大小与线程数，这是云原生部署的关键前提；
紧凑字符串（9）使纯拉丁字符存储占用近乎减半；应用类数据共享（10）显著加快启动速度。

七、升级路径与迁移建议

先评估再动手：使用 jdeps 等 JDK 自带工具扫描对内部 API 与已移除模块的依赖；
补齐被移除的能力：XML 绑定等模块已从 JDK 剥离，需显式引入对应依赖；
处理反射与内部 API：强封装后，依赖内部包的框架类库需升级到兼容版本，或短暂通过启动参数放宽（仅作过渡手段）；
建议两步走：Java 8 → 11 → 17，每一步充分回归测试，切勿一步跨到位；
善用云平台通用能力：可借助云厂商提供的容器平台、日志服务与监控告警（百度智能云等主流云平台均有此类通用服务）进行灰度发布，对比升级前后的延迟、内存与 GC 指标，用数据确认升级收益；
关注生态兼容：构建插件、字节码增强、序列化等组件对 class 文件版本号敏感，需同步升级。

八、结语

从 9 到 17，Java 走出了一条“先夯实底座、再现代化语法”的路线：模块化重塑平台边界，var、Switch 表达式、文本块、Record、密封类让代码更简洁也更安全，垃圾收集器演进与容器化适配则让 Java 在云原生时代保持竞争力。对仍停留在 Java 8 的团队而言，Java 17 是当前性价比最高的落点——既享受 LTS 的稳定与长期支持，又顺势完成一次面向未来的技术升级。

从 Java 8 到 Java 17：版本演进核心特性全解析