Java 24（Oracle JDK 24）正式发布，全网最全的新特性速览。Java 8 骨灰级程序员前来报道！

本文由 #公众号：一个正经的程序员 原创 作者：散淡样子 GitHub：

00、前言

Java 24（Oracle JDK 24）已于 2025 年 3 月 18 日正式发布，包含 24 项功能。作为标准 Java 的短期支持版本，JDK 24 将仅获得 Oracle 六个月的Premier 级支持，而长期支持 (LTS) 版本将获得至少五年的 Premier 级支持。作为 JDK 21 以来的第三个非 LTS 版本，也是六个月周期开始以来的第 15 个版本，同时具有 24 个功能，远远超过于 2024 年 9 月 17 日发布的具有 12 个功能的 JDK 23。

01、功能预览

此次最终功能集中的 24 个 JEP 包括：

1. JEP 404：分代 Shenandoah（实验性）
2. JEP 450：紧凑对象标头（实验性）
3. JEP 472：准备限制 JNI 的使用
4. JEP 475： G1 的 Late Barrier 扩展
5. JEP 478：密钥派生函数 API（预览）
6. JEP 479：删除 Windows 32 位 x86 端口
7. JEP 483：提前类加载和链接
8. JEP 484：类文件 API
9. JEP 485：流收集器
10. JEP 486：永久禁用安全管理器
11. JEP 487：范围值（第四个预览版）
12. JEP 488：模式中的原始类型、instanceof 和 switch（第二个预览）
13. JEP 489：向量 API（第九个孵化器）
14. JEP 490：ZGC：删除非分代模式
15. JEP 491：无需固定即可同步虚拟线程
16. JEP 492：灵活的构造函数主体（第三次预览）
17. JEP 493：无需 JMOD 即可链接运行时图像
18. JEP 494：模块导入声明（第二预览版）
19. JEP 495：简单源文件和实例主要方法（第四个预览版）
20. JEP 496：基于抗量子模块格的密钥封装机制
21. JEP 497：基于模块格的抗量子数字签名算法
22. JEP 498：在 sun.misc.Unsafe 中使用内存访问方法时发出警告
23. JEP 499：结构化并发（第四个预览版）
24. JEP 501：弃用 32 位 x86 端口并将其删除

JDK 24 可在此处下载，计划于 9 月发布下一个 LTS 版本 JDK 25。

Java SE Development Kit 24 downloads /

懒的看功能详解的可以直接滑到底部参与投票！

02、功能详解

1. JEP 404：分代 Shenandoah（实验性）

JEP 404: Generational Shenandoah (Experimental)

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

2. JEP 450：紧凑对象标头（实验性）

JEP 450: Compact Object Headers (Experimental)

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

3. JEP 472：准备限制 JNI 的使用

JEP 472: Prepare to Restrict the Use of JNI

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

4. JEP 475： G1 的 Late Barrier 扩展

JEP 475: Late Barrier Expansion for G1

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

5. JEP 478：密钥派生函数 API（预览）

JEP 478: Key Derivation Function API (Preview)

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

6. JEP 479：删除 Windows 32 位 x86 端口

JEP 479: Remove the Windows 32-bit x86 Port

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

7. JEP 483：提前类加载和链接

JEP 483: Ahead-of-Time Class Loading & Linking

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

8. JEP 484：类文件 API

JEP 484: Class-File API

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

9. JEP 485：流收集器

JEP 485: Stream Gatherers

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

10. JEP 486：永久禁用安全管理器

JEP 486: Permanently Disable the Security Manager

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

11. JEP 487：范围值（第四个预览版）

JEP 487: Scoped Values (Fourth Preview)

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

12. JEP 488：模式中的原始类型、instanceof 和 switch（第二个预览）

JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)

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

13. JEP 489：向量 API（第九个孵化器）

JEP 489: Vector API (Ninth Incubator)

向量 API 现已进入第九次孵化，旨在表达向量通信，这些通信可在运行时可靠地编译为受支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。向量 API 之前已在 JDK 16 到 JDK 23 中孵化。该提案的目标包括以与平台无关的 API 清晰简洁地表达各种向量计算，在 x64 和 AArch54 架构上提供可靠的运行时编译和性能，在运行时无法表达向量计算时可优雅降级并仍能正常运行，并与 Valhalla 项目保持一致，利用对 Java 对象模型的增强功能。

14. JEP 490： ZGC：删除非分代模式

JEP 490: ZGC: Remove the Non-Generational Mode

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

15. JEP 491：无需固定即可同步虚拟线程

JEP 491: Synchronize Virtual Threads without Pinning

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

16. JEP 492：灵活的构造函数主体（第三次预览）

JEP 492: Flexible Constructor Bodies (Third Preview)

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

17. JEP 493：无需 JMOD 即可链接运行时图像

JEP 493: Linking Run-Time Images without JMODs

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

18. JEP 494：模块导入声明（第二预览版）

JEP 494: Module Import Declarations (Second Preview)

模块导入声明，之前在 JDK 23 中预览过，增强了 Java 编程语言的功能，使其能够简洁地导入模块导出的所有包。这简化了模块库的重用，但不需要将代码导入为模块本身。第二个预览版增加了一些功能，包括解除任何模块都不能声明对 java.base 模块的传递依赖的限制、修改 java.se 模块的声明以及允许 type-import-on-demand 声明遮蔽模块导入声明。

19. JEP 495：简单源文件和实例主要方法（第四个预览版）

JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview)

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

20. JEP 496：基于抗量子模块格的密钥封装机制

21. JEP 497：基于模块格的抗量子数字签名算法

JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism

JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

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

22. JEP 498：在 sun.misc.Unsafe 中使用内存访问方法时发出警告

JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe

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

23. JEP 499：结构化并发（第四个预览版）

JEP 499: Structured Concurrency (Fourth Preview)

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

24. JEP 501：弃用 32 位 x86 端口并将其删除

JEP 501: Deprecate the 32-bit x86 Port for Removal

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

03、Java 8 骨灰级程序员

最有意思的是，尽管 Java 版本稳定发布，目前仍有不少开发者在依旧坚持使用 Java 8，并扬言：

你发任你发，我用 Java 8。”

新版本？新特性？不熟，告辞！”

Java 24 是啥？Java 8 才是永远的神！”

用啥 Java 24，Java 8 用到世界毁灭。”

Java 24 再香，也香不过我的 Java 8 情怀。”

Java 8 永不为奴！”

那么，你目前项目中用到的 JDK 版本是多少呢？（多选，主要针对 LTS 版本）