Free tools Windows power users keep installed
One-click scans. No signup required.
To restore a Spring Boot service from a CRaC checkpoint, first run it on a CRaC-enabled JVM, warm it with representative requests, and create a checkpoint. Package that checkpoint with the application, then start the runtime JVM by restoring from the checkpoint directory. Spring Boot 3.2 introduced initial support for JVM checkpoint and restore; the current Spring Framework reference lists Linux, a checkpoint-enabled JVM, and org.crac:crac 1.4.0 or newer as requirements.
This part of the Spring Boot 3.2 and CRaC workflow focuses on creating checkpoints on demand, warming the application deliberately, and handling configuration that may differ between image build and runtime. CRaC restores a saved running JVM, not merely a compiled application, so the checkpoint’s usefulness depends on the work completed before it is made.
What the on-demand checkpoint and restore workflow does
CRaC saves the state of a running JVM so that a later JVM can resume from that state instead of performing all initialization from scratch. In a Spring Boot service, the practical sequence is:
- Start the application on a JVM that supports CRaC, in an environment where the application can initialize successfully.
- Warm it with representative requests. Exercise important endpoints and dependencies so relevant classes are loaded and the JIT compiler has an opportunity to optimize code.
- Request a checkpoint. The tutorial’s on-demand script invokes
jcmd app.jar JDK.checkpointafter its warmup requests. - Package the checkpoint and application. The tutorial uses a multi-stage Dockerfile: a builder stage runs the warmup and checkpoint workflow, and the runtime stage copies the checkpoint and JAR into the image.
- Restore in the runtime environment. The image’s Java entry point starts the JVM by restoring from the checkpoint directory.
OpenJDK CRaC documentation describes restore as generally faster than initialization. Spring’s documentation says that a checkpoint created on a warmed-up JVM can leave the restored JVM equally warmed-up, allowing “potentially peak performance immediately.” Neither statement guarantees a particular startup time or performance level for every service.
What you need before creating a checkpoint
The current Spring Framework JVM Checkpoint Restore documentation identifies these requirements for its documented route:
- A Linux environment.
- A JVM built with checkpoint/restore support.
- The
org.crac:cracdependency at version 1.4.0 or newer.
Spring Boot 3.2 added initial JVM checkpoint/restore support; it does not make an ordinary JVM checkpoint-capable. Select and verify a compatible runtime for both checkpoint creation and restore. The Callista Enterprise tutorial’s Docker example uses Azul Zulu OpenJDK 21.0.3-21.34 with CRaC. That is the version used in that example, not a general recommendation for current deployments.
Warm the service before checkpointing
The tutorial creates a service-specific checkpoint-on-demand.bash script. It waits for the service, sends repeated requests to a service endpoint, and then invokes jcmd app.jar JDK.checkpoint. Its sample warmup is explicitly basic; a production warmup should reflect the actual service rather than merely prove that one endpoint responds.
Rank #2
Choose representative requests
Exercise the code paths that matter to users and to the service’s first work after restore. Consider the routes, serializers, validation, database access, and other integrations that the service normally needs. A checkpoint cannot preserve useful warmup for a path the application never exercised. Verify the responses and expected side effects, too: a request that fails early may not warm the path you intended.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check lifecycle behavior before saving state
Spring’s documented on-demand lifecycle stops running beans before checkpoint and starts them again after restore. Spring-managed lifecycle callbacks help coordinate that transition, but non-Spring libraries may need to implement org.crac.Resource so they can prepare for checkpoint and restore. Review files, sockets, active threads, and other external resources rather than assuming they remain valid across the pause.
Scheduled work needs particular care. A fixed-rate task can run missed executions after restore. Spring recommends fixed-delay or cron scheduling when that catch-up behavior is not wanted. Choose the schedule based on the job’s semantics, and verify behavior across the checkpoint boundary.
Build an image that restores the checkpoint
The tutorial separates checkpoint creation from runtime restoration with a multi-stage Docker image. The builder stage receives the JAR and the service-specific warmup/checkpoint script, runs the application and warmup, and produces the checkpoint. The runtime stage copies the JAR and checkpoint into the final image and configures Java to restore from the checkpoint directory.
This division matters: the checkpoint is produced from a running process, while the final image must include the saved state and the application artifacts needed by the restored process. The tutorial’s runtime image uses the same CRaC-enabled JDK family as its example builder. Adapt image contents and runtime settings to the exact JDK and deployment environment you operate; the example version should not be mistaken for a compatibility guarantee across arbitrary JVM builds.
Handle settings that differ between build and runtime
A checkpoint contains process state, including values read while the application was running in the builder environment. If hostnames, ports, or database credentials differ in production, decide explicitly which settings can be refreshed and which resources must be recreated or reconfigured.
Rank #4
The tutorial uses Spring Cloud Context Refresh for selected runtime configuration. It describes @RefreshScope for application properties, spring.cloud.refresh.extra-refreshable for selected library beans, and spring.config.import to load an external runtime configuration file. Its examples cover service host and port plus SQL datasource URL and credentials. These mechanisms and their behavior depend on the exact Spring Cloud and library versions, so verify them in the versions used by your service; they are not a blanket guarantee that every bean or connection will adopt runtime settings.
MongoClient limitation in the example
The tutorial closes its MongoClient before checkpointing to avoid open-port errors. It then reports that the restored client still uses build-time configuration. Its workaround is to use the runtime hostname during image build and resolve that name to localhost in the builder’s network context. That is a workaround for the demonstrated setup, not evidence that arbitrary MongoClient configuration is refreshed successfully after restore. Treat Mongo connection configuration as a specific compatibility and lifecycle problem to validate in your deployment.
Interpret the reported startup times carefully
Callista Enterprise’s 2024 tutorial prints the following restored-JVM values in its own Compose example:
Best Value
| Service in the example | Printed restored-JVM value | Attribution and context |
|---|---|---|
| Product | 127 ms | Callista Enterprise, 2024 tutorial example log |
| Recommendation | 133 ms | Callista Enterprise, 2024 tutorial example log |
| Product Composite | 155 ms | Callista Enterprise, 2024 tutorial example log |
| Review | 183 ms | Callista Enterprise, 2024 tutorial example log |
These are sample values printed by that tutorial’s Compose environment, not universal startup times or results of a controlled comparison. The article does not establish a comparison with cold initialization, native images, CDS, or another startup technique. For a meaningful deployment decision, measure the same application in the same environment, separating cold initialization from restored startup and time-to-first-operation from readiness. Record which endpoints were warmed and the size and build-and-shipping cost of the checkpoint.
Protect checkpoint images as sensitive artifacts
A checkpoint represents running JVM memory. It can contain any sensitive values the process has seen, including environment-derived configuration. Protect checkpoint files and images during storage, transfer, access, and retention as carefully as other artifacts containing application secrets. Limit who can retrieve them and avoid treating a checkpoint as harmless build output.
When this approach fits
CRaC is most useful to evaluate when reducing initialization work is important and you can reliably create, distribute, secure, and restore a checkpoint in the target environment. Its benefit depends on the application’s startup work, the quality of warmup, the resources it uses, and the operational cost of building and shipping checkpoint state.
Quick Recap
- Use a checkpoint only after the warmup has exercised meaningful application paths.
- Validate lifecycle handling for every important resource and scheduled task.
- Test runtime configuration and external connections in the exact framework, library, and JDK versions you deploy.
- Measure restored startup, readiness, and first useful operation separately before comparing approaches.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
