Spring Boot 3.2 + CRaC = 王炸！
前段时间发布了 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
2
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>
2
3
4
5
为检查点创建一个文件夹
在我们测试之前，我们需要确保我们有一个可以存储检查点的文件夹，例如 /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 中，然后退出应用程序。
现在你可以通过执行以下命令从检查点恢复应用程序（这意味着再次启动它）：
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 项目的副本。