Understanding Spring Bean Loading, Lifecycle, and BeanPostProcessor (Spring 5.0)

Spring is the core framework for many Java projects, and mastering how it loads beans is essential for developers. This article outlines the process of reading configuration files or annotations (e.g., @Component, @Service, @Scope) and converting them into BeanDefinition objects, which are then registered in a ConcurrentHashMap within DefaultListableBeanFactory.

The bean lifecycle is divided into four main phases: instantiation, property population, initialization, and destruction. Instantiation creates an object via reflection; property population fills dependencies (including handling @Autowired and potential circular references); initialization runs custom logic such as InitializingBean.afterPropertiesSet and post‑processors; finally, destruction occurs when the container shuts down.

Spring allows developers to customize bean creation through the BeanPostProcessor interface. Various callbacks— postProcessBeforeInstantiation, postProcessAfterInstantiation, postProcessBeforeInitialization, and postProcessAfterInitialization —enable injection of additional behavior before and after the standard lifecycle steps, and are also used by Spring AOP.

Key issues discussed include the difference between FactoryBean (a bean that produces other objects) and BeanFactory (the core IoC container), as well as Spring's three‑level cache mechanism ( singletonObjects, earlySingletonObjects, singletonFactories) that resolves circular dependencies by promoting beans through the caches.

To illustrate these concepts, the article provides a test class with a custom bean and a TestBean that implements BeanPostProcessor, SmartInitializingSingleton, InstantiationAwareBeanPostProcessor, and DisposableBean. The code logs each callback, demonstrating the order of execution during container startup and shutdown.

In summary, the blog gives a high‑level overview of Spring's bean loading process, emphasizing the main steps without delving into low‑level source details, and encourages readers to use this framework as a model for studying complex open‑source code.