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