Spring Bean Lifecycle

A Spring bean does not simply appear fully formed — the container walks it through a well-defined sequence of steps from instantiation to eventual destruction. Understanding this lifecycle matters whenever a bean needs to perform setup work after all its dependencies are injected (like opening a connection pool) or cleanup work before the application shuts down (like closing that pool).

Spring exposes several ways to hook into this lifecycle: the @PostConstruct and @PreDestroy annotations (the modern, framework-agnostic approach from Jakarta/Java EE), and the InitializingBean and DisposableBean interfaces (Spring's original, interface-based approach). Both accomplish the same goal, but differ in how tightly they couple your class to the Spring API.

The Full Lifecycle Sequence

In broad strokes, the container: (1) instantiates the bean by calling its constructor, (2) populates its properties via dependency injection, (3) calls any Aware interface methods (like BeanNameAware) if implemented, (4) invokes BeanPostProcessor "before initialization" callbacks, (5) calls the initialization callback (@PostConstruct or afterPropertiesSet()), (6) invokes BeanPostProcessor "after initialization" callbacks, and finally the bean is ready for use. On container shutdown, destruction callbacks (@PreDestroy or destroy()) run in reverse.

@PostConstruct and @PreDestroy

@PostConstruct marks a method to be run once, right after dependency injection is complete, making it the ideal place for setup logic that depends on injected collaborators being available. @PreDestroy marks a method to run just before the container destroys the bean (for singleton beans, this happens on graceful context shutdown). These annotations come from the Jakarta Annotations specification, not Spring itself, which keeps the annotated class portable across frameworks.

InitializingBean and DisposableBean

Implementing InitializingBean requires overriding afterPropertiesSet(), called at the same point in the lifecycle as @PostConstruct. Implementing DisposableBean requires overriding destroy(), called at the same point as @PreDestroy. These interfaces tie the class directly to Spring's API, which is why @PostConstruct/@PreDestroy are generally preferred in modern code — but the interface approach avoids any dependency on annotation processing and can be marginally faster since Spring checks the interface directly instead of scanning for annotations.

• @PostConstruct / @PreDestroy — annotation-based, framework-agnostic, the common modern choice.
• InitializingBean.afterPropertiesSet() / DisposableBean.destroy() — interface-based, tightly coupled to Spring.
• Prototype-scoped beans receive initialization callbacks but NOT destruction callbacks from the container automatically.

Example

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

class ConnectionPool implements InitializingBean, DisposableBean {

    @PostConstruct
    public void openPool() {
        System.out.println("1. @PostConstruct: pool opened");
    }

    @Override
    public void afterPropertiesSet() {
        System.out.println("2. InitializingBean: afterPropertiesSet");
    }

    @PreDestroy
    public void closePool() {
        System.out.println("3. @PreDestroy: pool closing");
    }

    @Override
    public void destroy() {
        System.out.println("4. DisposableBean: destroy");
    }
}

@Configuration
class AppConfig {
    @Bean
    public ConnectionPool connectionPool() {
        return new ConnectionPool();
    }
}

public class LifecycleDemo {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context =
            new AnnotationConfigApplicationContext(AppConfig.class);
        context.close(); // triggers destruction callbacks
    }
}

1. @PostConstruct: pool opened
2. InitializingBean: afterPropertiesSet
3. @PreDestroy: pool closing
4. DisposableBean: destroy

Exercise

Using the lesson's A bean using both @PostConstruct/@PreDestroy and the Spring lifecycle interfaces example, create a small implementation or design sketch that demonstrates Lifecycle order: construct, inject dependencies, run init callbacks, use the bean, run destroy callbacks on shutdown.. Add a test case or scenario that would catch Expecting @PreDestroy or destroy() to run for prototype-scoped beans — Spring does not track prototype beans after handing them out, so it never calls their destruction callbacks., and describe the expected result.

Quick quiz

Interview questions