2021 年 9 月，Java 17 正式发布。对很多仍停留在 Java 8 的团队来说，它看起来像一次跨越九个版本的大升级；对已经适应半年一个版本节奏的开发者来说，它又只是一个新的长期支持节点。
Java 17 最值得讨论的，并不只是 sealed class 或模式匹配，而是 Java 平台终于用稳定节奏证明：一门二十多岁的语言也可以持续演进，同时保住企业软件最看重的可预测性。
语言开始更准确地表达领域约束
在 Java 17 之前的几个版本中，record、文本块、switch 表达式陆续成为正式特性；Java 17 又带来了 sealed class，并继续预览 switch 的模式匹配。
这些语法糖的共同方向，是让代码更接近我们真正想表达的模型。record 适合不可变数据载体，sealed class 可以明确一个类型只允许哪些子类。过去写在注释里、依靠团队默契维持的约束，现在有机会交给编译器检查。
这不代表所有 DTO 都该改成 record，也不代表继承层次越封闭越好。新语法的价值从来不是少写几行，而是减少非法状态和模糊边界。如果领域本身仍在频繁变化，过早封闭类型反而会增加修改成本。
JVM 与运行时同样在变化
Java 17 包含大量不显眼但重要的改进：垃圾收集器继续演进，JDK 内部 API 的封装进一步收紧，旧组件和过时机制逐步退出。很多升级问题并不来自业务代码，而来自框架、字节码工具、代理和监控组件对 JDK 内部实现的依赖。
因此，从 Java 8 跨到 17 不应被当成“换一个环境变量”。比较稳妥的路线是先升级构建工具和依赖，再处理非法反射与废弃 API，随后用真实流量模型做 GC 和延迟测试，最后通过灰度逐步替换运行实例。
升级前后只比较平均吞吐量还不够。启动时间、P99 延迟、内存占用、线程数、类加载失败和观测代理是否正常，都应该进入验收清单。
LTS 不是“永远不用升级”
很多组织把 LTS 理解成可以长期冻结的版本。我的理解恰好相反：LTS 的意义是给组织一个明确的汇合点，让升级成为有计划的工程，而不是在安全补丁或框架停止支持时被迫跳跃。
如果每次都跨越八九个版本，团队会同时面对语言、JVM、依赖和运维工具的变化，风险自然被放大。半年发布一次的新节奏，真正要求的是持续兼容意识：在日常 CI 中保留新 JDK 的试运行，在依赖升级时关注最低和最高支持版本，并定期清理对内部 API 的依赖。
我的理解：Java 的优势是“有秩序地变”
Java 经常被批评保守，但企业系统需要的并不是最快出现的语法，而是可以解释、可以迁移、可以长期维护的变化。Java 17 一边吸收现代语言的表达方式，一边用预览、弃用和 LTS 节点控制节奏，这种机制本身就是平台价值的一部分。
对后端团队而言，最有价值的实践不是立即用遍所有新特性，而是建立一条可重复的升级流水线。能够小成本跨版本的系统，才真正享受得到 JVM 性能、安全修复和生态创新；永远停在旧版本，看似稳定，其实只是在积累一次更昂贵的迁移。
参考资料
本文是 2026 年整理断更期时写下的回顾，发布日期按事件所处阶段归档。