Backend Development 8 min read

Using CRaC with Spring Boot 3.2 and Spring 6.1: A Practical Guide

This article demonstrates how to enable and use Coordinated Restore at Checkpoint (CRaC) in Spring Boot 3.2 with the Spring Petclinic example, covering required dependencies, JVM setup, automatic and manual checkpoint creation, performance measurements, and best‑practice considerations for backend developers.

Selected Java Interview Questions
Selected Java Interview Questions
Selected Java Interview Questions
Using CRaC with Spring Boot 3.2 and Spring 6.1: A Practical Guide

Spring 6.1 and Spring Boot 3.2 have been released with full support for CRaC (Coordinated Restore at Checkpoint), an OpenJDK project that can snapshot a running JVM—including the application state—to disk and later restore it, achieving millisecond‑level startup times.

To test Spring Boot 3.2's CRaC support, the Spring Petclinic sample is used. Three prerequisites are needed: a CRaC‑compatible JVM, the org.crac JAR, and a writable directory for checkpoint files.

Installing Zulu JDK

The required JDK is Azul Zulu 21.0.1+ with CRaC support, available at https://www.azul.com/downloads/?os=linux&package=jdk-crac . CRaC currently runs only on Linux.

On Linux, set permissions for CRIU with:

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

Adding the CRaC JAR Dependency

Clone the Petclinic source and add the following Maven dependency:

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

Baseline Test

Running the application on JDK 17 vs JDK 21 reduces startup time by about 500 ms, but total startup still takes roughly 4 seconds.

java -jar spring-petclinic-3.2.0.jar

Automatic Checkpoint

By launching with the JVM flag -Dspring.context.checkpoint=onRefresh , a checkpoint is created automatically during the LifecycleProcessor.onRefresh phase, before any lazy beans are instantiated.

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

After the application exits, the checkpoint files are stored in ./tmp_checkpoint . The application can be restored with:

java -XX:CRaCRestoreFrom=./tmp_checkpoint

Restoring from the automatic checkpoint reduces startup time by an order of magnitude without any code changes.

Manual Checkpoint

Manual checkpoints can be triggered at any time, allowing the application to be fully warmed up before snapshotting.

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

Once the application is fully started, create a checkpoint from a second shell:

jcmd spring-petclinic-3.2.0.jar JDK.checkpoint

The checkpoint files appear in ./tmp_checkpoint . Restoration uses the same command as the automatic case.

Special Notes

Spring Boot 3.2 supports CRaC out‑of‑the‑box; no code modifications are required. For other frameworks, developers must implement the CRaC Resource interface and handle resource cleanup in beforeCheckpoint() and reopening in afterRestore() .

Conclusion

Using CRaC dramatically shortens Spring Boot 3.2 application startup time, achieving up to a ten‑fold improvement with automatic checkpoints and even faster results with manual checkpoints, while preserving the ability to run on a standard JVM compared to GraalVM native images.

ps: The PIG micro‑service project already supports Spring Boot 3.2 and Spring Cloud 2023 – source code at https://gitee.com/log4j/pig
backendJavaperformanceSpring BootCheckpointCRaC
Selected Java Interview Questions
Written by

Selected Java Interview Questions

A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.