0Pricing
Spring Boot 4 Complete Guide · Lezione

Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM

Acceleri l’avvio in modalità JVM con CDS, inizializzazione lazy e ottimizzazione dell’istanziazione dei bean.

Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM è una lezione Spring Boot 4 Complete Guide gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Spring Boot 4 Complete Guide, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Spring Boot 4 Complete Guide include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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.

Domande Frequenti

La lezione «Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM» è gratuita?

Sì — il testo completo di «Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Spring Boot 4 Complete Guide, passa a CoddyKit PRO. Il corso Spring Boot 4 Complete Guide include 4 lezioni in totale.

Cosa imparerò in «Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM»?

Acceleri l’avvio in modalità JVM con CDS, inizializzazione lazy e ottimizzazione dell’istanziazione dei bean. Eserciti Spring Boot 4 Complete Guide con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Spring Boot 4 Complete Guide?

Non è richiesta alcuna esperienza precedente. Spring Boot 4 Complete Guide su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Spring Boot 4 Complete Guide?

Sì. Ogni lezione Spring Boot 4 Complete Guide include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Elaborazione AOT e pipeline di build nativa
  2. Runtime Hints per reflection e risorse
  3. Condivisione dei dati delle classi e ottimizzazione dell’avvio della JVM
  4. Diagnosi e risoluzione dei problemi di compatibilità nativa
← Torna a Spring Boot 4 Complete Guide