前段时间发布了 Spring 6.1 和 SpringBoot 3.2，它们都完全支持 CRaC（检查点协调恢复）。

如果你想了解有关 CRaC 的更多信息，请随时阅读此处：

https://docs.azul.com/core/crac/crac-introduction

CRaC 是一个 OpenJDK 项目，可以“快照”正在运行的 JVM（Java 虚拟机）并将其状态（包括你的应用程序）存储到磁盘。然后，在另一个时间点，你可以将 JVM 从保存的检查点恢复到内存中。这样，我们就可以启动应用程序、预热它并创建检查点。从保存的检查点恢复到内存主要依赖于磁盘I/O，这意味着它非常快（在毫秒范围内）。

为了测试 SpringBoot 3.2 对 CRaC 的支持，我将使用 SpringBoot Petclinic 演示。

https://github.com/spring-projects/spring-petclinic

对于这个小测试，我在我的 M1 Macbook Pro 上使用 4 核和 4GB RAM 在 Parallels 中运行 Ubuntu 22.04。

先决条件

要在 SpringBoot 3.2 中使用 CRaC，你需要具备三件事：

• 支持 CRaC 的 JVM
• org.crac 的依赖项
• 可以存储检查点的文件夹

JDK

使用的 JDK（Java 开发工具包）是 Azul Zulu 21.0.1 + CRaC，你可以在此处获取：

https://www.azul.com/downloads/?os=linux&package=jdk-crac#zulu

JDK 适用于 x64 和 aarch64 CPU 架构以及 JDK 17 和 JDK 21。

权限

可能需要设置权限才能使用 CRIU，这意味着在运行演示的 Linux 机器上，你需要执行一次以下命令：

sudo chown root:root $JAVA_HOME/lib/criu
sudo chmod u+s $JAVA_HOME/lib/criu

org.crac。

将 petclinic 存储库克隆到本地计算机并添加对 org.crac 库的依赖项。

由于 CRaC 目前仅在 Linux 上可用，因此你找不到支持 MacOS 和 Windows 的 CRaC 的 JDK。这意味着如果你使用的是 Mac 或 Windows 计算机，则无法针对 CRaC API 进行编码。为了解决这个问题，org.crac 库提供了与支持 CRaC 的 JDK 中可用的相同 API，但你将在“org.crac”命名空间中找到它，而不是使用“jdk.crac”命名空间。

这样，即使在 MacOS 和 Windows 上，你也可以针对 CRaC API 进行编码，而不会出现任何问题，并且一旦你在具有启用 CRaC 的 JDK 的 Linux 系统上运行它，它将使用 CRaC 功能。

你可以在 Maven Central 上找到 org.crac ，因此你可以添加依赖，如下所示：

Gradle：

implementation 'org.crac:crac:1.4.0'

Maven：

<dependency>
  <groupId>org.crac</groupId>
  <artifactId>crac</artifactId>
  <version>1.4.0</version>
</dependency>

为检查点创建一个文件夹

在我们测试之前，我们需要确保我们有一个可以存储检查点的文件夹，例如 /tmp_checkpoint 在项目文件夹中。

插播一条：如果你近期准备面试跳槽，点击小程序刷题吧，共 2500+ 道，几乎覆盖了所有主流 Java 技术面试题。

不使用 CRaC 启动

克隆 petclinic 存储库后，你需要构建项目（例如 gradlew clean build），然后就可以运行它。

我们唯一感兴趣的是应用程序的启动时间。我对两个 JDK 版本（17 和 21）进行了测试，首先，只需从 17 切换到 21，petclinic 应用程序的启动时间就已经缩短了 500 毫秒！

因此，如果可能的话，你应该尽快切换 JDK，以获得更好的性能。

通过执行以下命令启动应用程序：

java -jar spring-petclinic-3.2.0.jar

以下是在不使用 CRaC 的情况下启动应用程序时的结果：

好的，快了大约 500ms，但启动仍然需要一些时间，所以让我们看一下 SpringBoot 3.2 中实现的另一种方法。

自动检查点

Spring 团队的工程师有一个好主意，通过在应用程序启动之前自动创建检查点来缩短 Spring/SpringBoot 框架的启动时间。

