When OpenJDK VM Sharing is Restricted: The Bootstrap Classpath Effect – wiki基地

当 OpenJDK VM Sharing 受限时：Bootstrap Classpath 的影响

引言

在追求应用程序性能和资源效率的现代计算环境中，Java 虚拟机（JVM）的启动速度和内存占用是关键考量因素。OpenJDK 提供了一项强大的功能，称为虚拟机共享（VM Sharing），具体实现是类数据共享（Class Data Sharing, CDS）。这项技术旨在显著缩短 JVM 的启动时间并减少多个 Java 进程的内存占用，其核心思想是将一部分核心类和应用类在 JVM 启动时加载并处理后，将其元数据存储到一个共享文件中（通常是 classes.jsa）。后续启动的 JVM 实例可以直接映射这个共享文件到内存中，从而避免重复加载、解析和验证这些类的开销。

然而，CDS 并非总能按预期工作。在某些情况下，JVM 会检测到环境与创建共享文件时的环境不匹配，从而拒绝使用共享存档（shared archive），转而回退到传统的类加载方式。这会导致 CDS 的所有性能和内存优势完全丧失。理解 CDS 何时以及为何会受限，对于有效利用这项技术至关重要。众多可能导致 CDS 受限的原因中，Bootstrap Classpath（引导类路径）的变化是一个特别重要且常常被忽视的因素。本文将深入探讨 OpenJDK VM Sharing (CDS) 的工作原理，分析其受限的各种场景，并重点阐述 Bootstrap Classpath 的变化如何直接或间接地导致 CDS 失效，以及由此带来的影响和应对策略。

OpenJDK VM Sharing (CDS) 的工作原理

OpenJDK 的 CDS 功能，特别是基线 CDS（base CDS）和应用 CDS（Application CDS，AppCDS），依赖于预先在 JVM 启动时加载一部分类，并将它们的内部表示（包括类的元数据、字段布局、方法字节码指针等）序列化并保存到一个特定的文件中。这个文件通常被称为共享存档（shared archive）或 CDS 存档。

整个过程分为两个阶段：

Dump (创建) 阶段:
- 启动一个特殊的 JVM 实例，通常使用 -Xshare:dump 参数。
- 在这个阶段，JVM 会加载指定的类（对于基线 CDS，通常是 JDK 的核心运行时类；对于 AppCDS，还需要加载应用指定的类列表）。
- JVM 会执行一些初始化步骤，解析这些类的元数据。
- 然后，JVM 会将这些加载好的类的元数据、内部数据结构等写入一个共享文件中。这个文件通常存储在 JDK 安装目录下的特定位置（例如 $JAVA_HOME/lib/server/classes.jsa）。
Run (运行) 阶段:
- 正常启动一个 Java 应用程序，通常使用 -Xshare:auto (默认) 或 -Xshare:on 参数。
- JVM 启动时，会检查是否存在有效的共享存档文件。
- 如果存在，JVM 会尝试将这个文件映射到其地址空间的一个共享内存区域。
- JVM 会对共享存档进行验证，包括检查版本、环境一致性等。
- 如果验证通过，JVM 将直接使用共享内存中的类元数据来创建和初始化对象，而不是从 JAR 或 class 文件中重新加载和解析。

通过这种方式，后续启动的 JVM 实例可以直接“共享”同一个预加载的类数据，显著减少了重复工作，从而加速启动并降低内存消耗。

CDS 受限的常见原因

尽管 CDS 功能强大，但在许多情况下它可能无法正常工作。JVM 在尝试使用共享存档时，会执行一系列严格的检查，任何不一致都可能导致回退到非共享模式。常见的受限原因包括：

禁用 CDS: 显式使用 JVM 参数 -Xshare:off 会禁用 CDS。
共享存档不存在或无权限访问: JVM 找不到共享存档文件，或者当前用户没有读取文件的权限。
共享内存不足: JVM 无法分配足够大的共享内存区域来映射存档文件。这可能发生在内存受限的环境中。
存档文件损坏或版本不匹配: 存档文件可能已损坏，或者它是用不同版本的 JVM（即使是同一主版本但构建号不同）创建的。JVM 通常会检查存档中的版本信息和签名。
环境不一致: 创建存档时的环境与运行时的环境存在显著差异。这种环境差异是导致 CDS 受限的最常见、最复杂的原因之一，其中 Bootstrap Classpath 的变化是核心因素。
安全管理器限制: （在现代 Java 版本中较少见）如果存在一个限制文件系统访问或内存映射的安全管理器，可能会阻止 CDS 正常工作。
操作系统限制: 某些操作系统设置或容器环境可能限制共享内存的使用或文件映射。

