Spring Boot 4 Complete Guide · 강의

클래스 데이터 공유 및 JVM 시작 성능 조정

CDS, 지연 초기화 및 빈 인스턴스화 조정을 활용해 JVM 모드의 시작 속도를 높입니다.

레슨 3/413개 단계

클래스 데이터 공유 및 JVM 시작 성능 조정은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

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.

무료로 시작

AI 튜터와 함께 Java을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 21
레슨: 84

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“클래스 데이터 공유 및 JVM 시작 성능 조정” 강의는 무료인가요?

네 — “클래스 데이터 공유 및 JVM 시작 성능 조정” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“클래스 데이터 공유 및 JVM 시작 성능 조정”에서 뭘 배우나요?

CDS, 지연 초기화 및 빈 인스턴스화 조정을 활용해 JVM 모드의 시작 속도를 높입니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Boot 4 Complete Guide은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“클래스 데이터 공유 및 JVM 시작 성능 조정” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Boot 4 Complete Guide 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Spring Boot 4 Complete Guide(으)로 돌아가기