这是文档中的描述：

“当设置 -Dspring.context.checkpoint=onRefresh JVM 系统属性时，在 LifecycleProcessor.onRefresh 阶段启动时会自动创建一个检查点。此阶段完成后，所有非延迟初始化的单例都已实例化，并且 InitializingBean# afterPropertiesSet 回调已被调用；但生命周期尚未开始，并且 ContextRefreshedEvent 尚未发布。”

为了使用自动检查点，我们按如下方式启动应用程序：

java -Dspring.context.checkpoint=onRefresh -XX:CRaCCheckpointTo=./tmp_checkpoint -jar spring-petclinic-3.2.0.jar

执行应用程序后，它将创建检查点，并将检查点文件存储在文件夹 ./tmp_checkpoint 中，然后退出应用程序。

好用！无限制使用ChatGPT 4.0！

现在你可以通过执行以下命令从检查点恢复应用程序（这意味着再次启动它）：

java -XX:CRaCRestoreFrom=./tmp_checkpoint

以下是从自动检查点恢复时与启动时间相关的结果

这非常酷，我们的启动时间比原始启动时间快一个数量级，而无需更改代码。这也意味着检查点仅包含框架代码，而不包含你的应用程序代码，因为它尚未启动。

手动检查点

自动检查点已经是与启动时间相关的一个很大的改进，但我们甚至可以通过使用手动检查点来更快。

使用手动检查点时，你可以决定何时创建检查点。

为什么这很重要？

好吧，你可能想在 10 分钟后或当你的应用程序完全预热（大多数/所有代码已编译和优化）等时创建一个检查点。

创建手动检查点的过程与自动检查点类似，唯一的区别是你从应用程序外部触发检查点，而不是让框架自动创建检查点。

在开始之前，请确保检查点的文件夹为空。

首先，你按如下方式启动你的应用程序：

java -XX:CRaCCheckpointTo=./tmp_checkpoint -jar spring-petclinic-3.2.0.jar

现在，你需要等待应用程序完全启动，然后再打开第二个 shell 窗口。

在第二个 shell 窗口中，执行以下命令：

jcmd spring-petclinic-3.2.0.jar JDK.checkpoint

现在你应该看到在第一个 shell 窗口中（你启动 petclinic 应用程序的位置）创建了一个检查点并且应用程序已关闭。

你可以通过验证文件夹 ./tmp_checkpoint 是否包含检查点文件来检查应用程序是否已设置检查点。

现在你可以关闭第二个 shell 窗口。

要从此检查点恢复应用程序，请执行与自动检查点相同的命令：

java -XX:CRaCRestoreFrom=./tmp_checkpoint

这个手动触发的检查点不仅包含框架代码，还包含应用程序代码，这意味着我们应该看到更快的启动，因为应用程序已经由框架加载并启动。结果如下：

正如你所看到的，我们已经能够将 petclinic 应用程序的启动时间减少另一个数量级，降至 75 毫秒！

信息

由于Spring 6.1和SpringBoot 3.2完全支持CRaC，因此我们不需要对代码进行修改。这里的完全支持意味着只要你使用 Spring 资源，框架就会负责在检查点之前关闭资源并在恢复后恢复它们。

如果你使用其他资源，则需要在相关类中实现 CRaC Resource 接口，并在“beforeCheckpoint()”方法中关闭其他资源（例如打开的文件或套接字连接），并在“beforeCheckpoint()”方法中重新打开其他资源。afterRestore()' 方法。

判决

正如我们所看到的，使用 CRaC 可以显着减少 SpringBoot 3.2 应用程序的启动时间。如果你只是想在不接触代码的情况下尝试一下，只需使用 Spring 6.1 / SpringBoot 3.2 中的自动检查点功能即可将启动时间减少一个数量级。

为了尽可能缩短启动时间，你可以手动创建检查点，这可以将启动时间缩短两个数量级。

CRaC 的优点在于它仍然在普通 JVM 上运行，并且在检查点/恢复后代码甚至可以进一步优化。

为了获得这些结果，我需要向 petclinic 项目添加几行代码，如果你想重现这些数字，请随时在我的 GitHub 存储库中克隆 petclinic 项目的副本。

你还有什么想要补充的吗？