skip to content

What is Class Data Sharing (CDS) and how does it speed up Spring Boot startup?

level: juniorimportance: should knowfreq 35%

answer

  1. parsed class metadata dumped to .jsa
  2. memory-map instead of re-parse
  3. AppCDS = your classes too
  4. helps class loading, not JIT/throughput
  5. ~20-40% faster startup

basics

~20 s

CDS saves the classes the JVM loads into a shared archive file. On the next startup the JVM memory-maps that archive instead of reading and parsing each class from the jar, so class loading is faster and startup time drops.

solid answer

~40 s

Class Data Sharing (CDS) is a JVM feature that stores the internal, parsed representation of loaded classes in a shared archive file (a .jsa file). Normally, every JVM start re-reads each class from disk, verifies it, and builds the JVM's internal metadata. With CDS that pre-processed metadata is memory-mapped straight from the archive, skipping most of the per-class parsing and verification work. Application CDS (AppCDS) extends this from just JDK classes to your application's own classes. Spring Boot 3.3+ added first-class support ("Project CDS") via a training run that produces the archive for your app. Class loading is a big part of Spring Boot startup, so CDS typically cuts startup time by roughly 20-40%. It only speeds up class loading — it does not change runtime behavior, JIT warmup, or peak throughput.

code

java · 6 lines
java
// Not application code — the JVM flags express CDS.
// Runtime use of a pre-built archive:
//   java -XX:SharedArchiveFile=application.jsa -jar my-app.jar
//
// The .jsa holds the JVM's parsed representation of classes,
// memory-mapped at startup instead of re-read from the jar.

go deeper

for a junior

Know the one-line idea: dump loaded classes to an archive, memory-map it next time, startup gets faster.

for a middle

Distinguish base CDS (JDK classes) from AppCDS (your classes) and name .jsa plus the two key flags.

for a senior

Explain the parse/verify-once mechanism, cross-process page sharing, and that it targets only the class-loading slice of startup.

for a principal

Frame CDS as the low-risk, full-JVM startup lever versus heavier AOT/native paths, and reason about where the startup budget actually goes.

## What CDS is **Class Data Sharing (CDS)** is a HotSpot JVM feature. When the JVM loads a class it does real work: it reads the bytes from a `.class` file (often inside a jar), *verifies* the bytecode, and builds an in-memory data structure (the "class metadata") describing the class. CDS lets the JVM do that work **once**, dump the resulting metadata into a **shared archive file** (conventionally named with a `.jsa` extension — Java Shared Archive), and then on later starts **memory-map** that archive directly instead of redoing the parse/verify work per class. Memory-mapping means the OS maps the file's bytes into the process address space read-only; the JVM uses them in place. Because the mapping is read-only, multiple JVM processes on the same host can share the same physical memory pages for those classes. ## Base CDS vs AppCDS - **Base/default CDS** archives only **JDK/core library classes**. Modern JDKs ship a default archive and enable it automatically, so `java.lang.String` etc. are already shared. - **Application CDS (AppCDS)** extends the archive to include **your application's classes and third-party library classes** — the bulk of what a Spring Boot app loads at startup. This is where the meaningful Spring Boot win comes from. **Spring Boot 3.3** introduced convenience support (often called *Project CDS*) that makes generating an AppCDS archive for a Boot app a documented, repeatable workflow via a **training run**. ## Why it helps Spring Boot specifically A Spring Boot app loads thousands of classes during context refresh (auto-configuration, bean definitions, proxies, etc.). Class loading, verification, and metadata construction are a large fraction of cold startup time. CDS attacks exactly that fraction, commonly yielding **~20-40% faster startup** with essentially no code changes. ## What CDS does NOT do - It does **not** change runtime semantics — full reflection, dynamic proxies, and classpath scanning still work normally (unlike native images). - It does **not** improve steady-state throughput or JIT-compiled peak performance; it only reduces the class-loading portion of **startup**. - It does **not** dramatically cut heap usage, though the read-only mapped metadata can be **shared across processes**, reducing overall footprint on multi-instance hosts. ## Key flags (names to know) - `-XX:ArchiveClassesAtExit=app.jsa` — dynamically create the AppCDS archive when the JVM exits (the *training* step). - `-XX:SharedArchiveFile=app.jsa` — use an existing archive at runtime (the *production* step). - `-Xshare:on|auto|off` — force/allow/disable CDS. ## When to use it Use CDS when you want faster startup (autoscaling, serverless-ish cold starts, CI) but want to keep the ordinary JVM (full reflection, easy debugging, standard tooling) and avoid the complexity of GraalVM native images. It's a cheap, low-risk optimization: if the archive can't be used, the JVM simply falls back to normal loading.

  • Does CDS make my application run faster at peak load?
    No. CDS only speeds up class loading during startup. Once the app is warm, JIT-compiled code and steady-state throughput are unaffected — CDS is a startup optimization, not a throughput one.
  • What is the .jsa file?
    It's the Java Shared Archive: a file containing the JVM's internal, already-parsed-and-verified representation of a set of classes, which the JVM memory-maps at startup.

saying these in an interview costs you the question

  • Claiming CDS compiles code to native machine code (that's GraalVM native image, not CDS).
  • Saying CDS improves peak/steady-state throughput rather than startup.
  • Thinking CDS stores the .class bytes verbatim — it stores the JVM's parsed metadata representation.

context

resolving links…