Java 27 正式发布：紧凑对象头转正，每个对象省 4 字节

2026 年 9 月 15 日，JDK 27 正式 GA（General Availability）。按照 Oracle 公布的路线图，下一个 LTS 版本是 2027 年 9 月的 Java 29，中间这两个非 LTS 版本承担的任务是把一批实验特性推向成熟。Java 27 交出的成绩单是 9 个 JEP（JDK Enhancement Proposal），其中 4 个正式特性、4 个预览、1 个孵化器，重点落在了三个方向：运行时性能、后量子安全、并发模型演进。

对象头瘦身：一次「不加代码」的内存优化

四个正式特性里，对存量应用影响最直接的是 JEP 534（紧凑对象头默认启用）和 JEP 523（G1 成为所有环境下的默认垃圾回收器）。

先看 JEP 534。在 64 位 JVM 上，每个 Java 对象都带一段对象头（object header），传统布局占 96 位，也就是 12 字节，里面装着标记字（mark word）和类指针（klass pointer）。JDK 24 引入的紧凑布局（JEP 450）把这两段信息压进一个 64 位机器字，对象头直接减半到 8 字节。

单个对象省 4 字节听起来微不足道，但 Java 应用里对象数量动辄以亿计。一个存放 1000 万个小对象的系统，仅对象头就能省出约 38 MB 堆内存。更实际的收益是缓存局部性：对象变小之后，同一条 64 字节缓存行能装下更多对象，指针压缩的覆盖面也随之扩大。

JEP 534 给出的实测数据（来自 JEP 450/519 两轮实验的积累）：

JEP 534 的原始 JEP 页面明确记录了这项特性的生产验证路径：Oracle 跑完了完整的 JDK 测试套件；Amazon 有数百个生产服务在紧凑对象头上运行，其中大部分是通过向 JDK 17 和 JDK 21 回移植的方式运行的；SAP 已经在自己的下游发行版 SapMachine 里默认开启了紧凑对象头，每天跑大规模测试。换句话讲，这个「默认开启」建立在已经被超大规模用户验证过的配置之上。

对开发者的实际操作变化是：JDK 25 里需要手动加 -XX:+UseCompactObjectHeaders，JDK 27 起默认生效，出问题时可以用 -XX:-UseCompactObjectHeaders 关掉回退。JEP 534 同时预留了 4 个位给 Project Valhalla 的值类型（value object），后续语言特性不会因为对象头没有空位而卡住。

G1 全环境默认化（JEP 523）补上了另一处历史遗留：Java 9 把 G1 设为默认 GC 时，单 CPU 或内存不足 1792 MB 的机器仍会回退到 Serial GC。G1 经过 JEP 522（减少同步开销提升吞吐）等持续优化后，低配环境的性能差距已经抹平，这个例外被移除。对用户的意义是开发机、容器、生产集群的行为一致，-XX:+UseSerialGC 仍可显式启用 Serial。

后量子 TLS：默认就位的「先存后解」防御

JEP 527（TLS 1.3 后量子混合密钥交换）是安全方向的主特性，防御的是「harvest now, decrypt later」攻击：对手现在录制加密流量存起来，等量子计算机成熟后再解密。对预期保密周期以十年计的数据（医疗记录、金融档案、国家机密），这个威胁从今天抓包那一刻就已经成立。

技术上，JEP 527 在 TLS 1.3 握手里加入了三个混合密钥交换组，把传统椭圆曲线 ECDHE 与基于格的 ML-KEM 组合起来：

• X25519MLKEM768（X25519 + ML-KEM-768）
• SecP256r1MLKEM768（secp256r1 + ML-KEM-768）
• SecP384r1MLKEM1024（secp384r1 + ML-KEM-1024）

混合方案的设计逻辑是：只要组合中的任何一个算法没被攻破，会话就是安全的。ML-KEM 新、缺乏时间检验，传统 ECDHE 久经考验但挡不住量子攻击，两者绑定互相补位。

对应用层开发者的体验接近于零成本：JDK 的 TLS 1.3 客户端默认把 X25519MLKEM768 排在握手候选列表最前面，没有显式配置过 named groups 的存量代码升级 JDK 后自动获得抗量子握手，服务端不支持时自然回退传统算法。需要精细控制时，可以通过 jdk.tls.namedGroups 系统属性或 SSLParameters::setNamedGroups 调整。配套的 JEP 538（PEM 编码 third preview）让密钥、证书、CRL 能直接和 PEM 格式互转，与现有安全运维工具链的互操作更顺。

