自 2018 年以来，我们每六个月就会迎来 Java 平台的新版本。就像瑞士手表一样精准规律，Java 的最新版本即将到来。这次是 JDK 24。以一种近乎诗意的方式，它包含了 24 项 JDK 增强建议 (JEP)。
定于 3 月 18 日发布的 JDK 24 包含 24 项 JDK 增强建议 (JEP)，这是自引入基于时间的发布计划以来新功能数量最多的一次。虽然其中有 10 项是预览功能、孵化模块或实验性功能，但仍有 14 项新功能。
您想了解的 6 项新功能
JDK 增强功能并不总是增加新功能。正如您将看到的，有些功能实际上是移除了过时或适得其反的功能。我选择了与开发人员和 Java 部署人员特别相关和有趣的 6 项新功能。
JEP 483：提前加载和链接类
JEP 483“提前加载和链接类”是更广泛的 Project Leyden 的一部分。Project Leyden 的目标是缩短与 Java 应用程序相关联的启动时间。Java 最大的优势之一在于对 JVM 的使用，这是一种虚拟机，它能让应用程序无需重新编译即可在任何平台上运行。这种“一次编写，随处运行”的方法还能利用即时编译 (JIT) 提供出色的可扩展性和性能。遗憾的是，这样做也是有代价的，表现为当应用程序预热时，性能会降低。
Project Leyden 分为几个部分，JEP 483 是 JDK 中要交付的第一个部分。这与 JDK 11 中引入的应用程序类数据共享有关，它使应用程序的类在 JVM 启动时立即处于加载和链接状态。这避免了每次启动应用程序时重复加载、验证和链接类文件的开销。
JEP 485：流收集器
JEP 485（流收集器） 是一项虽小但很有价值的变更，将使开发人员受益。JDK 8 引入了流 API，它与 Lambda 表达式相结合，在 Java 中提供了一种功能性更强的编程风格。
流由三部分组成：一个源、零项或多项中间操作和一项终端操作。开发人员通过指定实现收集器接口的任意功能，可以完全灵活地控制终端操作。
对于中间操作，有一套固定（尽管丰富多样）的可用方法。与收集器接口可用于自定义终端操作一样，收集器接口现在也可用于提供自定义中间操作。
JEP 486：永久禁用安全管理器
JEP 定义了 JDK 的增强功能，但这并不总是意味着要添加某些东西。
JEP 486（永久禁用安全管理器）移除了一些功能。乍听之下，这一特定的 JEP 令人不安。移除安全管理器？这不是会降低 JDK 的安全性吗？实际情况却大相径庭。
自 Java 首次发布以来，安全管理器就一直是 Java 的一部分，在执行远程加载的代码时使用。默认情况下，所有远程代码都被视为不可信任，因此无法访问文件系统、网络等资源。必须为每个所需的资源和访问形式授予明确的权限。
长期以来，安全管理器一直不是保护客户端 Java 安全的主要手段，也很少用于保护服务器端代码的安全。小程序的时代早已一去不复返了，在 JDK 11 中，浏览器插件已被移除。考虑到安全管理器的维护成本，它在 JDK 17 中被弃用，现在在 JDK 24 中已无法使用。遗憾的是，一些开发人员使用了这一功能，但却没有提供替代方案。将这些应用程序迁移到 JDK 24 及更高版本可能需要进行重大的架构更改和重新编码。虽然 Java 具有出色的向后兼容性，但有时必须更改应用程序才能在较新版本上运行。
JEP 491：同步虚拟线程而不固定
JDK 21 中引入了虚拟线程，能够大大提高应用程序的可扩展性，这些应用程序通常使用一线程一请求编程模型，而且这些线程被阻塞时会花费大量时间。但是，虚拟线程在使用同步方法或块时会受到限制。即使虚拟线程被阻塞，但如果它处于同步块或方法中，底层平台线程也不会被释放供其他虚拟线程使用。这是因为同步方法或块使用的监视器与平台线程而非虚拟线程相关联。
JEP 491（同步虚拟线程而不固定）通过将监控器关联移至虚拟线程，解决了这一限制。JVM 对同步关键字的实现方式已被更改，以便虚拟线程能够独立于其载体获取、保持和释放监视器。现在，挂载和卸载操作可处理必要的记账工作，允许虚拟线程在同步方法或语句中或在监视器上等待时卸载和重新挂载。
JEP 498：使用 sun.misc.Unsafe 中的内存访问方法时发出警告
自 JDK 9 以来，内部 JDK API 的封装越来越严格。在 JDK 24 中，我们朝着完全移除访问权限的方向又迈进了一步。
臭名昭著的 sun.misc.Unsafe 类一直以来都是个问题，因为它所包含的功能是无法通过用户编写的类来复制实现的。现在，所有与内存相关的方法都可以通过 VarHandle API 和外部函数与内存 API 提供的公共 API 来使用。JEP 498（使用 sun.misc.Unsafe 中的内存访问方法时发出警告）意味着，现在只要首次调用 sun.misc.Unsafe 中的任何内存访问方法，JVM 就会在运行时发出警告。
JEP 501：弃用 32 位 x86 端口以便后续移除
本文最后一个值得关注的 JEP 是JEP 501：弃用 32 位 x86 端口以便后续移除，它弃用了 32 位 x86 端口以便后续移除。实际上，这只影响 Linux 版本的端口，因为 Windows 版本的端口已在 JDK 21 (JEP 479) 中被移除。很少有人还在 32 位操作系统上运行应用程序，如果不同时将操作系统升级到 64 位版本，将应用程序迁移到现代 JDK 是毫无意义的。
JDK 24 继续推动 Java 平台向前发展，提供了开发人员和用户认为有用的功能。预计在 JDK 25（下一个长期支持版本，2025 年 9 月）及以后的版本中会提供更多此类功能。
您的 JDK 选择非常重要
Azul 提供 OpenJDK 的 Zulu 构建版本，既有免费的社区版形式，也有通过我们的 Platform Core 产品提供商业支持的版本。
Core 有几个独特之处，使其有别于 Oracle Java SE 和其他 OpenJDK 发行版：
- 价格通常比 Oracle 低 70%
- 支持 Java 6 和 7
- 稳定的安全构建版本
- 确保免受版权污染
有关 Azul Zulu 24 的更多信息，请查阅我们的《Azul 季度更新发布说明》。为何不试试 Azul Zulu 24？
