21CTO导读：Java 27 正式发布，“G1”成为正式垃圾回收器，支持后量子密钥技术，还有一些全新或增强的特性，来，我们先睹为快。

开发者可在此处下载 OpenJDK 27：

https://jdk.java.net/27/

接下来，我们将探讨 Java 27 的新特性，重点关注已正式发布的 JEP 及其对 Java 应用开发的影响。

使用 javax.net.ssl API 的应用默认受益，无需修改现有代码。新增算法包括 X25519MLKEM768、SecP256r1MLKEM768 和 SecP384r1MLKEM1024。

其中 X25519MLKEM768 被放在默认命名组列表最前，成为最优先组。JEP 538 第三次预览引入 PEM 编码 API，可编解码密钥、证书和证书吊销列表。

JVM

JEP 523：将 G1 设置为所有环境中的默认垃圾回收器

（https://openjdk.org/jeps/523）

自 Java 9 起，G1 一直是 Java 的默认垃圾回收器，但并非所有地方都如此。在 Java 26 之前，HotSpot JVM 在资源受限的环境中（例如只有一个 CPU 或物理内存小于 1792 MB）运行时，会自动切换到串行 GC。

当 G1 被引入为默认垃圾回收机制时，这种行为是合理的。串行垃圾回收的实现非常简单，并且在资源有限的机器上，历来都能提供更高的吞吐量和更小的内存占用。

然而，自 Java 9 以来，G1 已经发生了显著变化。它的本地内存占用量有所减少，并且最近的改进逐步缩小了与串行 GC 的吞吐量差距。在 Java 26 中，JEP 522 通过引入第二个卡片表，显著消除了 G1 写屏障的同步开销，从而大幅提升了吞吐量。

随着 JEP 523 的发布，Java 27 完成了这一演变：无论可用 CPU 或物理内存的数量如何，G1 现在都是每个环境中的默认垃圾回收器。

串行垃圾回收机制不会被移除。能够从中受益的应用程序仍然可以显式地选择它：

java -XX:+UseSerialGC -jar application.jar

同样，已经明确选择 G1、ZGC、Parallel GC、Shenandoah 或其他可用垃圾回收器的应用程序不受影响。

JEP 534：默认压缩对象头

（https://openjdk.org/jeps/534）

JEP 534 将紧凑对象头作为 64 位 HotSpot JVM 中的默认对象头布局。

紧凑对象头是Lilliput 项目的一部分，该项目的目标是通过将 Java 对象的头从 96 位缩小到 64 位（在 64 位架构上），来减少 Java 对象的内存占用。

在 Java 27 之前，必须显式启用紧凑对象头：

java -XX:+UseCompactObjectHeaders -jar application.jar

从 Java 27 开始，无需任何操作：

java -jar application.jar

JVM 会自动使用紧凑布局。

需要回退到旧版对象头布局的应用程序仍然可以显式禁用此功能：

java -XX:-UseCompactObjectHeaders -jar application.jar

JEP 536：JFR 过程中的数据脱敏

https://openjdk.org/jeps/536

JDK Flight Recorder (JFR) 是目前可用于诊断生产环境中 Java 应用程序的最有用工具之一。它能够以相对较低的开销记录 CPU 使用率、垃圾回收、线程、内存分配、锁、I/O 以及许多其他 JVM 事件的信息。

但是，JFR 记录还可以包含有关JVM 如何启动和配置的信息，包括命令行参数、环境变量和系统属性。

这可能会造成安全问题，因为这些值可能包含敏感信息，例如密码、API 密钥、访问令牌或凭证。

例如，想象一下这样启动一个应用程序：

$ export ACCESS_TOKEN=SECRET_TOKEN $ java -XX:StartFlightRecording:filename=dump.jfr \        -Xmx2G \        -Djavax.net.ssl.keyStorePassword=SECRET_PASSWORD \        -jar application.jar \       --dbpassword ANOTHER_SECRET_PASSWORD

jdk.InitialEnvironmentVariable在 Java 27 之前，这些敏感值可以通过诸如`java.java`、` jdk.InitialSystemPropertyjava.java` 和 `java.java`之类的事件直接出现在 JFR 记录中jdk.JVMInformation。

当.jfr文件与其他开发人员共享、附加到支持工单或上传到外部系统进行分析时，这个问题就变得尤为突出。

JEP 536 通过引入过程内数据脱敏来解决这个问题。

