How SpringBoot Loads Classes: Deep Dive into ClassLoaders and Bean Creation

Interview Intent and Answer Framework

The interview question "How does SpringBoot load classes?" tests three core abilities: basic knowledge of class‑loader mechanisms versus Spring bean loading, depth of understanding of SpringBoot's modification to the parent‑delegation model, and the ability to relate the theory to real‑world problems such as dependency conflicts, bean initialization errors, and hot‑deployment.

Two‑Layer Loading Model

SpringBoot class loading consists of two distinct layers:

JVM Class‑Loader Layer : The standard parent‑delegation hierarchy (Bootstrap → Extension → Application) loads core JDK classes. SpringBoot introduces a custom loader that can load application classes and third‑party JARs before delegating to the parent.

Spring Container Layer : After classes are loaded, Spring parses them into BeanDefinition objects and creates beans, adding an auto‑configuration step that is unique to SpringBoot.

Custom Class Loaders

LaunchedURLClassLoader (Fat‑Jar scenario) : Scans BOOT-INF/classes and BOOT-INF/lib. It first attempts to load a class from these paths; if not found, it delegates to the parent. This solves version‑conflict problems (e.g., Guava‑19 from Tomcat vs. Guava‑31 from the application) by keeping the two versions in separate class‑loader namespaces.

RestartClassLoader (DevTools hot‑deployment) : Creates a second loader for frequently changed business classes. When a class changes, the loader is destroyed and recreated, allowing the updated class to be reloaded without restarting the whole JVM.

Bean Loading Process

SpringBoot ultimately follows the standard Spring bean lifecycle:

public static void main(String[] args) {
    SpringApplication.run(MyApp.class, args);
}

The SpringApplication.run() call triggers AbstractApplicationContext.refresh(), which can be broken down into three phases:

Preparation : Set startup timestamps, create a fresh BeanFactory, and configure basic properties such as the class loader.

Infrastructure Initialization : Initialize the message source, event multicaster, and invoke any subclass‑specific hooks (e.g., embedded Tomcat startup).

Bean Instantiation : Register BeanFactoryPostProcessor (especially ConfigurationClassPostProcessor) to parse @Configuration, @ComponentScan, @Import, and @Bean definitions, then register BeanPostProcessor implementations, and finally instantiate all non‑lazy singleton beans following a topological order based on dependencies.

The bean creation steps are:

Instantiate (call constructor)

Populate properties (process @Autowired, @Value)

Apply BeanPostProcessor before initialization (e.g., @PostConstruct)

Invoke initialization callbacks ( InitializingBean.afterPropertiesSet or custom init‑method)

Apply BeanPostProcessor after initialization (AOP proxy creation)

Place the fully initialized bean into the singleton cache

Common Pitfalls

Confusing class loading with bean creation (e.g., describing LaunchedURLClassLoader as a bean).

Claiming SpringBoot completely breaks parent delegation while ignoring that core JDK classes still follow the original model.

Providing a pure procedural answer without linking to practical issues such as dependency isolation or hot‑deployment.

Advanced Control Techniques

@DependsOn("beanName")

forces a bean to be created after another. @Order or implementing Ordered controls the execution order of BeanPostProcessor and other extension points.

SpringBoot‑specific annotations @AutoConfigureBefore / @AutoConfigureAfter dictate the loading order of auto‑configuration classes.

Implementing SmartInitializingSingleton runs custom logic after all singleton beans are instantiated.

Observability

Enable DEBUG logging for org.springframework to see bean definition registration, bean instantiation, and post‑processor execution. For finer‑grained tracing, a custom BeanPostProcessor can log before and after each bean's initialization.

Key Takeaway

SpringBoot modifies the JVM class‑loader hierarchy only where flexibility is needed (application classes and third‑party libs) while preserving the safety of core JDK classes. This hybrid approach resolves version‑conflict and hot‑deployment challenges without compromising Java’s security model, and it seamlessly integrates with Spring’s well‑structured bean lifecycle.