Java 的更新节奏依然稳定。9 月 15 日，JDK 27 正式发布。作为按 6 个月节奏推出的新版本，JDK 27 并没有带来大规模语言语法重构，而是把重点放在 JVM 性能、内存占用、安全性以及并发编程等基础能力上。
不过，JDK 27 并不是长期支持版本（LTS）。Oracle 将为其提供 6 个月更新支持，直到 2027 年 3 月由 JDK 28 接替。当前 Java 最新的 LTS 版本仍然是 JDK 25。
整体来看，此次 JDK 27 一共包含 9 个正式纳入 JEP（JDK 增强提案）的特性，其中 4 个仍处于 Preview（预览）阶段，1 个处于 Incubator（孵化器）阶段。
以下是一些值得关注的变化：
G1 终于成为所有环境的默认垃圾收集器
这次最容易影响普通 Java 应用运行方式的变化之一，是 JEP 523：Make G1 the Default Garbage Collector in All Environments。
G1（Garbage-First）垃圾收集器并不新：从 Java 9 开始它就是 HotSpot JVM 在服务器环境中的默认垃圾收集器。但此前在一些资源受限环境，例如仅有一个 CPU，或内存低于一定规模的机器上，JVM 仍可能回退到 Serial GC。JDK 27 改变了这个默认行为。现在只要开发者没有在命令行中显式指定垃圾收集器，HotSpot JVM 就会统一选择 G1。也就是说，不管是服务器还是资源相对有限的设备，默认 GC 都是 G1。
能这样调整，靠的是 G1 近些年的持续优化。OpenJDK 团队希望，在原本会使用 Serial GC 的场景切换到 G1 后，吞吐量、延迟、内存占用和启动时间等指标不会出现明显下降。
对象头从 96 位压到 64 位，紧凑对象头正式默认开启
另一个与 JVM 内存效率直接相关的变化，是 JEP 534：Compact Object Headers by Default。
在 HotSpot JVM 中，每个 Java 对象除了自身数据，还要携带对象头（Object Header），里面是对象相关的运行时信息。从 JDK 27 开始，紧凑对象头成为 HotSpot JVM 的默认对象头布局。
在 64 位架构下，紧凑对象头可以把对象头从 96 bit 降到 64 bit。对于大量小对象组成的 Java 应用，这意味着更少的额外内存开销、更低的堆内存占用，同时提高部署密度和数据局部性。
这个变化看起来不如新语法显眼，但对大量创建对象的 Java 服务来说，可能比某个语言特性更基础。尤其在云服务器和微服务环境中，一台机器需要承载更多服务时，每个对象省下的空间累加起来，就可能转化为更高的内存利用率。
Java 开始为“量子时代”提前准备
如果说前两个变化主要针对 JVM 本身，那么 JDK 27 在安全方面最值得关注的更新，就是 JEP 527：Post-Quantum Hybrid Key Exchange for TLS 1.3。
简单来说，Java 27 为 TLS 1.3 增加了后量子混合密钥交换能力。
这里的核心概念是“混合”。传统加密算法继续承担一部分保护，另一部分则使用能够抵御未来量子计算攻击的抗量子算法。两者组合后，即使未来量子计算机对传统公钥密码体系构成威胁，通信系统也能获得更高安全性。
对 Java 开发者而言，重要的一点是：使用 javax.net.ssl API 的应用可以直接受益于这套改进，不需要修改现有代码。
与此同时，JDK 27 还继续推进 JEP 538：PEM Encodings of Cryptographic Objects。PEM 是 Privacy-Enhanced Mail 的缩写，如今已成为非常常见的密钥和证书编码格式。JDK 27 提供新的 API，用于在 Java 对象与 PEM 格式之间进行编码、解码，覆盖加密密钥、证书以及证书吊销列表等对象。这一特性目前仍处于第三次 Preview。
结构化并发第七次预览
Java 的并发模型也在继续推进。这次 JEP 533：Structured Concurrency（结构化并发）已经进入第七次 Preview。
它想解决的问题并不复杂：当一个任务需要同时启动多个子任务时，开发者通常还要自己处理线程之间的生命周期、异常、取消和资源清理。结构化并发希望把一组相关并发任务当成整体来管理。例如，一个请求同时调用多个服务时，这些子任务可以被组织成明确的任务结构。当其中一个失败，或整个操作被取消时，相关任务也能按照统一生命周期处理。
这样做的目标，是让并发代码更容易维护，同时改善异常处理、任务取消以及可观测性，减少线程泄漏和取消延迟等问题。
不过需要注意，结构化并发在 JDK 27 中依然只是 Preview，还不是最终确定的 Java SE 标准特性。
instanceof、switch 终于可以更自然地处理原始类型
JDK 27 还继续推进 Java 模式匹配能力。JEP 532：Primitive Types in Patterns, instanceof, and switch 进入第五次 Preview。
它解决的是 Java 模式匹配体系中长期存在的一些限制：让原始类型能够更统一地参与模式匹配，并让 instanceof 和 switch 支持所有原始类型。
这意味着开发者可以用更统一的方式处理 int、long、double 等原始类型，不必因为基本类型与对象类型的差异引入额外转换或特殊处理。同时，这个 JEP 还进一步收紧了 switch 中的支配关系检查，并完善了“无条件精确性”的定义，让编译器能发现更多潜在错误。
从 Java 21 开始，模式匹配相关能力一直是 Java 语言演进的重要方向。JDK 27 更像是在继续补齐这套体系，而不是突然加入一个完全陌生的语法。
Lazy Constants：让常量初始化可以“晚一点”
JDK 27 还带来 JEP 531：Lazy Constants 的第三次 Preview。
传统 final 字段能保证值不会被重新赋值，但初始化时机通常仍受到对象创建和类初始化机制的影响。Lazy Constants 提供了一种新 API，让保存不可修改数据的对象可以延迟到真正需要时再初始化。
JVM 会把 Lazy Constant 当作真正的常量，从而让它享受类似 final 字段的优化；与此同时，开发者又能更灵活地控制初始化时机。
对大型 Java 应用来说，这类能力的主要价值体现在资源利用和启动效率上，尤其适合需要加载大量配置、数据或其他高成本对象的应用。
Vector API 继续孵化，已经第 12 次
Java 在高性能计算方向也没有停下来。JEP 537：Vector API 在 JDK 27 中进入第 12 次 Incubator。
Vector API 允许开发者以 Java API 的方式表达向量计算，并让 JVM 在运行时将其编译为目标 CPU 支持的最佳向量指令。与一次处理一个数据元素的标量计算相比，向量指令可以在一次操作中处理多个数据，因此适合数据分析、科学计算以及 AI 推理等计算密集型场景。
不过，这仍不是最终版 API。值得一提的是，JetBrains 对 JDK 27 的介绍也指出，Vector API 在这一版本中没有相较 JDK 26 发生大的 API 变化，仍处于持续孵化阶段。
JFR 开始主动处理敏感信息
JDK 27 还对开发者经常使用的 JDK Flight Recorder（JFR）做了一项安全增强。JEP 536：JFR In-Process Data Redaction 允许 JFR 在进程内部对命令行参数、环境变量初始值以及系统属性初始值进行脱敏。
原因很现实。JFR 是 Java 应用诊断和性能分析的重要工具，但诊断信息中可能包含敏感数据，例如命令行参数中的密钥、环境变量中的访问令牌，以及系统属性中的密码。JDK 27 可以在这些信息离开进程之前脱敏，从而降低敏感数据通过诊断记录泄露的风险。
Java 27 不是“全面大改”的一个版本
如果把 JDK 27 的 9 个 JEP 放在一起看，会发现这次 Java 的更新很有特点。
它没有试图靠一个巨大的语言特性制造“Java 2.0”，而是在 JVM、并发、内存、安全和开发工具几个长期方向上继续向前推进。Oracle 也特别强调，除了 9 个 JEP 之外，JDK 27 还包含大量没有单独形成 JEP 的改进，例如 ML-KEM、ML-DSA、X25519 和 Ed25519 等密码算法的性能优化，G1 堆大小调整、C2 编译器优化、I/O 改进，以及诊断和运维工具的增强。
因此，对于已经运行在 Java 25 LTS 或其他稳定版本上的企业应用来说，JDK 27 更像是提供新能力和提前体验未来 Java 特性的 Feature Release，而不是必须立即升级的版本。毕竟，它只有 6 个月的支持周期。
如果是希望长期稳定运行的生产环境，目前 Java 的 LTS 主线仍然是 JDK 25；而对于希望提前尝试下一代 JVM、并发模型、安全机制和语言能力的开发者，JDK 27 则提供了不少值得测试的新东西。
从 Java 8 到 Java 17，再到如今的 Java 27，Java 的变化越来越不像过去那种“一次发布，几年不动”的模式。现在的 Java 更像在一条稳定流水线上持续迭代：每隔半年加入一批新能力，一部分成熟后正式落地，另一部分则继续以 Preview 或 Incubator 的方式接受开发者检验。
而这或许也是今天 Java 仍然能够保持生命力的重要原因。
来源：
发表于 1 小时前
|
查看: 6|
回复: 0