JFR 现在不会将敏感信息写入录音，而是在将敏感值写入录音之前对其进行识别和编辑。

Java 27 为以下两个新子选项引入了：-XX:FlightRecorderOptions编辑键与编辑参数。

redact-key用于识别敏感环境变量和系统属性，而redact-argument适用于命令行参数。

JFR为命令行参数和键值对（例如环境变量和系统属性）提供了默认的密文过滤器。

如果既未指定redact-key也未redact-argument指定，则会自动使用这些内置过滤器。它们涵盖常见的敏感术语，例如密码、密钥、令牌、凭证、私钥、API 密钥和客户端密钥。

语言更新

JEP 532：模式、instanceof 和 switch 中的原始类型（第五次预览）

https://openjdk.org/jeps/532

JEP 532 继续推进 Java 模式匹配扩展到原始类型的工作。

此前，模式匹配主要与引用类型相关联。此功能允许基本类型也参与模式匹配。

例如：

int value = 100;if(value instanceof byte b) {	System.out.println("一个字节可以容纳："+ b);}

只有当转换完全准确时，模式才匹配，也就是说，不会丢失任何信息。例如，` \ 100sigma ...byte1000

该特性还扩展switch到支持所有基本类型，包括long、float、double和boolean：

long value = 42L;String result = switch (value) {case 0L->"zero";case 42L->"the answer";default->"other";};

原始图案也可以直接用于case标签中：

object value = 42；switch(value) {   case byte b -> System.out.println( "byte: " + b);   case int i -> System.out.println( "int: " + i);   default-> System.out.println( "other"); }

JEP 532 是该功能的第五个预览版，之前已有 JEP 455、488、507 和 530 版。

Java 27与 Java 26 相比没有引入任何语言变化；该功能仍处于预览阶段，以便在最终确定之前收集更多反馈。

API

JEP 527：TLS 1.3 的后量子混合密钥交换

JEP 527 通过引入混合密钥交换算法来增强 TLS 1.3 抵御未来量子计算攻击的能力。

其思路是将传统的椭圆曲线算法与后量子时代的ML-KEM算法相结合。这可以防范“先捕获后解密”的威胁，即加密流量今天被捕获，未来可能使用量子计算机进行解密。

Java 27 引入了三种混合方案：

• X25519MLKEM768 
  

• SecP256r1MLKEM768 
  

• SecP384r1MLKEM1024

X25519MLKEM768默认情况下， X25519 和 ML-KEM-768的组合协议已启用。因此，只要不覆盖默认的 TLS 命名组，使用标准 API 的应用程序无需更改代码javax.net.ssl即可受益于后量子保护。

支持的组仍然可以使用jdk.tls.namedGroups或进行自定义SSLParameters#setNamedGroups。

因此，JEP 527 使 Java 应用程序默认情况下更易于后量子时代部署，同时保持与现有 TLS 基础架构的兼容性。

JEP 531：惰性常量（第三次预览）

惰性常量提供了一种简单的方法，可以在首次需要时初始化一个值，同时仍然允许 JVM 将该值视为真正的常量并应用诸如常量折叠之类的优化。

例子：

static final LazyConstant LOGGER = LazyConstant.of(Logger::create); Logger logger = LOGGER.get();

get()只会在首次调用时以线程安全的方式评估一次。

与之前的预览版相比，Java 27 主要带来了两项变化：

• isInitialized()并被orElse()移除。
• Set.ofLazy(...)除了现有的 lazyList和Map支持之外，还扩展了 lazy 集合。

注意，JEP 531在 Java 27 中仍然是预览版 API 。

JEP 533：结构化并发（第七次预览）

结构化并发将一组相关的并发任务视为一个单一的工作单元，从而简化了取消、错误处理和可观察性。

使用该方法StructuredTaskScope，子任务会在明确定义的范围内进行分支和合并：

try( var scope = StructuredTaskScope.open()) {   var user = scope.fork(() -> fetchUser());   var orders = scope.fork(() -> fetchOrders());   scope.join();   return new Response(user.get(), orders.get()); }

Java 27 主要改进了异常处理，StructuredTaskScope现在可以Joiner指定要抛出的异常类型join()，从而在编译时明确定义异常类型。

allSuccessfulOrThrow() anySuccessfulOrThrow() awaitAllSuccessfulOrThrow()

现在，导致join()抛出熟悉的异常ExecutionException而不是预览特有的异常FailedException。Joiner.awaitAll()此外，该异常也被移除。

同样地，JEP 533在 Java 27 中仍然是预览版 API 。

JEP 537：载体 API（第十二个孵化版本）

Vector API 允许开发人员直接在 Java 中表达SIMD 计算，使 JVM 能够将其编译成优化的向量 CPU 指令，例如 AVX 或 NEON。

例如：

var va = FloatVector.fromArray(SPECIES, a, 0); var vb = FloatVector.fromArray(SPECIES, b, 0); var result = va.mul(vb).add(va);

CPU 可以使用向量寄存器并行处理多个值，而不是一次处理一个值。

JEP 537 是API 的第十二次迭代，与最近的版本相比，没有引入任何实质性的实现变更。

Vector API 目前仍处于孵化阶段，等待Project Valhalla 的必要功能上线。一旦这些功能可用，该 API 预计将从孵化阶段过渡到预览阶段。

JEP 538：加密对象的 PEM 编码（第三次预览版本）

JEP 538 提供了一个标准的 Java API，用于对 PEM 格式的加密密钥、证书和 CRL 进行编码和解码，避免手动 Base64 解析和格式化。

该 API 主要围绕PEMEncoder以下两点构建PEMDecoder：

String pem = PEMEncoder.of().encodeToString(publicKey); PublicKey key = PEMDecoder.of().decode(pem, PublicKey.class);

私钥也可以通过 API 直接加密和解密。

与 Java 26 相比，主要变化如下：

• DEREncodable更名为BinaryEncodable。
• PEM现在它已成为常规课程，而不是记录课程。
• EncryptedPrivateKeyInfo获得支持以检索KeyPair。
• 新的CryptoException表示加密处理失败。
  

需要说明的，JEP 538在 Java 27 中仍然是预览版 API 。

后续版本

Oracle 表示，JDK 27 是六个月发布节奏下按时交付的第 18 个特性版本。Oracle 将为 JDK 27 提供更新至 2027 年 3 月，随后由 Oracle JDK 28 接替。

配套产品方面，Helidon 27、JavaFX 27 同步更新。Oracle Java Platform Extension for Visual Studio Code 继续支持最新 JDK 和早期访问构建。

Oracle Jipher 20 已纳入 Java Verified Portfolio，封装通过 FIPS 140-3 验证的 OpenSSL 加密模块，并支持 ML-KEM、ML-DSA 等。

OCI 成为首个支持 Oracle JDK 27 的云提供商。Oracle Java SE Universal Subscription 现包含 Java Verified Portfolio。

另外，OpenJDK 社区贡献者来自阿里巴巴、亚马逊、ARM、谷歌、IBM、微软、英伟达、红帽、SAP 等企业，独立开发者贡献了 16% 的修复。

来自业界的评论声音

针对于Java 27的发布，IDC软件开发研究副总裁 Arnal Dayaratna 这样表示道：

“Java的安全性、可靠性和企业级扩展性使其成为人工智能代理的关键基础，这些代理需要可信地访问业务系统和敏感数据。Java 27的人工智能开发工具和后量子密码技术进一步巩固了其在企业应用开发中的核心地位，并帮助企业为新一代应用和智能体时代的安全威胁做好准备。”

“三十多年来，Java 一直致力于帮助开发者构建强大、可靠且安全的应用程序，”Oracle Java 平台高级副总裁兼 OpenJDK 管理委员会主席 Georges Saab 表示。

“Java 27 延续了这一优良传统，为当今的企业工作负载以及创新的 AI 和后量子密码学功能提供了稳定的基础。Java 27 的发布标志着后量子密码学发展的一个重要里程碑，Oracle 正在按计划推进，将类似的功能引入到 JDK 版本中，并提供 Oracle 的长期支持。这将帮助客户以更少的中断保护业务关键型应用程序和数据。

结语

我们可以看到，Java 27 稳步推进了平台发展，重点关注性能、内存效率、安全性和开发人员生产力。

此版本默认提供多项重要改进，包括紧凑对象标头、在所有环境中将 G1 作为默认垃圾回收器、更强大的后量子 TLS 安全性以及更安全的JFR 记录。

与此同时，结构化并发、惰性常量、原始模式、PEM API 和 Vector API 等功能也在通过预览和孵化不断完善。

Java 27 虽然不是 LTS 版本，但它清楚地表明了该平台的发展方向：更高效的 JVM、更强大的安全默认设置以及更简单的现代 Java 应用程序编程模型。

作者：场长