JDK 24：Java 24 中的新特性

Java 开发工具包 (JDK) 24现处于初始缩减阶段，功能集冻结为 24 个功能，从类文件 API 到结构化并发的第四个预览版。

JDK 24 于 12 月 5 日进入了缩减阶段。它将于 2025 年 3 月 18 日发布生产版本。JDK 24 拥有二十多个特性，远远超过了前身JDK 23，后者于 9 月 17 日发布，带有 12 个官方新特性。

最新添加的五项内容包括在中使用内存访问方法的警告sun.misc.unsafe、结构化并发的第四个预览、弃用并删除 32 位 x86 端口，以及通过提供基于抗量子模块格子的数字签名算法和基于抗量子模块格子的密钥封装机制的 Java 实现来提高 Java 对量子计算攻击的抵抗力。

先前提出的功能包括灵活的构造函数主体；提前类加载和链接；删除 Windows 32 位 x86 端口；同步虚拟线程而不固定；简单的源文件和实例主方法；永久禁用安全管理器；模块导入声明；紧凑对象头的实验版本；模式、instanceof和中的原始类型switch；链接没有 JMOD 的运行时图像；分代 Shenandoah 垃圾收集器；范围值；密钥派生函数 API；删除 Z 垃圾收集器中的非分代模式；流收集器；矢量 API；类文件 API；警告，以便开发人员为未来使用 JNI （Java 本机接口）的限制做好准备；以及 G1 垃圾收集器的后期屏障扩展。

JDK 24 已被指定为非长期支持 (LTS) 版本。（当前 LTS 版本是JDK 21，将于 2023 年 9 月发布。）与 JDK 23 一样，JDK 24 也将仅获得 Oracle 六个月的顶级支持。JDK 24 的早期访问版本可在jdk.java.net上找到。JDK 24 计划于明年 9 月发布下一个 LTS 版本 JDK 25。

在使用 中的内存访问方法时sun.misc.Unsafe发出警告，Java 会在运行时首次调用 中的任何内存访问方法时发出警告。所有这些不受支持的方法在 JDK 23 中都被彻底弃用，并已被标准 API 取代。创建 类是为了为 Java 类提供一种执行低级操作的机制。它的大多数方法都用于访问内存，无论是在 JVM 的垃圾收集堆中还是在堆外内存中，这些内存不受 JVM 控制。正如类名所示，这些内存访问方法是不安全的。 sun.misc.unsafe sun.misc.Unsafe

结构化并发，再次预览，旨在通过引入结构化并发 API 来简化并发编程。借助结构化并发概念，在不同线程中运行的相关任务组被视为单个工作单元，从而简化错误处理和取消，提高可靠性并增强可观察性。目标是推广一种并发编程风格，可以消除因取消和关闭而产生的常见任务，例如线程泄漏和取消延迟。提高并发代码的可观察性也是一个目标。

弃用 32 位 x86 端口并删除，这是在弃用 Windows 32 位 x86 端口的提议之后做出的（见下文），这将弃用 Linux 32 位 x86 端口，这是 JDK 中剩余的唯一 32 位 x86 端口。它还将有效弃用任何剩余的下游 32 位 x86 端口。在删除 32 位 x86 端口后，与架构无关的零端口将成为在 32 位 x86 处理器上运行 Java 程序的唯一方法。在 JDK 24 中弃用 32 位 x86 端口将允许在 JDK 25 中将其删除。

为通过抗量子性提高 Java 安全性而提出的两个功能包括抗量子的基于模块格的密钥封装机制(ML-KEM) 和抗量子的基于模块格的数字签名算法(ML-DSA)。ML-DSA 将使用数字签名来检测对数据的未经授权的修改并验证签名者的身份，从而防止未来的量子计算攻击。密钥封装机制 (KEM) 用于使用公钥加密技术通过不安全的通信通道保护对称密钥。这两个功能都旨在防止未来的量子计算攻击。

灵活的构造函数体在JDK 22和JDK 23中首次亮相后，目前已进入第三个预览版，尽管在 JDK 22 中该功能的名称有所不同，之前称为语句super(...)。该功能旨在重新构想构造函数在对象初始化过程中的作用，让开发人员更自然地将他们当前必须考虑的逻辑放入辅助静态方法、辅助中间构造函数或构造函数参数中。该提案在构造函数体中引入了两个不同的阶段：序言包含在调用超类构造函数之前执行的代码，而结语在调用超类构造函数之后执行。该功能还将保留现有的保证，即子类构造函数中的代码不能干扰超类的实例化。

