从 Java 9 到 Java 17：核心特性演进全解析

一、为什么要回头梳理 Java 9~17

Java 8 是继 Java 5 之后影响最深远的一次版本升级：Lambda 表达式让函数式编程正式进入主流开发流程；Stream API 彻底改变了集合的处理思路——开发者只描述“想要什么结果”，而不必亲手编排“如何遍历、如何过滤”；同一时期引入的全新日期时间 API、增强的并发工具、新的客户端图形界面工具包以及内置的 JavaScript 执行引擎，共同构成了沿用至今的技术基线。

但基线不等于终点。从 2017 年底开始，Java 改为每六个月发布一个大版本，并引入“长期支持版本（LTS）”的概念，Java 11 与 Java 17 正是模块化时代先后到来的两个 LTS。与此同时，生态层面也在倒逼升级：业界主流的企业级开发框架已相继宣布其新版本将以 Java 17 作为最低运行要求。这意味着，若仍停留在 Java 8，未来想使用新框架的能力，就必须跨过中间近十个版本。

Java 之父也曾公开回应过“新版本普及为何偏慢”的疑问：Java 长期以稳定、非破坏性升级著称，绝大多数情况下直接安装新版本即可正常运行；从 Java 8 到 Java 9 是发展史上少有的一次真正重大更替，主要源于模块化带来的约束，此后的版本迁移则平缓得多。因此，理清 9 到 17 的演进脉络，不仅是为了“跟上版本”，更是为了理解语言设计者的取舍方向。

二、Java 9：模块化元年

1. 平台模块系统（JPMS）

Java 9 最大的变化是引入模块化：将类型与资源封装进模块，通过声明式文件显式控制依赖与可见性：

module com.example.order {
    requires com.example.common;      // 声明依赖的其他模块
    requires java.net.http;           // 声明依赖的 JDK 模块
    exports com.example.order.api;    // 对外暴露的包
    opens   com.example.order.model;  // 允许深度反射访问的包
}

未导出或未开放的包，即视为模块设计者不希望对外使用，后续版本可以在不另行通知的情况下修改甚至删除。这与前端工程中通过导出/导入控制可见性的思路类似。

模块化的收益十分明确：

• 可靠封装：内部包不再因类路径全开放而被随意反射；
• 更小的运行时：可按需裁剪出只包含所需模块的自定义运行时镜像；
• 更清晰的依赖关系：循环依赖在模块层面被直接拒绝。

代价是迁移成本：依赖内部 API 的老代码、重度依赖反射的框架，都需要在 9 之后逐步适配。

2. 语言与 API 的实用增强

• 接口私有方法：默认方法得以复用私有逻辑，避免在接口内出现重复代码：

public interface Parser {
    default int parse(String raw) {
        String v = normalize(raw);
        return v == null ? 0 : Integer.parseInt(v);
    }
    private String normalize(String raw) {
        return raw == null ? null : raw.trim();
    }
}

• 集合工厂方法：一行创建不可变集合，取代冗长的组装代码：

List<String> roles = List.of("admin", "user");
Map<String, Integer> conf = Map.of("timeout", 30, "retries", 3);

• try-with-resources 增强：effectively final 的变量可直接放入 try 括号，无需再定义临时变量；
• @SafeVarargs 适用范围扩展到私有方法；
• Process API 改进：新增进程句柄能力，可获取进程编号、父子关系并支持更优雅的销毁；
• JShell：JDK 自带的交互式编程环境，适合快速验证语法与 API 行为；
• 其他：支持 HTTP/2 的新客户端以孵化模块形式首次亮相；紧凑字符串优化了字符串内存占用；多版本 JAR 让同一构件可同时携带面向不同 JDK 的字节码。此外，G1 从本版本起成为默认垃圾收集器。

三、Java 10 与 11：var 问世与首个模块化 LTS

Java 10 最受关注的是局部变量类型推断：

var cache = new HashMap<String, List<Integer>>(); // 省略右侧重复泛型

var 只能用于局部变量，类型推导在编译期完成，Java 依然是严格的静态类型语言。同版本还包括应用类数据共享（缩短启动时间）、G1 并行化全量回收，以及更友好地感知容器资源配额等运行时改进。

Java 11 是模块化后的第一个 LTS，也是许多团队的实际升级目标：

• HTTP 客户端正式标准化，支持 HTTP/2 与异步调用：

