Java 27 深度解析：默认变更如何悄悄改变生产环境

Java 27 正式发布，这是近年来体量最小的一次更新——仅有 9 个 JEP（对比 Java 24 的 24 个、Java 25 的 18 个、Java 26 的 10 个）。但别被数字迷惑，这个「更小」的版本在幕后动了不少默认配置。哪怕你不写一行新代码，只要升级或迁移到下一个 LTS 版本 Java 29，你在生产环境跑的东西就会发生变化。

本文基于 YouTube 上一位 Java 开发者对 Java 27 的深度解读，梳理其中真正值得关注的几项改动。

紧凑对象头：默认开启，堆内存直降

对象头（object header）是 JVM 在每个堆对象上附加的元数据，用于加锁、垃圾回收以及识别对象所属的类。这个头部长期以来是 12 字节，而紧凑对象头（compact object headers）把它压缩到了 8 字节，每个对象节省 4 字节。

听起来微不足道？但堆里从来不是一个对象，而是上亿个微小对象——每一个 Optional、每一个 DTO、每一条订单行、每一个庞大的 List。这些全都各自瘦身 4 字节。

这个特性其实在 Java 25 就已登场，但当时需要手动开启 UseCompactObjectHeaders 标志。现实是，很多人根本不会在服务正常运行时去改 JVM 标志——「没坏就别动」。到了 Java 27，这个标志不再需要，紧凑对象头成为默认行为。

JEP 给出的实测数据颇具说服力：在 SPECjbb2015 基准上，堆内存减少 22%、CPU 时间减少 8%、垃圾回收次数减少 15%。当然这只是单一基准，升级后你的 AWS 账单不会真的便宜 22%。但值得一提的是，亚马逊已在数百个生产服务中启用该特性（多数通过回移植到 Java 17 和 21 实现），SAP 甚至比 Oracle 更早在自家 JDK 中将其设为默认。

如果真的出问题，可以用 -UseCompactObjectHeaders 临时关闭——但要记住这只是临时方案，按照 JEP 450 的规划，旧的 12 字节对象头终将从 JDK 中彻底删除。

垃圾回收器：G1 成为无条件默认

很多人不知道，G1 虽然自 Java 9 起就是「默认」垃圾回收器，但这个默认其实是有条件的。如果你没有手动指定回收器，JVM 会检查所在机器：若发现只有 1 个 CPU 或内存低于 1792 MB，它会给你 Serial 回收器。

这意味着，一个小容器、一个 Lambda、或者只分配了单核的 Pod，一直以来都在跑 Serial。同一个应用会因为落在不同大小的机器上而使用不同的回收器。

Java 27 修复了这个问题：不指定回收器时，无论机器大小，一律使用 G1。

这并非完全免费的改动。Oracle 表示，在小型机器上，G1 的内存占用与 Serial 相当，吞吐略低，但最大延迟表现更好——也就是尾部延迟改善、原始吞吐略降。对大多数服务而言，这正是你愿意做的权衡。若不然，Serial 并未消失，设置 UseSerialGC 即可继续使用。

G1（Garbage-First）回收器自 Java 9 取代 Parallel GC 成为默认选项，其核心设计思路是将堆划分为若干大小相等的「Region」，优先回收存活对象最少的区域（即「垃圾最多」的区域），从而在可预测的停顿时间内最大化回收效率。相比之下，Serial GC 使用单线程完成所有回收工作，没有并发开销，在极小堆和单核环境下反而能避免多线程协调带来的额外成本，因此过去被 JVM 视为资源受限场景下的「务实选择」。然而容器化普及后，「单核 Pod」早已不意味着一台配置极差的旧机器，而可能是一个内存充裕、IO 性能优秀的现代云实例——此时 Serial GC 的尾部延迟特性反而成为累赘。Java 27 的修正正是认清了这一现实：机器规格不再是推断最佳回收策略的可靠信号，统一使用 G1 反而能提供更一致的行为预期。

Flight Recorder：默认脱敏敏感信息

Flight Recorder 会记录运行中 JVM 的一切，这样当生产环境凌晨两点出事时，你能回溯到底发生了什么。问题在于「一切」也包括进程的启动方式。

JEP 直接给出了例子：环境变量里的访问令牌、系统属性里的 keystore 密码、命令行参数里的数据库密码——三个秘密。在 Java 27 之前，这三项都会以明文形式出现在记录文件里。当有人把这份 dump 复制粘贴进 Jira 工单，或者丢给 AI agent 时，你的生产凭证就泄露到了不该出现的地方。

Java 27 在数据写入磁盘之前就对这些内容进行脱敏处理，且默认生效，无需任何配置。

抗量子加密：防御「先收割，后解密」