本文重点探讨第 5 点中的一个关键方面：Bootstrap Classpath 的变化如何导致环境不一致，进而限制 CDS 的使用。

什么是 Bootstrap Classpath？

Bootstrap Classpath 是 Java 类加载机制中最基础的一环。它包含了 JVM 启动时加载的核心运行时类库。在 Java 8 及更早版本中，这主要指向 rt.jar、jre/lib 下的其他核心 JAR 文件以及 jre/classes 目录。在 Java 9 及更高版本引入模块系统后，Bootstrap Classpath 的概念演变为 JVM 启动时加载的核心模块（如 java.base、java.logging 等）所包含的类。这些类由 Bootstrap ClassLoader（根类加载器）加载，它是所有其他类加载器的父加载器。

Bootstrap Classpath 中的类是 JVM 正常运行所必需的最基本的组件，包括 java.lang.Object、java.lang.String、各种核心集合类、I/O 类等。它们的定义、结构和行为是 JVM 内部实现的基础。

Bootstrap Classpath 对 CDS 的影响：核心机制

CDS 的核心是将 已加载 的类的元数据进行序列化。这些已加载的类中，很大一部分是由 Bootstrap Classloader 加载的核心类。当 JVM 尝试使用共享存档时，它会检查存档中记录的类信息是否与当前运行环境中 Bootstrap Classpath 中实际可用的类相匹配。这种匹配检查非常严格，因为如果核心类的定义发生了变化，而 JVM 仍然使用存档中过时的或错误的元数据，可能会导致不可预测的行为、崩溃或安全漏洞。

JVM 进行匹配检查时，通常会比对：

核心 JAR/Module 的身份: 在较早版本中可能是 rt.jar 等文件的路径、大小、时间戳或哈希值。在模块化版本中，是核心模块的版本和校验和。
存档中引用的类的签名/结构: 存档中保存了类的内部表示。JVM 会快速验证这些表示是否与当前 Bootstrap Classpath 中加载的同名类兼容。

如果 JVM 检测到 Bootstrap Classpath 中的任何核心组件与创建共享存档时的环境不一致，它就会判断当前环境与存档不兼容，从而放弃使用共享存档。

Bootstrap Classpath 变化导致 CDS 失效的场景

以下是导致 Bootstrap Classpath 变化并进而影响 CDS 的常见场景：

