skip to content

What is Project CRaC and what problem does it solve for JVM startup?

level: juniorimportance: should knowfreq 45%

answer

  1. Coordinated Restore At Checkpoint
  2. snapshot warmed-up running JVM to disk
  3. restore in milliseconds, keep full JIT throughput
  4. CRIU on Linux under the hood
  5. not native-image: real HotSpot JVM

basics

~10 s

CRaC (Coordinated Restore at Checkpoint) snapshots a fully warmed-up, running JVM to disk, then restores it later so the app starts in milliseconds instead of seconds — while keeping normal JVM speed.

solid answer

~40 s

Project CRaC (Coordinated Restore at Checkpoint) is an OpenJDK project that lets you take a checkpoint — a full snapshot of a running JVM process (heap, threads, JIT-compiled code) — to disk, then restore it into a new process almost instantly. It solves the JVM's slow-startup and warm-up problem: normally a Spring app spends seconds on class loading, bean initialization, and JIT warm-up before it runs at peak speed. With CRaC you warm the app up once, checkpoint it, and every restore skips all that, reaching peak throughput immediately. Unlike GraalVM native image, the restored process is a real HotSpot JVM, so you keep full JIT throughput and standard JVM tooling. On Linux it uses CRIU under the hood. Spring Boot 3.2+ integrates with it via the Lifecycle/SmartLifecycle mechanism.

code

java · 14 lines
java
// The JVM API lives in jdk.crac. A minimal manual checkpoint trigger:
import jdk.crac.Core;

public class CheckpointDemo {
    public static void main(String[] args) throws Exception {
        // ... app is started and warmed up here ...

        // Request a checkpoint of the whole JVM. Execution 'pauses' here;
        // on a later restore, code resumes right after this call.
        Core.checkpointRestore();

        System.out.println("Running after restore");
    }
}

go deeper

for a junior

Know the expansion (Coordinated Restore at Checkpoint) and the one-line value: snapshot a warmed JVM, restore fast.

for a middle

Should articulate the two costs solved (startup + JIT warm-up) and that restore keeps full throughput.

for a senior

Contrast crisply with native image (real HotSpot vs Substrate VM) and mention CRIU/Linux dependency.

for a principal

Frame the trade-off space: image portability, security of on-disk snapshots, and where CRaC fits vs native-image and vs plain JVM in an autoscaling strategy.

## What CRaC is **Project CRaC** stands for **Coordinated Restore at Checkpoint**. It is an OpenJDK project (and a corresponding JDK API in the `jdk.crac` package) that adds two operations to the JVM: - **Checkpoint** — freeze a running JVM process and write its entire state (the Java heap, thread stacks, loaded classes, and JIT-compiled native code) to a set of image files on disk. - **Restore** — start a brand-new process from those image files. The restored process resumes exactly where the checkpoint was taken, as if it had never stopped. ## The problem it solves A JVM application — especially a Spring Boot one — is slow to reach full speed for two separate reasons: 1. **Startup / initialization cost.** Class loading, classpath scanning, bean creation, auto-configuration, connection-pool setup — this takes seconds. 2. **Warm-up cost.** The **JIT (Just-In-Time) compiler** only optimizes ('compiles to native code') methods after they have run many times. Until then code runs interpreted and slow. Reaching peak throughput can take many more seconds or minutes of real traffic. CRaC lets you pay both costs **once**, at build/prepare time: you start the app, optionally push some traffic through it to warm the JIT, then take a checkpoint. Every later **restore** skips initialization AND arrives already JIT-warmed, so it hits peak throughput essentially from the first request. Restore times are typically tens of milliseconds. ## How it differs from native image GraalVM **native image** also gives fast startup, but it produces an ahead-of-time-compiled binary with a different runtime (Substrate VM), reduced peak throughput compared to a warmed JIT, and heavy build-time constraints (closed-world assumption, reflection config). **CRaC keeps a real HotSpot JVM** — full JIT, full throughput, standard tooling (JFR, agents, etc.). The trade-off is that a checkpoint image is Linux-specific and tied to CRIU. ## The 'Coordinated' part CRaC is *coordinated* because open resources (files, sockets, DB connections) cannot simply be frozen and later resumed — a socket held open across a checkpoint would be stale on restore. So CRaC notifies the application before checkpoint and after restore, giving code a chance to release and re-acquire resources. This is what the `jdk.crac.Resource` interface and Spring's lifecycle integration are for (covered in related questions). ## Under the hood On Linux, CRaC uses **CRIU (Checkpoint/Restore In Userspace)**, a Linux tool that snapshots process state. That is why CRaC checkpointing is Linux-only and why Docker/containers are the usual delivery vehicle. ## When to use it Use CRaC when you want native-image-like fast startup (serverless, scale-to-zero, fast autoscaling, fast rollouts) but cannot accept native-image's throughput penalty or build constraints, and you deploy on Linux.

  • Does the restored process still benefit from JIT optimization?
    Yes — that is the key advantage over native image. The checkpoint captures already-JIT-compiled native code, so the restored JVM runs at peak throughput immediately instead of warming up again.
  • Why is CRaC restricted to Linux?
    Because it relies on CRIU (Checkpoint/Restore In Userspace), a Linux-kernel-level facility for snapshotting process memory and state. There is no equivalent on macOS/Windows for the checkpoint step.

saying these in an interview costs you the question

  • Confusing CRaC with GraalVM native image (thinking it AOT-compiles to a native binary)
  • Claiming restore loses JIT optimization and must warm up again
  • Thinking checkpoints work identically on macOS/Windows

context

resolving links…