HttpClient client = HttpClient.newHttpClient();
HttpRequest req = HttpRequest.newBuilder()
        .uri(URI.create("https://your-api-host/data"))
        .build();

• String 补齐 isBlank、strip、lines、repeat 等高频方法；
• lambda 形参也可使用 var；
• 单文件直接运行：java Hello.java，降低脚本化使用门槛；
• 移除 Java EE 与 CORBA 相关模块，内置 JavaScript 引擎进入废弃流程（后续版本被移除）；
• 支持 TLS 1.3；低延迟收集器 ZGC 与“无操作”收集器 Epsilon 以实验特性引入；飞行记录器（JFR）全面开放使用。

四、Java 12~14：语法现代化三步走

这三个版本的核心主题是语法现代化，大量特性以预览形式逐步打磨：

1. switch 表达式（14 转正）：箭头语法、多值匹配、yield 返回值，直接消灭漏写 break 的隐患：

int days = switch (month) {
    case 1, 3, 5, 7, 8, 10, 12 -> 31;
    case 4, 6, 9, 11           -> 30;
    case 2                     -> 28;
    default                    -> throw new IllegalArgumentException("非法月份");
};

1. 文本块（13 预览、15 转正）：多行字符串不再需要拼接换行符与转义引号：

String json = """
        {
          "name": "service-a",
          "port": 8080
        }
        """;

1. record（14 预览）：为“纯数据载体”提供一行式声明，自动生成构造器、访问器与 equals/hashCode/toString：

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

1. instanceof 模式匹配（14 预览）：类型判断与强制转换合并为一步；
2. 收集器方面：CMS 在 14 被移除；另一款低延迟收集器于 12 以实验特性加入；G1 与 ZGC 先后具备将空闲内存归还操作系统的能力；
3. 一个广受欢迎的小改动：空指针异常会精确指出哪个引用为 null，显著缩短排错时间。

五、Java 15~16：新语法转正与 GC 成熟

• 文本块正式发布；隐藏类为框架的动态字节码生成提供了更安全的载体；
• ZGC 等低延迟收集器转为正式特性，超大堆上的低停顿回收进入生产可用阶段；
• 16 中，record 与 instanceof 模式匹配双双转正，Stream 新增 toList() 终结操作，收集结果列表不再依赖冗长的收集器写法；
• Unix 域套接字通道补齐了本机进程间通信能力；
• JDK 内部 API 自 16 起默认强封装，为 17 的最终落地铺路。

六、Java 17：聚合与奠基的新 LTS

作为继 11 之后的第二个 LTS，Java 17 更多是“收束与奠基”：

• 密封类正式发布：父类可显式声明允许哪些子类继承或实现，让“受限的继承树”成为语言能力，也为后续模式匹配铺路：

public sealed interface Shape permits Circle, Square {}
public record Circle(double radius) implements Shape {}
public record Square(double side) implements Shape {}

• switch 的模式匹配进入预览，按类型分发有望逐步取代冗长的条件分支链；
• 强封装 JDK 内部 API 最终落地：非受支持的内部类默认不再可访问，这是老应用升级时最常见的拦路虎；
• 伪随机数生成器体系重构，提供可插拔、可流式使用的随机数接口；
• 移除实验性 AOT/JIT 实现，废弃 Applet API。

七、从 Java 8 到 17 的升级建议

1. 分两步走：先升 11，再升 17。两个 LTS 之间的问题域不同，分步升级更容易定位故障；
2. 依赖先行：优先确认核心框架与中间件客户端是否声明支持 17，字节码增强类库（如各类持久化、代理、序列化实现）是兼容性问题高发区；
3. 借助 JDK 自带的依赖分析工具扫描对内部 API 与废弃 API 的引用，形成整改清单；
4. 模块化不必一步到位：普通应用可继续以类路径方式运行，仅需为强封装问题补充启动参数或替换内部 API 用法；真正需要强边界的类库才建议编写模块描述文件；
5. 运行时同步评估：G1 是默认选择，对停顿敏感的大堆服务可评估 ZGC；容器化部署注意让 JVM 正确感知配额。

八、结语

从 9 到 17，Java 的演进主线非常清晰：模块化重构平台边界，var、文本块、switch 表达式、record、密封类持续压缩样板代码，ZGC 等新一代收集器重塑延迟上限，而 LTS 节奏与生态框架的版本要求共同把 17 推成了新的基线。对仍停留在 Java 8 的团队而言，越早建立这张版本地图，升级路线就越从容。