Java 27 移除冻结应用的GC，对象内存开销减少 33%

Java 27 带来了两项变更，将悄然影响所有运行中的 JVM。G1 垃圾收集器现已成为每个 Java 运行时的默认选项——终结了在受限硬件上仍使用 Stop-the-World 串行收集器的局面——同时对象头从 96 位缩减至 64 位，对于任何创建大量对象的应用程序，开销降低了三分之一。

串行收集器是 Java 最古老的 GC：简单、可预测、但粗暴。当它运行时，会冻结整个应用程序直到堆被清理。在大内存、多 CPU 的服务器上，这种权衡多年前就已变得不可接受——从 Java 9 开始，G1 取代串行收集器成为服务器默认选项。受限环境（单 CPU 机器、小型云虚拟机、低内存嵌入式系统）一直使用串行收集器直到 Java 26。这一默认选项在 Java 27 中终结。

G1 将堆划分为多个小区域，并增量式回收，优先处理垃圾最多的区域——因此得名 Garbage-First。停顿仍然存在，但比串行完整收集更短、更可预测。甲骨文公司表示，G1 现在在所有堆大小上都与串行收集器具有竞争力。对于在可用的最廉价云实例（一个 CPU、1GB 内存）上部署应用程序的开发者来说，Java 27 消除了他们多年来一直忍受的摩擦。

紧凑对象头变更是本次发布的另一半。Java 对象携带元数据——类型信息、哈希码、锁定状态——存储在附加到每个对象的头部中。旧格式使用 96 位。Java 27 将其压缩至 64 位，每个对象减少 33%。对于创建数百万个对象的应用程序——消息队列、金融账本、事件驱动微服务——累积效果是可测量的：更密集的堆、更好的 CPU 缓存利用率、更少的收集周期。

两项变更都有注意事项。专门针对串行 GC 行为调优的应用程序在升级后可能会遇到意外的时序差异。G1 用于记账的内存比串行收集器多，这在内存预算真正紧张的环境中很重要——尽管甲骨文公司的测试表明，对于大多数工作负载，吞吐量权衡可以忽略不计。在受限系统上部署 Java 27 的开发团队应在发布前针对新默认值进行测试。过渡是自动的，但并非不可见。

Java 27 还为 TLS 1.3 添加了后量子混合密钥交换，实现了 ML-KEM 算法，与现有的 X25519 椭圆曲线交换并行。今天协商的 TLS 连接理论上可能被未来的量子计算机捕获并解密。混合密钥交换通过要求攻击者同时破解经典算法和后量子算法来防御这一点——对于任何处理敏感数据的 Java 服务来说，这是一个有意义的补充。

Java 27 于 2026 年 9 月 15 日发布，遵循该平台每六个月一次的发布节奏。结构化并发和惰性常量在此版本中继续作为预览特性。Java 系列的下一个长期支持版本预计在 2027 年发布。

标签: 编程, Oracle, G1 GC, garbage collection, Java, JVM