阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 江南一点雨 「江南一点雨」欢迎转载，保留摘要，谢谢！

• 一 CRaC是什么
• 二 CRaC的原理
• 三 CRaC 的应用场景
• 四 支持版本
• 五 实践

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

今天和小伙伴们来聊一个稍微新一点的技术话题—CRaC。

CRaC（Coordinated Restore at Checkpoint，检查点协调恢复）是一个 OpenJDK 项目，旨在解决 Java 应用程序启动和预热时间过长的问题。

Java 应用程序启动和预热时间过长是一个老大难的问题，目前来看各方也都提出了一些不同的解决思路，之前松哥和大家聊过的 AOT 也能从一定程度上解决启动慢的问题，今天的 CRaC 算是另外一种解决思路。

一 CRaC是什么

CRaC 允许对运行中的 JVM 进行“快照”，并将其状态（包括应用）存储到磁盘中。

之后，在另一个时间点，可以将 JVM 从保存的检查点恢复到内存中。

这个功能意味着你可以启动应用程序、预热并创建检查点，然后从这个检查点快速恢复，从而显著减少启动时间。

二 CRaC的原理

CRaC 的工作原理基于用户空间检查点和恢复（CRIU），这是一个为 Linux 实现检查点和恢复功能的项目。

CRIU 允许冻结容器或单个应用程序并从保存的检查点文件中恢复它。

CRaC 采用了 CRIU 的通用方法，并增加了一些增强和调整，使其适用于 Java 应用程序。

一般来说，CRaC 的执行步骤如下：

1. 创建检查点：在应用程序运行并达到稳定状态后，可以创建一个检查点，这个检查点包含了 JVM 的状态和应用程序的数据。
2. 存储检查点：检查点数据被存储到磁盘上，以便之后可以从中恢复。
3. 恢复检查点：当需要启动应用程序时，可以直接从检查点恢复，而不是从头开始启动和预热 JVM。

这个感觉就有点类似于大伙平时使用的 VMWare 的快照功能，在某个时间点为系统拍摄一个快照，下次可以直接从快照启动，就比从头开始启动要快很多。CRaC 所拍快照中不仅包含 JVM，也可以包含你的应用信息。

三 CRaC 的应用场景

CRaC 特别适用于需要快速启动和恢复的场景，比如：

• 云原生环境：在微服务和无服务器架构中，服务可能需要频繁地启动和停止，CRaC 可以显著减少服务的启动时间。
• 开发和测试环境：开发者可以在开发和测试过程中快速恢复应用程序到某个已知状态，提高开发效率。
• 灾难恢复：在系统发生故障时，可以快速从最近的检查点恢复服务，减少系统停机时间。

四 支持版本

从 Spring Boot3.2/Spring6.1 开始对 CRaC 的提供支持，所以如果大伙想体验 CRaC，需要选择合适的 SpringBoot 版本。

同时，由于前文提到的 CRaC 依赖于 Linux 特有的 CRIU，因此 CRaC 目前仅在Linux操作系统上支持。Windows 和 Mac 则不支持。

五 实践

首先我们需要安装支持 CRaC 的 JDK，目前主要有以下两种 JDK 支持 CRaC：

1. Azul Zulu 21.0.1 + CRaC 版本支持 CRaC，适用于 x64 和 aarch64 CPU 架构，包括 JDK17 和 JDK21。

2. Liberica JDK 17 和 Liberica JDK 21 提供了对 CRaC 的支持。

接下来在项目中添加 CRaC 依赖：

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

OK，如此之后，我们的准备工作就算完成了。

接下来我们需要在项目启动的时候，指定检查点的位置，并给出生成检查点的时机：

java -Dspring.context.checkpoint=onRefresh -XX:CRaCCheckpointTo=./tmp_checkpoint -jar javaboy-crac-3.3.5.jar

在上面的启动脚本中，我们通过设置 JVM 系统属性 -Dspring.context.checkpoint=onRefresh 来启用自动检查点。这个属性会在 Spring 的 LifecycleProcessor.onRefresh 阶段自动创建检查点，这个阶段在所有非延迟初始化的 Singleton 实例化和 InitializingBean#afterPropertiesSet 回调调用之后，但在生命周期启动和 ContextRefreshedEvent 发布之前。也就是说在这个时机创建检查点（拍摄快照）。

当然，如果你想等应用程序完全启动之后再拍摄快照，也是可以的。

先用如下命令启动应用程序：

java -XX:CRaCCheckpointTo=./tmp_checkpoint -jar javaboy-crac-3.3.5.jar

等待应用程序完全启动后，在另一个终端执行以下命令来手动触发检查点：

jcmd <pid> JDK.checkpoint

其中 <pid> 是应用程序的进程ID，这将创建检查点并关闭应用程序。检查点文件将存储在指定的文件夹中。

手动执行检查点生成的好处是，这个检查点包含了框架代码和应用程序代码，因此启动速度会更快，因为框架已经加载并启动了应用程序。

无论哪种方式生成检查点，只要有了检查点，最后一步就是使用这个检查点了。

我们可以利用检查点生成的文件来快速拉起应用程序，相关命令如下：

java -XX:CRaCRestoreFrom=./tmp_checkpoint

总结下就是，自动检查点适合快速实现和无需代码更改的场景，而手动检查点提供了更大的灵活性，允许在应用程序完全预热后创建检查点，从而可能实现更快的启动时间。

好啦，感兴趣的小伙伴可以去尝试下，记得选择合适的操作系统、JDK 版本以及 Spring Boot 版本哦～