MediumExperience level: 3-5 years · 8-15 years3 min read

Class-Data Sharing (CDS/AppCDS) — Interview Questions

Reviewed by Gurusankar M.

Asked inAmazonGoogle
#cds#appcds#startup time#cold start#containers
Report issue

Short Answer

Every JVM start normally has to parse and verify the bytecode of every class it loads, including java.lang.String and the rest of the core library, from scratch. Class-Data Sharing pre-parses core-library classes once into a shareable archive file that the JVM can memory-map directly on subsequent starts, skipping that parsing/verification work; AppCDS extends the same mechanism to your own application and third-party library classes. The practical payoff is faster startup and lower memory (the archive can be shared across JVM processes on the same machine) — which matters far more for short-lived containers and serverless functions, where startup time is a direct cost, than for a long-running server where a slower start is a one-time, amortized expense.

On this page

Concept Made Simple

Coffee Chat Question

“How does Class-Data Sharing (CDS/AppCDS) cut JVM startup time, and why does it matter for containers and serverless?”

Remember It Faster

Mind Map Answer

CDS attacks a cost that's easy to overlook when you're used to long-running servers: class loading and verification is real, repeated work the JVM redoes on every single process start, for the same core classes every time. A pre-built, memory-mapped archive turns that repeated parse into a fast mmap.

CDS (base)
Shares core JDK class metadata via a pre-built archive
AppCDS
Extends sharing to your app + library classes
Dynamic CDS
Auto-generates the app archive at JVM exit — less manual setup
Matters most for
Containers/serverless — many short-lived JVM starts

Key takeaway: CDS is a startup/memory optimization, not a throughput one — it doesn't make a long-running service faster once it's warmed up, it makes getting to 'started' faster and cheaper, which is exactly the cost that dominates in scale-to-zero, per-request-cold-start environments.

Learn by Doing

Hands-on Keyboard

bash
# Dynamic CDS (JDK 13+): generate an app-class archive automatically at exit
java -XX:ArchiveClassesAtExit=app-cds.jsa -jar app.jar

# Reuse the archive on subsequent starts for faster startup
java -XX:SharedArchiveFile=app-cds.jsa -jar app.jar

# Base CDS is on by default in modern JDKs for core classes;
# AppCDS/dynamic CDS is what you opt into for your own application classes.

Think Beyond the Expected

What If?

Does CDS help a long-running microservice the same way it helps a serverless function?

It still shaves real time off startup either way, but the impact is proportionally much smaller for a service that runs for hours or days — the one-time startup cost is amortized. For a serverless function or an autoscaling pod that starts fresh per invocation or per scale-up event, that same fixed startup cost is paid repeatedly and directly affects cold-start latency and cost.

Real World

Teams moving Java workloads to Lambda, Cloud Run, or Kubernetes with aggressive autoscaling specifically chase startup time because it's on the critical path for user-facing latency (cold start) or billed compute time — CDS/AppCDS is one of the lower-effort levers available before reaching for heavier options like GraalVM Native Image, and Spring Boot's own CDS support exists precisely because of this pressure.

Real Talk from Guru

I'd frame CDS as 'the JVM startup optimization you get for a config flag, before you consider Native Image.' It's a good sign of practical cloud-native Java awareness if a candidate brings it up unprompted when discussing container startup latency.

Interviewer's Expectation

Keywords they're listening for:

  • Explains CDS pre-parses/shares class metadata to skip repeated work
  • Distinguishes base CDS (JDK classes) from AppCDS (app classes)
  • Connects the benefit specifically to startup time, not steady-state throughput
  • Names containers/serverless as the environments where this matters most

Common Mistakes

  • Assuming CDS speeds up steady-state throughput, not just startup
  • Not knowing the difference between base CDS and AppCDS
  • Overlooking CDS in favor of jumping straight to Native Image

Best Practices

  • Enable dynamic CDS for app classes on startup-sensitive deployments
  • Measure actual cold-start improvement before adding complexity
  • Consider CDS before reaching for Native Image's larger trade-offs

Follow-up Questions

  1. How does dynamic CDS differ from the older, more manual AppCDS workflow?
  2. How does CDS compare to GraalVM Native Image for solving the same cold-start problem?
  3. Why can a CDS archive be shared in memory across multiple JVM processes on the same host?

Continue Learning with AI

Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.

Plain-language foundations

I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner.

Topic: Troubleshooting (JVM)
Interview question: "How does Class-Data Sharing (CDS/AppCDS) cut JVM startup time, and why does it matter for containers and serverless?"

Please:
1. Explain the core idea in simple, plain language, using an everyday analogy.
2. Define any technical terms you use.
3. Walk through one small, concrete example.
4. Finish with a single sentence I can easily remember.

Keep the tone friendly and assume I'm new to this topic.
Open inChatGPTGeminiClaude

Was this answer helpful?

Affiliate links

Tools for Your Developer Workspace

Equipment for a comfortable, productive setup.

As an Amazon Associate I earn from qualifying purchases.