使用 -Xbootclasspath/a 或 -Xbootclasspath/p 参数:
- -Xbootclasspath/a:<path>：将指定路径添加到 Bootstrap Classpath 的末尾。
- -Xbootclasspath/p:<path>：将指定路径添加到 Bootstrap Classpath 的开头。
- 这两个参数允许开发者修改默认的 Bootstrap Classpath，例如为了注入诊断工具、实现 AOP（Aspect-Oriented Programming）或替换 JDK 的某些核心类。
- 影响: 如果在创建 CDS 存档（-Xshare:dump）时使用了这些参数，那么在运行应用程序时（-Xshare:auto/-Xshare:on）必须使用 完全相同 的参数和路径，并且路径指向的文件内容也必须一致。反之，如果在创建存档时没有使用这些参数，而在运行时使用了，也会导致不匹配。即使仅仅改变了路径中文件的时间戳或大小，也可能导致 CDS 验证失败。JVM 的设计理念是，Bootstrap Classpath 应该尽可能保持稳定和不可变，对它的任何修改都被视为潜在的不兼容性。
使用 -Xbootclasspath 参数 (较旧或非标准 JDK):
- 这是一个更旧的参数，允许完全替换 Bootstrap Classpath。在现代 OpenJDK 版本中已被弃用或移除，由模块系统取代了大部分需求。
- 影响: 如果你在使用一个支持这个参数的 JDK 版本，并且创建存档和运行应用程序时使用了不同的 -Xbootclasspath 设置，CDS 将失效。
使用不同构建或供应商的 JDK:
- 即使是同一主版本的 JDK（例如都声称是 JDK 17），来自不同供应商（Oracle OpenJDK, Adoptium, Azul Zulu, Amazon Corretto 等）或甚至是同一供应商的不同构建号，其内部的核心类库文件（如 rt.jar 或模块 JAR 文件）可能存在细微差异。这些差异可能体现在文件大小、时间戳、内部结构甚至是类字节码上。
- 影响: 如果你用一个构建的 JDK 创建了 CDS 存档，然后尝试用另一个构建的 JDK 运行应用程序并使用该存档，很可能因为核心类库文件的差异导致 Bootstrap Classpath 环境检查失败，CDS 无法使用。
JDK 安装目录移动或文件更改:
- CDS 存档（classes.jsa）通常位于 JDK 安装目录的特定位置。存档文件内部可能记录了它创建时所依赖的核心 JAR 或模块文件的相对或绝对路径、大小、时间戳等信息。
- 影响: 如果在创建存档后，移动了整个 JDK 安装目录，或者手动修改、替换了 JDK 目录下的核心 JAR/模块文件（即使没有使用 -Xbootclasspath 参数），都可能导致 JVM 在运行时检查时发现这些文件信息与存档中记录的不一致，从而禁用 CDS。
模块路径 (--module-path) 的影响 (AppCDS 相关):
- 虽然严格来说，--module-path 主要影响的是 Platform ClassLoader 或 Application ClassLoader 加载的模块，而不是 Bootstrap Classloader。但在使用 Application CDS (AppCDS) 时，AppCDS 存档中会包含应用模块和部分平台模块的类元数据。AppCDS 存档的创建和使用对模块路径的依赖性非常强。
- 影响: 如果创建 AppCDS 存档时使用的 --module-path 配置与运行时不同，或者模块路径上的模块内容发生了变化，即使 Bootstrap Classpath（核心模块）本身没有变化，AppCDS 也会失效。这虽然不是严格意义上的“Bootstrap Classpath Effect”，但在实践中，涉及到共享类库的 CDS 功能受限时，模块路径的变化是 AppCDS 失效的一个主要原因，其原理与 Bootstrap Classpath 变化导致基线 CDS 失效有相似之处：都是因为依赖的类库环境发生了变化。

CDS 受限的后果

当 CDS 由于 Bootstrap Classpath（或任何其他原因）受限而回退到传统模式时，应用程序仍然可以正常启动和运行，但会失去 CDS 带来的所有优势：

启动时间增加: JVM 需要重新加载、解析、验证和初始化那些原本可以通过共享存档快速获取的类。这会显著延长 JVM 的启动时间，特别是对于包含大量类的大型应用程序。
内存占用增加: 每个 JVM 实例都会在自己的堆外内存区域（Metaspace 或 PermGen）中独立存储一份类元数据副本，而不是共享同一份只读数据。这会导致多个 JVM 实例运行时总体的内存消耗增加。
GC 压力: 更多的元数据复制可能导致垃圾收集器在处理类元数据时花费更多时间，尽管这通常不是主要影响。

对于微服务架构或 Serverless 环境中频繁启动和停止的短生命周期应用来说，启动时间的增加尤其不利，因为它直接影响了请求的响应速度和资源的利用效率。

诊断和解决 CDS 受限问题

识别 CDS 是否受限以及受限的原因是解决问题的第一步。

检查 JVM 参数: 确保运行时没有意外使用了 -Xshare:off。如果使用了 -Xshare:on 而 JVM 启动失败并报错，那明确是 CDS 问题。如果使用 -Xshare:auto (默认)，JVM 会静默回退。
查看 JVM 输出: 在启动 JVM 时，添加 -Xlog:cds 或 -Xlog:classload 参数可以获得详细的 CDS 和类加载信息。JVM 会在日志中说明是否成功使用了共享存档，如果失败，通常会给出原因（例如“Shared archive not found”、“Mismatched CDS archive”、“Invalid layout”等）。寻找与 Bootstrap Classpath 相关的错误信息。
验证 JDK 版本和构建: 确保用于创建 CDS 存档的 JDK 完全一致 于用于运行应用程序的 JDK。检查 $JAVA_HOME/release 文件或使用 java -version 和 java -fullversion 输出进行比对。
检查 Bootstrap Classpath 参数: 如果在创建或运行阶段使用了 -Xbootclasspath/a 或 -Xbootclasspath/p，请核对这两个阶段的参数是否完全一致，并且引用的文件路径和内容是否相同。
验证 JDK 安装目录状态: 检查 $JAVA_HOME 目录是否被移动，核心库文件是否被意外修改或替换。
（对于 AppCDS）检查模块路径: 确保创建 AppCDS 存档时使用的 --module-path 与运行时完全匹配，并且模块内容未发生变化。