提前类加载和链接旨在缩短启动时间，方法是在 HotSpot Java 虚拟机启动时，使应用程序的类立即处于加载和链接状态。这将通过在一次运行期间监视应用程序并将所有类的加载和链接形式存储在缓存中以供后续运行使用来实现。

Windows 32 位 x86 端口已弃用，将在 JDK 21 中删除，目的是在未来版本中将其删除。计划要求删除源代码并构建对 Windows 32 位 x86 端口的支持。目标包括删除仅适用于 Windows 32 位 x86 的所有代码路径，停止针对 Windows 32 位 x86 平台的所有测试和开发工作，并简化 JDK 的构建和测试基础架构。该提案指出，Windows 10 是支持 32 位操作的最后一款 Windows 操作系统，将于2025 年 10 月终止其使用寿命。

同步虚拟线程而不固定涉及提高使用同步方法和语句的 Java 代码的可扩展性，方法是安排在此类构造中阻塞的虚拟线程释放其底层平台以供其他线程使用。这将消除几乎所有虚拟线程被固定到平台线程的情况，这严重限制了可用于处理应用程序工作负载的虚拟线程数量。

简单源文件和实例主方法的第四个预览将改进 Java 语言，以便初学者可以编写他们的第一个程序，而无需了解为大型程序设计的语言功能。该功能之前已在JDK 21、JDK 22和JDK 23中预览过。目标是允许初级 Java 程序员为单类程序编写精简的声明，然后随着技能的增长无缝扩展他们的程序以使用更高级的功能。

永久禁用安全管理器需要修改 Java 平台规范，以便开发人员无法启用安全管理器，而其他平台类则不会引用它。提案指出，多年来，安全管理器一直不是保护客户端 Java 代码的主要手段，很少用于保护服务器端代码，而且维护成本高昂。安全管理器已在 Java 17 中被弃用并被删除。

模块导入声明（之前已在 JDK 23 中预览）增强了 Java 编程语言，使其能够简洁地导入模块导出的所有包。这简化了模块库的重用，但不需要将代码导入为模块本身。

紧凑对象头会将 HotSpot VM 中的对象头大小从 96 到 128 位减少到 64 位架构上的 64 位。提议的功能的目标是减少堆大小、提高部署密度并增加数据局部性。

JDK 24 中模式、 instanceof和switch中原始类型的第二个预览将通过允许在所有模式和上下文中使用原始类型来增强模式匹配。该功能还将扩展instanceof并switch适用于所有原始类型。该功能的目标包括通过允许所有类型（无论是原始类型还是引用类型）的类型模式实现统一的数据探索；使类型instanceof与instanceof安全转换对齐；并允许模式匹配在嵌套和顶级模式上下文中使用原始类型。其他目标包括提供易于使用的构造，以消除由于不安全的转换而丢失信息的风险，遵循switch Java 5 和 Java 7 中的增强功能，并允许switch处理任何原始类型的值。此功能之前已在 JDK 23 中预览过。

通过链接不使用 JMOD 的运行时映像，计划通过启用jlink工具来创建不使用 JDK JMOD文件的自定义运行时映像，将 JDK 的大小减少约 25%。此功能必须默认启用，某些 JDK 供应商可能选择不启用它。目标包括允许用户从模块链接运行时映像，而不管这些模块是独立的 JMOD 文件、模块化 JAR 文件还是先前链接的运行时映像的一部分。提出该提案的动机是，在云环境中，文件系统上安装的 JDK 的大小非常重要，因为包含已安装 JDK 的容器映像会通过网络自动且频繁地从容器注册表复制。减小 JDK 的大小将提高这些操作的效率。

分代 Shenandoah将通过实验性的分代收集功能增强垃圾收集器，以提高可持续吞吐量、负载峰值抵抗力和内存利用率。主要目标是提供一种实验性的分代模式，而不会破坏非分代 Shenandoah。分代模式旨在成为未来版本中的默认模式。

范围值使方法能够与线程内的调用方和子线程共享不可变数据。范围值比本地线程变量更容易推理。它们还具有较低的空间和时间成本，特别是与虚拟线程和结构化并发一起使用时。范围值 API 是在JDK 20中提出的孵化版，在JDK 21中提出的预览版，并针对JDK 22和JDK 23进行了改进和完善。范围值将在 JDK 24 中预览。

