Java - Java Class Data Sharing (CDS) and AppCDS
Introduction
Java applications often spend a noticeable amount of time loading class metadata into memory during startup. Every Java program depends on numerous classes from the Java Standard Library and application-specific libraries. Each time a Java application starts, the Java Virtual Machine (JVM) reads these classes, verifies them, prepares metadata, and stores the information in memory. Although this process is necessary, it increases startup time and consumes additional memory, especially when multiple Java applications are running on the same system.
Class Data Sharing (CDS) is a JVM feature that improves application startup performance and reduces memory usage by allowing multiple Java processes to share preprocessed class metadata. Instead of loading and preparing common classes every time an application starts, the JVM can use a pre-created archive containing class information.
Application Class Data Sharing (AppCDS) extends this concept by allowing developers to include their own application classes and third-party libraries in the shared archive, providing even greater performance improvements.
What is Class Data Sharing (CDS)?
Class Data Sharing (CDS) is a feature introduced in the HotSpot JVM that stores commonly used class metadata in a shared archive file. When an application starts, the JVM loads class information directly from this archive instead of recreating it from scratch.
This reduces:
-
JVM startup time
-
Memory consumption
-
CPU usage during startup
The shared archive can be used by multiple Java processes running on the same machine.
Why is CDS Needed?
Consider a system where several Java applications are running simultaneously.
Without CDS:
-
Every application loads Java core classes independently.
-
Each JVM creates its own copy of metadata.
-
More RAM is consumed.
-
Startup becomes slower.
With CDS:
-
Core class metadata is stored once.
-
Multiple JVM processes share the same archive.
-
Startup becomes faster.
-
Overall system memory usage decreases.
Understanding Class Metadata
When Java loads a class, the JVM stores information such as:
-
Class name
-
Package information
-
Fields
-
Methods
-
Constructors
-
Interfaces
-
Annotations
-
Constant pool
-
Method bytecode references
This information is called class metadata.
Instead of rebuilding this metadata every time, CDS stores it inside an archive.
How CDS Works
The process follows several steps.
Step 1: JVM Loads Classes
During the first execution, Java loads all required system classes.
Example:
String
Object
ArrayList
HashMap
Scanner
Math
Integer
Thread
Step 2: Metadata is Prepared
The JVM verifies each class.
It checks:
-
Bytecode correctness
-
Security rules
-
Symbol resolution
-
Internal data structures
Step 3: Archive Creation
The processed metadata is stored inside a shared archive file.
Example:
classes.jsa
The archive contains only metadata—not application data or object instances.
Step 4: Future JVM Starts
Next time the application starts:
JVM
↓
Open Shared Archive
↓
Load Metadata
↓
Start Application Faster
No repeated processing is required.
What is Stored in the Archive?
The archive generally contains:
-
Class metadata
-
Method information
-
Constant pools
-
Symbol tables
-
Internal JVM structures
-
Loaded system classes
It does not store:
-
Objects
-
Variables
-
Application data
-
Heap memory
-
User input
What is AppCDS?
Originally CDS shared only Java system classes.
Application Class Data Sharing (AppCDS) allows developers to include:
-
Application classes
-
External libraries
-
Framework classes
Examples:
MyApplication.class
Student.class
Employee.class
Customer.class
Framework libraries like:
Spring
Hibernate
Jackson
Apache Commons
Log4j
can also become part of the archive.
Difference Between CDS and AppCDS
| CDS | AppCDS |
|---|---|
| Shares Java system classes | Shares application classes |
| Automatically available | Archive must be created |
| Improves JVM startup | Improves complete application startup |
| Uses standard library classes | Includes project-specific classes |
| Requires minimal configuration | Requires archive generation |
CDS Architecture
Java Application
|
Java Virtual Machine
|
Shared Archive (classes.jsa)
-------------------------
Java Core Classes
Metadata
Constant Pools
Method Information
Symbol Tables
-------------------------
|
Shared Among JVM Processes
Creating a CDS Archive
A JVM archive can be created using the Java command.
Example:
java -Xshare:dump
This generates the default shared archive.
The archive is commonly stored as:
classes.jsa
Using the Shared Archive
Applications can use the archive during startup.
Example:
java -Xshare:on MyProgram
The JVM loads metadata from the archive instead of preparing it again.
Creating an AppCDS Archive
For application classes, developers first collect the list of loaded classes.
Example:
java -XX:DumpLoadedClassList=classes.lst MyProgram
This creates:
classes.lst
Next, generate the archive.
Example:
java
-XX:SharedClassListFile=classes.lst
-XX:SharedArchiveFile=app.jsa
-Xshare:dump
Finally, run the application using:
java
-Xshare:on
-XX:SharedArchiveFile=app.jsa
MyProgram
The JVM loads both Java system classes and application classes from the archive.
Benefits of CDS
Faster Startup
The JVM skips repeated class verification and metadata creation.
Applications become ready much faster.
Lower Memory Usage
Shared metadata is stored once.
Multiple JVM processes use the same memory pages.
This significantly reduces RAM usage.
Reduced CPU Utilization
Class loading requires CPU time.
CDS minimizes repeated processing.
Better Cloud Performance
Cloud platforms frequently start and stop containers.
CDS helps reduce startup latency.
This is especially useful for:
-
Docker
-
Kubernetes
-
Serverless deployments
Improved Scalability
When hundreds of JVM instances run simultaneously, CDS reduces both memory consumption and startup overhead.
Practical Example
Suppose a server hosts five Java applications.
Without CDS:
Application A
↓
Loads String
Loads Object
Loads HashMap
Creates Metadata
Consumes Memory
The same process repeats independently for Applications B, C, D, and E.
Total memory usage becomes much higher.
With CDS:
Shared Archive
↓
String
Object
HashMap
↓
Application A
Application B
Application C
Application D
Application E
All applications reuse the same metadata.
Real-World Use Cases
CDS is commonly used in:
-
Enterprise Java applications
-
Microservices
-
Spring Boot applications
-
Banking systems
-
Insurance software
-
Healthcare platforms
-
Cloud-native applications
-
Large-scale web servers
-
Continuous Integration (CI) environments
-
Containerized deployments
Limitations of CDS
Although CDS offers many benefits, it has some limitations.
-
The archive is JVM-version specific and generally cannot be reused across different Java versions.
-
Changes to application classes require regeneration of the AppCDS archive.
-
It primarily optimizes startup and memory usage; it does not directly improve business logic execution speed.
-
Dynamic class generation at runtime (such as some proxy classes or bytecode-generated classes) may not benefit from AppCDS.
Best Practices
-
Enable CDS for production environments where applications start frequently.
-
Use AppCDS for applications with many custom classes or large third-party libraries.
-
Regenerate the archive after significant code or dependency changes.
-
Benchmark startup time and memory usage before and after enabling CDS to measure improvements.
-
Combine CDS with other JVM optimizations, such as appropriate garbage collection settings, for better overall performance.
Summary
Java Class Data Sharing (CDS) is a JVM optimization feature that stores processed class metadata in a shared archive so that multiple Java applications can reuse it. This reduces startup time, lowers memory usage, and decreases CPU overhead during application initialization. Application Class Data Sharing (AppCDS) extends this capability to include application-specific and third-party library classes, making it particularly valuable for enterprise applications, cloud deployments, and microservices. By minimizing repeated class-loading work, CDS and AppCDS help Java applications start faster and use system resources more efficiently.