解决策略:

核心原则是确保创建 CDS 存档时的环境与运行时的环境尽可能一致，特别是与 Bootstrap Classpath 相关的部分：

使用相同的 JDK 分发和构建: 始终使用同一份 JDK 安装来执行 CDS dump 和运行应用程序。在自动化部署流程中，确保使用的 JDK 是固定的版本和来源。
避免不必要的 Bootstrap Classpath 修改: 除非有非常明确的理由，否则应尽量避免使用 -Xbootclasspath/a 或 -Xbootclasspath/p。如果必须使用，确保 dump 和 run 阶段的设置 完全相同。
固化环境: 在容器化环境中，使用相同的 Docker 镜像构建步骤来生成 CDS 存档和运行应用程序，可以最大程度保证环境一致性。
重新创建 CDS 存档: 如果环境（如 JDK 版本或补丁）发生了变化，务必重新创建 CDS 存档。
足够的内存和权限: 确保运行环境中 JVM 有足够的内存分配共享区域，并且对 CDS 存档文件有读取权限。

AppCDS 与 Bootstrap Classpath Effect

Application CDS (AppCDS) 扩展了基线 CDS 的能力，允许将应用程序自己的类和更多的 JDK 平台类也包含到共享存档中。AppCDS 需要用户提供一个类列表，告诉 JVM 哪些应用类应该被加载并包含在存档中。

AppCDS 的创建命令通常是：

bash java -Xshare:dump -XX:DumpLoadedClassList=classes.lst -XX:SharedArchiveFile=app_classes.jsa <MainClass or other setup>

然后运行时使用：

bash java -XX:SharedArchiveFile=app_classes.jsa <MainClass>

AppCDS 同样会受到 Bootstrap Classpath 变化的影响，因为它的存档也依赖于核心 JDK 类。此外，AppCDS 对应用程序 Classpath 和 Module Path 的变化更加敏感。如果在创建 AppCDS 存档时，应用程序的 JAR 文件、依赖库或者模块路径与运行时不同，AppCDS 也将失效。这种情况下，虽然 Bootstrap Classpath 可能未变，但 AppCDS 所依赖的应用级环境不一致同样导致存档无法使用。因此，在使用 AppCDS 时，需要确保整个类加载环境（包括 Bootstrap Classpath, Extension Classpath (如果使用), Application Classpath, Module Path）在 dump 和 run 阶段保持一致。

总结

OpenJDK 的虚拟机共享（CDS）是一项提升 Java 应用程序启动性能和减少内存占用的重要技术。它通过将预加载的类元数据保存在共享存档中，使多个 JVM 实例能够共享这些数据。然而，CDS 的有效性高度依赖于创建存档时的环境与运行时的环境之间的一致性。

Bootstrap Classpath，作为 JVM 最底层的类路径，包含了 JVM 启动所需的核心类库。对 Bootstrap Classpath 的任何修改，例如通过 -Xbootclasspath 系列参数添加额外的 JAR 包，或者使用了不同构建号、不同供应商的 JDK，都会改变核心类库的环境。JVM 在加载 CDS 存档时，会严格检查当前 Bootstrap Classpath 环境是否与存档创建时记录的环境匹配。任何不匹配都会导致 CDS 校验失败，JVM 将放弃使用共享存档，转而执行传统的类加载过程。

这种“Bootstrap Classpath Effect”是导致 CDS（包括基线 CDS 和 AppCDS）失效的一个常见且关键原因。当 CDS 受限时，应用程序会损失启动加速和内存共享的优势，特别是在需要快速启动和扩展的场景下影响更为明显。

为了确保 CDS 能有效工作，最关键的措施是维护创建共享存档的环境与运行环境之间的高度一致性。这意味着使用相同的 JDK 分发和构建，避免随意修改 Bootstrap Classpath，以及在环境发生变化时及时重新创建 CDS 存档。理解并妥善处理 Bootstrap Classpath 对 CDS 的影响，是充分利用 OpenJDK VM Sharing 功能、优化 Java 应用性能的关键。