另一项安全特性 JEP 536（JFR 进程内数据脱敏）解决的是诊断数据的合规问题：JDK Flight Recorder 在录制数据离开进程之前，把命令行参数、环境变量和系统属性的初始值脱敏。排查生产问题的工程团队不再需要在「诊断数据够不够全」和「敏感信息会不会跟着 JFR 文件泄露」之间二选一。

预览梯队：语言与并发的下一步

9 个 JEP 里有 5 个还处在预览或孵化阶段，这个版本的语言层改动延续了几条主线。

JEP 532（模式匹配支持原始类型，第五次预览）让 instanceof 和 switch 的模式可以匹配 int、double 等全部原始类型，消除手工拆箱和范围判断里的隐患。下面是带守卫模式的 switch 写法：

int itemDiscountPercentage(int items) {
    return switch (items) {
        case 2 -> 5;
        case 3, 4 -> 10;
        case int i when i >= 5 -> 20;
        default -> 0;
    };
}

JEP 531（Lazy Constants，第三次预览）提供「求值时机延迟、结果不可变」的常量容器。final 字段在对象构造时必须立即赋值，Lazy Constants 把求值推迟到首次使用，对重型配置对象、缓存场景可以显著改善启动时间。这个 API 在 Java 25 以 Stable Values 之名首次引入，Java 26、27 连续两轮修订。

JEP 533（结构化并发，第七次预览）把一组相关联的并发任务当作一个工作单元处理，统一取消、统一报错、统一观测，消除线程泄漏和取消延迟。它与虚拟线程、Scoped Values 同属 Project Loom 的并发拼图。JEP 537（Vector API，第十二次孵化）继续等待 Project Valhalla 的值类型落地，API 本身这轮没有变化。

预览特性的机制值得了解：这些 API 默认关闭，需要加 --enable-preview 才能用，且只保证当前 JDK 版本可用。Java 27 的四个预览特性中，模式匹配原始类型与 Java 26 相比没有变化，Lazy Constants 和结构化并发的 API 有修订。生产系统真正吃进这些特性，一般要等转正之后。

升级建议与生态现状

升级路径按场景区分：

• 追求内存收益的服务：升级后直接受益，重点回归 GC 行为和内存指标，个别依赖旧对象头布局的工具（如某些堆分析、字节码增强框架）需要确认兼容性。
• TLS 消费方：存量代码不用动；显式配置过 named groups 的客户端需要手动把混合组加进列表。
• 观望派：等 Java 29 LTS 再统一升级是常见策略，Java 27 的默认化改动（对象头、G1）届时会原样带进 LTS，现在在测试环境先跑一遍是低成本的风险前置。

工具链已经就位：JetBrains 在发布当天宣布 IntelliJ IDEA 完整支持 Java 27，新语言级别为「27 - No new language features」（Java 27 没有新增正式语言特性，改动集中在运行时和库层），预览特性切换到「27 (Preview)」级别。JetBrains 自家 IDE 已经吃上了紧凑对象头，官方博客确认观察到一致的内存节省。另一条值得关注的消息是 IntelliJ IDEA 的 Java 与 Kotlin 智能支持正在通过 LSP 开放给 VS Code、Cursor 和各类 Agent 工作流，JDK 27 的完整支持会同步出现在这些编辑器里。

前瞻方面，Oracle 在发布通告里把 JDK 28 EA 的 Project Valhalla 作为重点预告：值对象（JEP 401）与 JVM 层严格字段初始化（JEP 539）已 target 到 JDK 28，Valhalla 第一次以预览形态进入主线 JDK，不再需要专门的发行版。Project Leyden（启动时间与 AOT 编译）也在同步推进。对象头里预留的 4 个 Valhalla 位、Vector API 对值类型的等待，在这个版本里已经能看到几条线汇合的趋势：Java 平台这几年最大的语言层变革正在逼近。

来源：OpenJDK JDK 27 项目页 · Oracle 官方通告 · JEP 534 · JEP 527 · JetBrains 官方博客 · Java Version Almanac