这是本次更新中最有意思的一项——JEP 527，量子计算相关。它不是为了让你的应用今天变得更好，而是关乎你今天加密的流量在 10 到 15 年后是否依然安全。

Java 27 将后量子密钥交换（post-quantum key exchange）内建进 TLS 1.3 和 JDK 本身。今天的量子计算机破解不了这些加密，但这个 JEP 防御的是一种正在发生的攻击——「harvest now, decrypt later」（先收割，后解密）：攻击者今天截获你的加密流量，读不了没关系，先存上十年十五年，等量子计算机成熟了再来破解。

对于处理医疗记录、银行转账、政府数据等在十年后依然重要的信息的人来说，你需要加密能扛住那时存在的计算机。

具体实现上，JEP 为 TLS 1.3 增加了混合密钥交换：同时运行经典的椭圆曲线密钥交换 X25519 和后量子算法 ML-KEM，将两者的共享密钥合并为一个。之所以做成混合模式，是因为如果 ML-KEM 存在缺陷（后量子算法此前发生过），经典一侧仍能兜底；而如果量子计算机真的出现，ML-KEM 一侧依然可靠——本质是冗余，攻击者必须同时攻破两者。

据 Oracle 提示，如果你的应用使用 Java 标准的 javax.net.ssl 栈，且未自行覆盖 TLS 命名组，那么这个特性默认生效，无需改动任何代码。

ML-KEM（Module Lattice-based Key Encapsulation Mechanism）是美国国家标准与技术研究院（NIST）于 2024 年正式标准化的后量子密钥封装算法，前身为 CRYSTALS-Kyber。它的安全性基于「模格上的带误差学习问题」（Module-LWE），目前没有已知的量子算法能在多项式时间内求解该问题，而经典的 RSA 和椭圆曲线密码学（ECC）则会被 Shor 算法在足够强大的量子计算机上高效破解。X25519 是基于 Curve25519 椭圆曲线的 Diffie-Hellman 密钥交换协议，以高性能和抗侧信道攻击著称，是当前 TLS 1.3 最广泛使用的密钥交换算法。将两者混合使用的策略，在后量子密码学领域被称为「hybrid key exchange」，它的逻辑前提是：安全性取其强者——只要两个算法中有一个未被攻破，整个密钥交换就是安全的。这一设计在 NIST 完成标准化之前的过渡期尤为重要，因为新算法的实现和数学基础仍有可能存在尚未发现的缺陷。

仍在预览与孵化中的特性

本次还有五个 JEP 处于预览或孵化阶段：

• 惰性常量（Lazy Constants）：第三次预览
• 模式中的原始类型（Primitive Types in Patterns）：第五次预览，即在 int 上做 switch 而无需装箱
• PEM 编码：第三次预览
• 结构化并发（Structured Concurrency）：第七次预览，自 Java 21 起持续预览
• Vector API：第 12 次孵化，从 Java 16 就开始了

Vector API 迟迟不定稿是有原因的：JEP 明确表示它在等待 Valhalla。团队不希望在一套对象模型上定稿 API，然后让 value class 把底层全部改变。

Project Valhalla 是 Oracle 自 2014 年启动的长期 JDK 研究项目，核心目标是引入「值类型」（value types / value classes）：一种没有对象身份（identity）的内联数据载体，可以像 int 一样在栈上分配或在数组中平铺存储，彻底消除当前泛型和集合对基本类型的「装箱税」。Vector API 依赖 Valhalla 的原因在于：向量运算的高性能实现需要将大量数值紧凑排列在连续内存中，而当前对象模型的堆引用语义和对象头开销会破坏这一布局。一旦 value class 落地，JDK 就能将 VectorFloat256 这类类型直接映射到 CPU 的 SIMD 寄存器，而无需通过引用间接访问。结构化并发同样持续预览多版，主要原因是社区仍在就 API 细节（如作用域继承、异常传播策略）进行讨论，而非技术实现存疑——这也说明「预览」机制本身正在发挥它设计时的初衷：给足时间收集真实使用反馈，再最终定稿。

一切默认开启，重点在下一个 LTS

Java 27 有一条贯穿始终的主线：你几乎什么都不需要做。迁移到 Java 27，上述特性全部默认开启；即使不迁移——现实中大多数人不会——它们也会在下一个 LTS Java 29（一年后发布）中默认启用。

但真正的大事其实是 Java 28。它将在三月发布，届时 Valhalla 的 value class 将作为预览特性正式集成进 JDK 28——这是 Java 承诺了十多年的东西。那将是另一个值得单独展开的话题。

一个耐人寻味的观察是：人们总说 Java 落后，但如今 Java 却在为几十年后的量子威胁未雨绸缪。这一点，得给 Java 记上一分。