0Pricing
Spring Boot 4 Complete Guide · Leçon

Partage des données de classes et optimisation du démarrage de la JVM

Accélérez le démarrage en mode JVM grâce à CDS, à l’initialisation différée et à l’optimisation de l’instanciation des composants.

Partage des données de classes et optimisation du démarrage de la JVM est une leçon Spring Boot 4 Complete Guide gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Spring Boot 4 Complete Guide, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Spring Boot 4 Complete Guide comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Why JVM Startup Still Matters

GraalVM native images give near-instant startup, but most teams still ship a regular JVM build for the vast majority of deployments. The JVM is easier to debug, supports full reflection, and works with every agent and library out of the box.

The good news: a JVM-mode Spring Boot 4 app does not have to be slow to start. Three levers move the needle the most:

  • Class Data Sharing (CDS) — skip re-parsing class metadata on every boot.
  • Lazy initialization — create beans only when first used.
  • Bean instantiation tuning — avoid expensive work in constructors and at refresh time.

This lesson walks through all three, in JVM mode, no native image required.

What Class Data Sharing Actually Does

When the JVM starts, it loads, parses, and verifies hundreds or thousands of classes. Class Data Sharing (CDS) writes the parsed in-memory class representation into a read-only archive file once, then memory-maps that archive on every subsequent start.

The payoff:

  • Less class loading and verification work per boot.
  • The archive can be shared across multiple JVM processes (same physical memory pages).

Two flavors matter for Spring Boot 4:

  • Dynamic CDS (AppCDS) — archive your application classes, not just the JDK ones.
  • Project Leyden / Ahead-of-Time cache — an evolution layered on CDS in newer JDKs.

Spring Boot 4's Built-in CDS Support

Spring Boot has first-class support for generating an AppCDS archive. You run the app once in a special training mode, it touches the application context, exits, and dumps an archive. Subsequent runs point the JVM at that archive.

The training run uses the special property below. It performs context refresh and then shuts down without serving traffic:

  • -Dspring.context.exit=onRefresh stops the app right after the context is ready.
  • The JVM flags -XX:ArchiveClassesAtExit capture the loaded classes.
# Step 1: training run - refresh context, then exit, dumping the archive
java -XX:ArchiveClassesAtExit=app.jsa \
     -Dspring.context.exit=onRefresh \
     -jar target/myapp.jar

# Step 2: every production start reuses the archive
java -XX:SharedArchiveFile=app.jsa \
     -jar target/myapp.jar

Layout Optimization with the CDS-Friendly Jar

A standard Spring Boot fat jar nests dependency jars inside it. CDS works best when classes live as plain files on a path the JVM can map directly. Spring Boot's tools layout extracts the app into a directory so CDS can index it cleanly.

Extract the runnable structure with the built-in jar mode, then run from the exploded layout:

  • -Djarmode=tools extract writes an application/ directory with a flat classpath.
  • Running from the exploded form makes both training and production starts faster and more reproducible.
# Explode the jar into a CDS-friendly directory structure
java -Djarmode=tools -jar target/myapp.jar extract --destination app

# Train against the exploded app
java -XX:ArchiveClassesAtExit=app/app.jsa \
     -Dspring.context.exit=onRefresh \
     -jar app/myapp.jar

# Production start
java -XX:SharedArchiveFile=app/app.jsa -jar app/myapp.jar

Verifying CDS Is Active

Always confirm the archive is actually being used; a typo in the path silently falls back to no CDS. Add class-load logging to see which classes come from the shared archive versus the regular classpath.

Use the diagnostic flag during a one-off check:

  • -Xlog:class+load:file=cds.log tags each class with shared when it loads from the archive.
  • Grep the log: a healthy archive shows the bulk of framework classes marked shared.
# Run with class-load logging and inspect the source of each class
java -XX:SharedArchiveFile=app/app.jsa \
     -Xlog:class+load:file=cds.log \
     -jar app/myapp.jar

# Count how many classes were served from the shared archive
grep -c 'source: shared objects file' cds.log

Lazy Bean Initialization

By default Spring eagerly instantiates every singleton bean during context refresh. With many beans, that work dominates startup. Lazy initialization defers each bean's creation until it is first injected or requested.

Turn it on globally with one property:

  • spring.main.lazy-initialization=true makes all beans lazy.
  • Trade-off: errors in a bean's wiring surface at first use instead of at boot, and the first request that touches a cold bean pays its construction cost.

Prefer it for short-lived CLI tasks and dev startup; be cautious in always-on services where a slow first request is worse than a slightly slower boot.

spring.main.lazy-initialization=true

Selective Laziness with @Lazy

Global laziness is blunt. Often you want most beans eager (so failures are caught at boot) but a few heavy beans lazy — a client that opens a slow connection, or a cache that pre-loads a large dataset.

Annotate the bean or the injection point with @Lazy. Spring then injects a proxy and instantiates the real bean on first call.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Lazy;

@Configuration
public class ReportingConfig {

    // Heavy bean: only built when something actually needs it
    @Bean
    @Lazy
    public ReportGenerator reportGenerator(DataWarehouse warehouse) {
        return new ReportGenerator(warehouse);
    }
}

Keep Bean Constructors Cheap

