JEP 341：默认 CDS 存档
概述
增强 JDK 构建过程，以便在 64 位平台上使用默认类列表生成类数据共享 (CDS) 存档。
目标
- 提升开箱即用的启动时间
- 消除用户运行
-Xshare:dump以从 CDS 中受益的需求
非目标
- 我们将仅为本地构建生成默认存档，而不为交叉编译的构建生成。
- 我们将仅为 64 位构建生成默认存档；对 32 位构建的支持可能会稍后添加。
动机
自 JDK 8u40 以来，基础 CDS 功能得到了许多增强。启用 CDS 所带来的启动时间缩短和内存共享优势显著增加。在 Linux/x64 上使用 JDK 11 早期访问版本 14 进行的测量显示，运行 HelloWorld 时启动时间减少了 32%。在其他 64 位平台上，观察到了类似或更高的启动性能提升。
目前，JDK 镜像在 lib 目录中包含一个默认的类列表，该列表是在构建时生成的。想要利用 CDS（即使仅使用 JDK 中提供的默认类列表）的用户必须执行 java -Xshare:dump 作为额外的步骤。此选项在文档中有说明，但许多用户并不知晓。
描述
修改 JDK 构建过程，以便在链接镜像后运行 java -Xshare:dump。（可以添加额外的命令行选项来微调 GC 堆大小等，从而为常见场景获得更好的内存布局。）将生成的 CDS 存档保留在 lib/server 目录中，使其成为最终镜像的一部分。
用户将自动受益于 CDS 功能，因为在 JDK 11 中，默认情况下服务器 VM 已启用 -Xshare:auto（JDK-8197967）。要禁用 CDS，请使用 -Xshare:off 运行。
具有更高级需求的用户（例如，使用包含应用程序类的自定义类列表、不同的 GC 配置等）仍可以像以前一样创建自定义 CDS 存档。
替代方案
构建默认的 CDS 存档，但禁用 -Xshare:auto。
这种方法会更安全。在 Windows 上，CDS 在许多版本中已经默认启用，因为默认的 CDS 存档是由 JDK Windows 安装程序创建的，但其他平台并非如此。如果我们在用户未作出明确选择的情况下突然启用 CDS，那么现有的应用程序可能会受到影响，例如，如果它们依赖于 JVM 启动序列的未记录方面。
如果禁用了 -Xshare:auto（即，我们回退了 JDK-8197967），那么即使默认的 CDS 存档包含在 JDK 中，用户也需要在命令行中显式指定 -Xshare:auto 才能使用 CDS。这将为用户提供一个适应默认 CDS 存档的过渡期，之后我们可以在未来的版本中重新实施 JDK-8197967。
这种方法的优势在于：
- 它不会立即改变默认行为。
- 通过消除常见情况下的
java -Xshare:dump步骤，它提高了使用默认存档的 CDS 可用性。 - 通过在不立即改变默认行为的风险下向用户提供默认存档，它提供了更多的测试曝光。
这种方法存在的问题包括：
- 我们将在
-Xshare:auto之间来回切换，这会引起混淆。 - 这一做法基于一个错误的假设，即包含 CDS 存档具有高风险。CDS 默认存档在 Windows（客户端）上已经启用了十多年，很少出现问题。
- 用户只有在明确开启
-Xshare:auto选项时才能测试此功能。然而，那些关心（或了解）CDS 的用户可能已经创建了 CDS 存档，并针对之前的版本修改了他们的命令行，这意味着他们已经在没有我们提供默认存档的情况下测试了 CDS。这种方法是否真的会带来更多的测试，令人怀疑。
相比之下，使用此 JEP 中提出的方法，许多开发者在构建 JDK 或使用早期访问版本时会隐式测试 CDS，这显然会带来更多的测试。
测试
现有的启用了 CDS 的自动化测试已经足够。