第 3 章 Red Hat build of OpenJDK 功能

最新的 Red Hat build of OpenJDK 21 发行版本可能包括新功能。另外，最新版本可能会增强、弃用或删除来自以前红帽构建的 OpenJDK 21 版本的功能。

Red Hat build of OpenJDK 的改进

红帽构建的 OpenJDK 21 为最初在以前版本的 OpenJDK 中创建的功能提供了改进。

-XshowSettings launcher 选项包含一个 安全 类别

在 Red Hat build of OpenJDK 21.0.4 中，-XshowSettings launcher 选项包含一个安全类别，允许传递以下参数：

如果应用程序类路径或模块路径中包含第三方安全供应商，且在 java.security 文件中配置，则输出会包括这些第三方安全提供程序。

请参阅 JDK-8281658 (JDK Bug System)。

添加了 GlobalSign R46 和 E46 root 证书

在 OpenJDK 21.0.4 中，cacerts truststore 包括两个 GlobalSign TLS root 证书：

请参阅 JDK-8316138 (JDK Bug System)。

仅 POSTOCSP 请求的回退选项

JDK-8175903 是红帽构建的 OpenJDK 17 中引入的，增加了对将 HTTP GET 方法用于在线证书状态协议(OCSP)请求的支持。此功能为小请求无条件地启用。

Internet Engineering Task Force (IETF) RFC 5019 和 RFC 6960 明确允许，并建议使用 HTTP GET 请求。但是，有些 OCSP 响应器无法在这些类型的请求中正常工作。

Red Hat build of OpenJDK 21.0.4 引入了 JDK 系统属性 com.sun.security.ocsp.useget。默认情况下，此属性设置为 true，它会保留对小请求使用 GET 请求的当前行为。如果此属性设置为 false，则只使用 HTTP POST 请求，无论大小如何。

请参阅 JDK-8328638 (JDK Bug System)。

RPATH 优先于 RUNPATH 用于内部 JDK 二进制文件中的 $ORIGIN 运行时搜索路径

JDK 中的原生可执行文件和库使用嵌入式运行时搜索路径(rpaths)来定位所需的内部 JDK 原生库。在 Linux 系统上，二进制文件可以使用 DT_RPATH 或 DT_RUNPATH 指定这些搜索路径。

如果二进制文件使用 DT_RPATH 指定搜索路径，则会在 LD_LIBRARY_PATH 环境变量中指定的任何路径 之前 搜索这些路径。如果二进制文件使用 DT_RUNPATH 指定搜索路径，则仅在 LD_LIBRARY_PATH 中指定的路径 后 进行搜索。这意味着，使用 DT_RUNPATH 允许 JDK 内部库被 LD_LIBRARY_PATH 中指定的名称的任何库覆盖。

在以前的版本中，使用的运行时搜索路径类型是基于动态链接器的默认搜索路径。在 OpenJDK 21.0.4 的 Red Hat build 中，为了确保使用 DT_RPATH，--disable-new-dtags 选项被明确传递给链接器。

请参阅 JDK-8326891 (JDK Bug System)。

Jpackage 工具在将文件路径传递给 dpkg之前解析符号链接

在 Debian 和 Ubuntu 系统上，jpackage 工具使用 dpkg -S 命令检查哪个软件包提供特定的文件。但是，在较新的 Debian 和 Ubuntu 系统上，dpkg -S 命令无法解析符号链接。

在 OpenJDK 21.0.4 的 Red Hat build 中，jpackage 在将实际文件路径传递给 dpkg 之前解析符号链接。

请参阅 JDK-8295111 (JDK Bug System)。

G1 垃圾收集器忽略了在 Remark 阶段重新调整大小的现有 eden 区域

为了遵守 -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio 设置，Garbage-First (G1)垃圾收集器调整垃圾回收的 Remark 阶段的 Java 堆大小，保持在这些限制内可用区域的数量。

在早期版本中，eden 区域被视为已占用或完全用于计算 Java 堆大小。这意味着堆大小取决于 Remark 阶段运行时的 eden occupancy。但是，在下一个垃圾回收后，这些 eden 区域为空。

在 Red Hat build of OpenJDK 21.0.4 中，在 Remark 阶段计算过程中，eden 区域被视为为空或自由。此增强意味着 G1 垃圾收集器现在积极地扩展 Java 堆，更确定，因为可用区域的数量没有很大不同。此增强还使 Java 堆大小与完整的垃圾回收堆大小保持一致。但是，这可能会导致更频繁的垃圾回收。

请参阅 JDK-8314573 (JDK Bug System)。

修复了在代码 根扫描 阶段因为不平衡迭代而暂停长时间垃圾回收的修复

垃圾回收的代码 根扫描 阶段查找对编译的代码中的 Java 对象的引用。为加快这个过程，会在包含 Java 堆引用的编译代码的每个区域中维护缓存。

假设一组引用非常小，以前的发行版本使用每个区域的单一线程来迭代这些引用。这种单线程方法引入了一个可扩展性瓶颈，如果特定区域包含大量参考，则性能可能会降低。

在 Red Hat build of OpenJDK 21.0.4 中，会使用多个线程，这有助于消除任何可伸缩的瓶颈。

请参阅 JDK-8315503 (JDK Bug System)。

修复长垃圾回收在 Stop-the-World 收集器中暂停的问题

在 Red Hat build of OpenJDK 21 的早期版本中，应用程序在停止(STW)垃圾回收过程中可能会经历很长时间的暂停时间。此问题会影响集合的不同阶段，包括 Class Unloading、Root Scanning 和 CodeCache Unloading，在所有类型的 STW 垃圾收集器中，如 Serial、Parallel 和 G1 收集器。

红帽构建的 OpenJDK 21.0.4 解决了 STW 收集器中的这些性能问题。

请参阅 JDK-8333832 (JDK Bug System)。

在 Windows 上更改 AWT 无头模式检测的行为

在早期版本中，除非 java.awt.headless 系统属性被设置为 true，否则在 Windows Server 平台上调用 java.awt.GraphicsEnvironment.isHeadless （） 返回 false。

从 OpenJDK 21.0.4 开始，除非 java.awt.headless 属性明确设置为 false，且当前系统上没有检测到有效的 monitor，则调用 java.awt.GraphicsEnvironment.isHeadless （） 会在 Windows Server 平台上返回 true。可能无法检测到有效的 monitor，例如，如果会话是由服务启动还是 PowerShell 远程启动。

这个行为的变化意味着在这些条件下运行的应用程序（以前预期会在头环境中运行），现在可能会遇到 Abstract Window Toolkit (AWT)操作所引发的非 头例外 错误。

您可以通过将 java.awt.headless 属性设置为 false 来重新恢复旧行为。但是，如果应用程序以 headful 模式运行，且有效的显示不可用，则这些应用程序可能会继续遇到意外问题。

请参阅 JDK-8185862 (JDK Bug System)。