The single biggest self-inflicted startup wound is doing real work in constructors or @PostConstruct methods: opening connections, warming caches, calling remote services. All of it runs during refresh, serially, blocking startup.

Rules of thumb:

  • Constructors should only store collaborators, never perform I/O.
  • Defer expensive warm-up to an event that fires after the context is ready, or run it asynchronously.
  • Listen for ApplicationReadyEvent for warm-up that should not block the context from coming up.
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.context.event.EventListener;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;

@Component
public class CacheWarmer {

    private final ProductCache cache;

    public CacheWarmer(ProductCache cache) {
        // cheap: just hold the dependency
        this.cache = cache;
    }

    // Runs after startup, off the critical path
    @Async
    @EventListener(ApplicationReadyEvent.class)
    public void warmUp() {
        cache.preload();
    }
}

Background Bean Instantiation

Spring Boot can instantiate eligible beans on a background thread pool while the main thread continues refreshing. This parallelizes independent, slow-to-construct beans and shrinks wall-clock startup time.

Define a bootstrapExecutor bean; Spring uses it to construct beans that opt in, in the background. Beans with no dependency on those still proceed on the main thread.

import java.util.concurrent.Executor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

@Configuration
public class BootstrapConfig {

    // Spring detects a bean named 'bootstrapExecutor' for background init
    @Bean
    public Executor bootstrapExecutor() {
        ThreadPoolTaskExecutor exec = new ThreadPoolTaskExecutor();
        exec.setCorePoolSize(4);
        exec.setThreadNamePrefix("bg-init-");
        exec.initialize();
        return exec;
    }
}

Measuring Startup with the Startup Actuator

Don't guess where the time goes — measure. Spring Boot records a startup timeline of every step (bean instantiation, post-processing, auto-configuration) when you supply a BufferingApplicationStartup.

Wire it in main(), then read the buffered events from the /actuator/startup endpoint to find the slowest steps. Sort by duration and attack the top offenders first.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.metrics.buffering.BufferingApplicationStartup;

@SpringBootApplication
public class ShopApplication {

    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(ShopApplication.class);
        // capture up to 2048 startup steps for /actuator/startup
        app.setApplicationStartup(new BufferingApplicationStartup(2048));
        app.run(args);
    }
}

Putting It Together: A Tuned Startup Recipe

A realistic JVM-mode tuning pass for a Spring Boot 4 service combines the techniques in order of impact:

  • 1. Extract the jar (jarmode=tools extract) and generate an AppCDS archive with a training run.
  • 2. Apply @Lazy to a handful of genuinely heavy beans; keep the rest eager so config errors fail fast.
  • 3. Move all warm-up / I/O out of constructors into ApplicationReadyEvent listeners.
  • 4. Add a bootstrapExecutor if you have several independent slow beans.
  • 5. Use BufferingApplicationStartup to confirm each change helped.

The launch command then simply points at the archive:

java -XX:SharedArchiveFile=app/app.jsa \
     -Dspring.threads.virtual.enabled=true \
     -jar app/myapp.jar

Quick Check: Choosing the Right Lever

You have an always-on Spring Boot 4 web service. Profiling shows boot time is dominated by re-parsing and verifying framework classes on every restart, and a few requests hit beans that were never warmed. You want faster repeatable startup without risking that the first user request becomes noticeably slow.

Recap

JVM-mode Spring Boot 4 can start fast without going native. Key takeaways:

  • CDS memory-maps a pre-parsed class archive; create it with a training run (-XX:ArchiveClassesAtExit + spring.context.exit=onRefresh) and consume it with -XX:SharedArchiveFile. Extract the jar first for a CDS-friendly layout.
  • Lazy init defers bean creation: global via spring.main.lazy-initialization, or surgical via @Lazy. It trades fail-fast and first-request latency for a quicker boot.
  • Bean tuning: keep constructors cheap, move warm-up to ApplicationReadyEvent, and parallelize independent slow beans with a bootstrapExecutor.
  • Measure everything with BufferingApplicationStartup and /actuator/startup — tune the slowest steps, not your assumptions.

Questions Fréquemment Posées

La leçon « Partage des données de classes et optimisation du démarrage de la JVM » est-elle gratuite ?

Oui — le texte complet de « Partage des données de classes et optimisation du démarrage de la JVM » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Spring Boot 4 Complete Guide, passe à CoddyKit PRO. Le cours Spring Boot 4 Complete Guide comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Partage des données de classes et optimisation du démarrage de la JVM » ?

Accélérez le démarrage en mode JVM grâce à CDS, à l’initialisation différée et à l’optimisation de l’instanciation des composants. Tu pratiques Spring Boot 4 Complete Guide avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Spring Boot 4 Complete Guide ?

Aucune expérience préalable n'est requise. Spring Boot 4 Complete Guide sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Partage des données de classes et optimisation du démarrage de la JVM » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Spring Boot 4 Complete Guide ?

Oui. Chaque leçon Spring Boot 4 Complete Guide inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Traitement AOT et pipeline de compilation natif
  2. Indications d’exécution pour la réflexion et les ressources
  3. Partage des données de classes et optimisation du démarrage de la JVM
  4. Diagnostic et résolution des problèmes de compatibilité native
← Retour à Spring Boot 4 Complete Guide