How does Spring Boot 3.2+ integrate with CRaC, and how do you trigger an automatic checkpoint?

## The moving parts There are three layers involved: 1. **The JDK** must be a **CRaC-enabled build** (e.g. Azul Zulu with CRaC, BellSoft Liberica with CRaC). A stock JDK has no checkpoint support. 2. **The `org.crac` library** (`org.crac:crac`) — a thin, portable façade over the `jdk.crac` API. Frameworks compile against `org.crac` so they build on any JDK; at runtime it delegates to the real `jdk.crac` if present, otherwise no-ops. Spring depends on this. 3. **Spring's integration** — Spring Framework 6.1+ registers a global CRaC `Resource` and wires checkpoint/restore into its `Lifecycle` machinery. ## What Spring does on checkpoint and restore Spring's `ApplicationContext` already manages **`Lifecycle`** and **`SmartLifecycle`** beans (things that can be `start()`ed and `stop()`ped: message listener containers, task schedulers, the web server, etc.). When a checkpoint is requested, Spring: - **Before checkpoint**: calls `stop()` on lifecycle beans (in reverse phase order). This pauses schedulers, stops listener containers, and lets components release resources they can't safely hold across a snapshot. - **After restore**: calls `start()` again, resuming everything. Beans that need finer control implement the `org.crac.Resource` interface directly (`beforeCheckpoint`/`afterRestore`) — covered in the resource-handling question. ## Two ways to take the checkpoint ### 1. Automatic checkpoint on refresh Set the property: ``` -Dspring.context.checkpoint.restore=onRefresh ``` With this, Spring initializes the whole `ApplicationContext` (all beans created, auto-config done) and then **immediately triggers a checkpoint right after context refresh, before the embedded web server begins accepting requests**. The resulting image is a fully-initialized application that has not served any traffic. Benefit: deterministic, easy to bake into a Docker build. Limitation: because no traffic has flowed, the **JIT is not warmed** — you get fast startup but not the peak-throughput-from-first-request benefit. > Note: this property historically was `spring.context.checkpoint.restore`; in newer versions the automatic-checkpoint value is `onRefresh`. The checkpoint itself is still performed by running the JVM with `-XX:CRaCCheckpointTo=<dir>`. ### 2. On-demand checkpoint (warmed) Start the app normally with `-XX:CRaCCheckpointTo=<dir>`, drive real or synthetic load to warm the JIT, then from outside trigger: ``` jcmd <pid> JDK.checkpoint ``` The JVM writes the image and exits. This image is **JIT-warmed**, so restore reaches peak throughput immediately — the fullest expression of CRaC's value. The cost is a more involved build pipeline (you must run a representative workload during the build). ## Restoring Regardless of how the checkpoint was made, restore with: ``` java -XX:CRaCRestoreFrom=<dir> ``` No main class or classpath is needed — everything is in the image. Spring runs its `afterRestore` handling and the app is serving within milliseconds. ## Gotchas - **Open resources must be closed before checkpoint.** An open socket or DB connection held across a checkpoint will be invalid on restore. CRaC even fails the checkpoint if it detects certain open file descriptors, forcing you to handle them. - **Secrets and randomness.** State captured at checkpoint (loaded config, in-memory secrets, RNG seeds) is duplicated across every restored instance — a security consideration. - **The image contains your heap.** Anything sensitive in memory is on disk; protect the image files. - **Time and identity.** System time jumps and the process starts fresh; anything caching 'now' or a startup timestamp may be stale.