借助密钥派生函数 (KDF) API，将引入用于密钥派生函数的 API，这些函数是用于从密钥和其他数据派生其他密钥的加密算法。此提案的目标是允许安全提供商以 Java 代码或本机代码实现 KDF 算法。另一个目标是使应用程序能够使用 KDF 算法，例如基于 HMAC（哈希消息认证码）的提取和扩展密钥派生函数 ( RFC 5869 ) 和 Argon2 ( RFC 9106 )。

删除 Z 垃圾收集器 (ZGC) 的非分代模式是一项旨在降低支持两种不同模式的维护成本的提案。该提案指出，维护非分代 ZGC 会减慢新功能的开发速度，而对于大多数用例而言，分代 ZGC 应该是比非分代 ZGC 更好的解决方案。后者最终应该被前者取代，以降低长期维护成本。该计划要求通过淘汰 ZGenerational 选项并删除非分代 ZGC 代码及其测试来删除非分代模式。非分代模式将在未来的版本中过期，届时它将不会被 HotSpot JVM 识别，从而拒绝启动。

流收集器将增强流 API，以支持自定义中间操作。流收集器允许流管道以现有内置中间操作无法轻易实现的方式转换数据。此功能在JDK 22和JDK 23中作为预览版提出。该 API 将在 JDK 24 中最终确定。目标包括使流管道更加灵活和富有表现力，并允许自定义中间操作来操作无限大小的流。

向量API旨在表达向量通信，这些通信在运行时可靠地编译为受支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。向量 API 之前在JDK 16到JDK 23中孵化。它将在 JDK 24 中重新孵化，没有任何 API 变化，也没有相对于 JDK 23 的实质性实现。该提案的目标包括用与平台无关的 API 清晰简洁地表达各种向量计算，在 x64 和 AArch54 架构上提供可靠的运行时编译和性能，当无法在运行时表达向量计算时可以优雅地降级并仍然运行，并与Project Valhalla保持一致，利用对 Java 对象模型的增强功能。

之前在 JDK 22 和 JDK 23 中预览过的类文件 API将 在 JDK 24 中最终确定，但会略有改动。此 API 提供了一个用于解析、生成和转换 Java 类文件的标准 API。其目的是提供一个用于处理类文件的 API，该 API 跟踪 Java 虚拟机规范定义的类文件格式。第二个目标是使 JDK 组件能够迁移到标准 API，并最终删除 JDK 内部的第三方ASM 库副本。自第二个预览版以来的更改包括重命名枚举值、删除某些字段、添加方法和方法重载、重命名方法以及删除被认为不必要的接口和方法。

G1 垃圾收集器的后期屏障扩展旨在简化 G1 屏障的实现。G1 垃圾收集器的屏障通过将其扩展从 C2 编译管道的早期移到后期来记录有关应用程序内存访问的信息。目标包括减少使用 G1 收集器时 C2 编译的执行时间，使对 C2 缺乏深入了解的 HotSpot 开发人员能够理解 G1 屏障，并确保 C2 保留有关内存访问、安全点和屏障的相对顺序的不变量。第四个功能是保留 C2 生成的 JIT（即时）编译代码的质量（速度和大小）。

第一个针对 JDK 24 的功能，正式名称为“准备限制使用 JNI ”，要求发出有关使用 JNI 的警告，并调整JDK 22 中的外部函数和内存 (FFM) API，以一致的方式发出警告。这些警告旨在为未来版本做准备，通过统一限制 JNI 和 FFM API，默认情况下确保完整性。该计划的目标包括将 JNI 保留为与本机代码互操作的标准方式，为默认情况下不允许与本机代码互操作的未来版本准备 Java 生态系统，并协调 JNI 和 FFM API 的使用，以便库维护者可以从一个迁移到另一个，而无需开发人员更改命令行选项。

最新的 LTS 版本 JDK 21 于 2023 年 9 月发布，预计将获得 Oracle 至少五年的 Premier 支持。下一个 LTS 版本 JDK 25 将于 2025 年 9 月发布。LTS版本主导了 Java 的采用，这意味着在用户等待 JDK 25 时，JDK 23 和 JDK 24 的采用率可能会较低。

https://openjdk.org/projects/jdk/24/