JDK 27候选版落地：9项新特性，G1垃圾回收器全面转正

甲骨文Java平台组首席架构师Mark Reinhold近日宣布，JDK 27已进入首个发布候选版阶段。作为JDK 25发布后的第二个非LTS版本，JDK 27的功能集已由主干源代码库锁定（该库于2026年6月初分叉至稳定版本库，即Rampdown第一阶段）。目前，严重缺陷仍可通过修复请求流程审批后修复，但整体功能已冻结。按发布计划，JDK 27将于2026年9月15日正式面世。

本次最终确定的九项新特性（以JEP形式呈现）可归为四大类：核心Java库、HotSpot、安全库和Java语言规范。其中，核心Java库占三项，HotSpot占三项，安全库占两项，Java语言规范占一项。这些特性分别隶属于Amber、Loom、Panama、Valhalla和Leyden等主要Java项目，这些项目旨在孵化组件，并最终通过筛选合并流程纳入JDK。

HotSpot三项调整：G1转正、紧凑对象头、JFR数据屏蔽

HotSpot类别中的三项新特性值得重点关注。JEP 523提议将“垃圾优先”垃圾回收器（G1 GC）设为“所有环境中的默认选项，而不仅仅是服务器环境”。这意味着，如果命令行中未指定垃圾回收器，HotSpot JVM将始终选择G1 GC，这一变化将影响所有Java应用的默认运行行为。

JEP 534则提议将JEP 519（紧凑对象头，已随JDK 25发布）设为HotSpot JVM中的默认对象头布局。这一调整旨在优化内存占用，对大规模部署场景可能带来显著的内存效率提升。此外，JEP 536提议增强JDK Flight Recorder（JFR），使其在记录完成前对敏感信息进行屏蔽，这些信息可能包括命令行参数、环境变量的初始值以及系统属性，对安全敏感型应用尤为重要。

Amber项目：基本类型模式匹配进入第五轮预览

在Java语言规范类别中，JEP 532（模式、instanceof和switch中的基本类型第五个预览版）是唯一入选的特性。此前，该特性已在JDK 23至JDK 26期间完成了四轮预览。本次第五轮预览包含两项变更：完善了无条件准确性定义，并在switch结构中应用了更严格的支配性检查。该特性通过允许在所有模式上下文中使用基本类型来增强模式匹配功能，并扩展instanceof和switch结构，使它们支持所有的基本类型。

这一演进对开发者意味着更灵活的类型匹配能力。过去，模式匹配主要面向引用类型，基本类型（如int、long等）的支持一直受限。随着预览轮次的推进，这一能力正在逐步成熟，但距离正式定稿仍需时间——从预览到最终确定，通常需要多轮反馈和调整。

Loom项目：结构化并发第七轮预览，简化并发编程

JEP 533（结构化并发第七个预览版）提出进行第七轮预览，包含一些细微调整。此前，该项目已在JDK 21至JDK 26期间进行了六轮预览，并在JDK 19至JDK 20期间进行了两轮孵化。该功能通过引入结构化并发来简化并发编程，旨在“将运行在不同线程中的相关任务组视为单个工作单元，从而简化错误处理和取消操作，提高可靠性，并增强可观察性。”

结构化并发的核心价值在于，它改变了传统并发编程中任务管理分散、错误处理复杂的局面。开发者可以将一组相关任务作为一个整体来管理，统一处理取消和异常，这在实际项目中能显著降低并发代码的复杂度。不过，连续七轮预览也说明该特性在API设计和行为细节上仍在持续打磨。

Panama项目：向量API第十二轮孵化，等待Valhalla关键依赖

JEP 537（向量API第十二轮孵化）提议启动第十二轮孵化。该功能已历经十一轮孵化（从JDK 16到JDK 26），且其实现自JDK 25以来未发生实质性变化。该功能引入了一套API，用于“表达向量计算，而这些计算可以在运行时可靠地编译为受支持CPU架构上的最优向量指令，从而实现优于等效标量计算的性能。”

值得关注的是，向量API将继续处于孵化阶段，直至Valhalla项目中的必要功能作为预览功能发布。届时，向量API团队将调整API及其实现以支持这些功能，并将向量API从“孵化”阶段提升至“预览”阶段。这意味着，向量API的最终定稿与Valhalla项目的进展深度绑定，短期内不会转正。

安全库：PEM编码第三轮预览，TLS 1.3后量子混合密钥交换

安全库类别包含两项新特性。JEP 538（加密对象PEM编码第三个预览版）在JDK 25和JDK 26中经历了两轮预览后，提出进行第三轮预览。该功能提供“一个API，用于将表示加密密钥、证书和证书撤销列表的对象编码为广泛使用的增强隐私邮件（PEM）传输格式，并从该格式解码回对象”。本轮变更包括：将PEM记录类重新分类为普通类，以便提供构造函数接受字节数组中Base64编码内容；将DEREncodable接口重命名为BinaryEncodable，以更准确地描述PEM文本中存储的二进制数据。

另一项安全特性是JEP 527（TLS 1.3后量子混合密钥交换）。随着量子计算的发展，传统加密算法面临潜在威胁，后量子混合密钥交换旨在提前布局，确保TLS 1.3连接在量子计算时代仍具备安全性。这一特性对金融、政务等高安全需求场景具有前瞻性意义。

JDK 28前瞻：六项JEP已定，JSON API与值对象在列

JDK 28计划于2027年3月发布GA版本，届时将包含六项JEP（其中五项为Targeted状态，一项为Proposed to Target状态）。已确定的目标包括：JEP 541（废弃macOS/x64移植版以备移除）、JEP 540（简单JSON API第一个孵化版）、JEP 539（JVM中严格字段初始化预览版）、JEP 535（Shenandoah垃圾回收器默认启用分代模式）、JEP 401（值对象预览版）以及JEP 542（加密对象PEM编码最终定稿）。

其中，JEP 540（简单JSON API）值得开发者特别关注。该JEP定义了一个简单的标准API，用于解析和生成JSON文档，无需依赖外部库，实现了RFC 8259（JSON数据交换格式）。这一提案取代了已关闭并撤回的JEP 198（轻量级JSON API），意味着Java生态将迎来官方原生的JSON处理方案，有望减少对Jackson、Gson等第三方库的依赖。

JEP 401（值对象预览版）同样值得关注。该JEP此前名为“对象类与值预览版”，提议通过值对象增强语言功能。值对象被定义为：仅包含final字段、不具有身份标识、对象之间仅能通过各自字段的值来区分。这一特性与Valhalla项目的长期目标一致，可能对Java的内存布局和性能模型产生深远影响。

此外，JEP 535（Shenandoah垃圾回收器默认启用分代模式）将改变Shenandoah GC的默认行为，非分代模式将被标记为已弃用，并计划在未来版本中移除。JEP 541（废弃macOS/x64移植版）则反映了苹果公司已不再支持该架构的现实，此举旨在通过在未来版本中移除该移植版本来节省维护成本，与之前废弃Windows 32位x86移植版的逻辑类似。

整体来看，JDK 27的九项新特性以渐进式优化为主，没有颠覆性的语言变革，但G1垃圾回收器全面转正、紧凑对象头默认化等调整，将在运行层面带来实际影响。而JDK 28的规划中，JSON API和值对象等特性则更具想象空间。对于Java开发者而言，关注这些预览和孵化特性的演进方向，有助于提前布局技术栈的升级路径。