The container instantiates the bean (constructor call), injects dependencies (constructor/setter/field), calls Aware interface callbacks if implemented (e.g., BeanNameAware), runs BeanPostProcessor.postProcessBeforeInitialization, calls initialization callbacks (@PostConstruct, then InitializingBean.afterPropertiesSet(), then a custom init-method), runs BeanPostProcessor.postProcessAfterInitialization, and the bean is now ready for use — until container shutdown triggers @PreDestroy, DisposableBean.destroy(), and any custom destroy-method, in that order.

Intermediate5 min

AccentureCapgeminiCognizantOracleIBMAmazon

#Bean Lifecycle

What is the lifecycle of a Spring bean, from instantiation to destruction?

Why Injection Happens Before Initialization Callbacks

@PostConstruct methods are guaranteed to run only after all dependencies have already been injected — this ordering guarantee is exactly what makes it safe to use injected fields inside a @PostConstruct method, whereas using them inside the constructor itself would be unsafe if any dependency is injected via setter rather than constructor.

Instantiate → inject deps → Aware callbacks → BeanPostProcessor (before) → init callbacks → BeanPostProcessor (after) → ready → @PreDestroy

Lifecycle Callbacks

java

@Component
class CacheWarmer {
    @PostConstruct
    void warmUp() { /* runs after injection completes */ }

    @PreDestroy
    void cleanup() { /* runs on graceful container shutdown */ }
}