How Global Lazy Initialization Speeds Up Spring Boot Startup

About Lazy Loading

In Spring, by default all defined beans and their dependencies are created when the application starts and the container context is initialized. Example code:

@Slf4j
@Configuration
public class DemoConfig {
    public DemoConfig() {
        log.warn(">>> demoConfig initialized >>>");
    }
}

Application startup log shows that DemoConfig bean is initialized before Tomcat starts.

Usually many beans (data sources, caches) are initialized at startup, slowing the app. Before Spring Boot 2.2 we added @Lazy to beans to defer initialization until first use. The code becomes:

@Lazy
@Configuration
public class DemoConfig {}

Why Global Lazy Loading Is Needed

Manually adding @Lazy works only for beans we control. Third‑party starters (e.g., druid‑spring‑boot‑starter, spring‑boot‑starter‑data‑redis) inject beans automatically, and we cannot annotate them.

Spring Boot 2.2 introduced a global lazy‑initialization property; when enabled, all beans are lazy by default and created only when needed.

spring:
  main:
    lazy-initialization: true  # default false (off)

Individual beans can be excluded by setting @Lazy(false) to load at startup.

@Lazy(false)
@Configuration
public class DemoConfig {}

Alternatively, implement a LazyInitializationExcludeFilter to exclude specific bean types.

@Bean
LazyInitializationExcludeFilter integrationLazyInitExcludeFilter() {
    return LazyInitializationExcludeFilter.forBeanTypes(DemoConfig.class);
}

Issues with Global Lazy Loading

Enabling global lazy loading reduces startup time, but has two drawbacks:

First HTTP request processing time becomes longer because the required beans are created on demand.

Errors are not thrown during startup, making early detection harder.

Conclusion

Source code: spring-boot-course

Reference

spring-boot-course: https://github.com/lltx/spring-boot-course/tree/master/v2.3/global-lazy-init