Bean Lifecycle

#Introduction

One of the most important Spring interview topics. Almost every senior-level interviewer asks some variation of: Explain the Spring bean lifecycle. When is @PostConstruct called? When is @PreDestroy called? What's the difference between BeanFactoryPostProcessor and BeanPostProcessor? What are bean scopes? What is a singleton bean? How are prototype beans destroyed? What happens internally when Spring starts?

Understanding the bean lifecycle explains how Spring creates, initializes, manages, proxies and destroys every bean.

#What is a Spring Bean?

A bean is simply an object that is created by Spring, managed by Spring and stored inside the IoC container.

@Service
public class UserService {
}

#Complete Bean Lifecycle

#Step 1 — BeanDefinition Creation

Spring scans your project for @Component, @Service, @Repository, @Controller and @Configuration classes. Each discovered bean becomes a BeanDefinition, which stores metadata such as the bean class, name, scope, lazy/eager initialization, constructor information and lifecycle callbacks. No object has been created yet.

#Step 2 — Bean Instantiation

Spring creates the object — internally like UserService service = new UserService();. The object exists, but dependencies aren't injected yet (except constructor arguments).

#Step 3 — Dependency Injection

@Autowired
private UserRepository repository;

#Step 4 — Aware Interfaces

If a bean implements an Aware interface, Spring injects framework objects:

public class UserService implements BeanNameAware {

    @Override
    public void setBeanName(String name) {
        System.out.println(name);
    }
}

Common Aware interfaces: BeanNameAware, BeanFactoryAware, ApplicationContextAware, EnvironmentAware and ResourceLoaderAware. These are mainly used by framework developers and advanced infrastructure components.

#Step 5 — BeanPostProcessor (Before Initialization)

Spring calls postProcessBeforeInitialization():

@Component
public class MyProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        return bean;
    }
}

This runs before the bean's init callbacks.

#Step 6 — @PostConstruct

One of the most asked interview questions.

@Service
public class UserService {

    @PostConstruct
    public void init() {
        System.out.println("Bean Initialized");
    }
}

Called once, after bean creation and dependency injection. Perfect for loading caches, reading configuration, opening connections (if appropriate) and initializing in-memory data.

#Step 7 — InitializingBean

public class UserService implements InitializingBean {

    @Override
    public void afterPropertiesSet() {
    }
}

afterPropertiesSet() runs after @PostConstruct. Today @PostConstruct is generally preferred because it avoids coupling your class to Spring interfaces.

#Step 8 — Custom initMethod

@Bean(initMethod = "initialize")
public UserService service() {
    return new UserService();
}

public void initialize() {
}

Spring calls it after afterPropertiesSet().

Initialization Order

Interview favourite:

#Step 9 — BeanPostProcessor (After Initialization)

Spring executes postProcessAfterInitialization(). This is where many Spring features create proxies — Spring AOP, @Transactional, Spring Security, @Async and @Cacheable.

Why BeanPostProcessor Matters

@Transactional
public void save() {
}

Without BeanPostProcessor, features like @Transactional and @Async wouldn't work.

#Step 10 — Bean Ready

The bean is fully initialized and lives in the ApplicationContext, available to controllers, services and repositories.

#Step 11 — @PreDestroy

When the application stops:

@Service
public class UserService {

    @PreDestroy
    public void destroy() {
        System.out.println("Cleaning Resources");
    }
}

Called before bean destruction. Useful for closing resources, releasing locks, flushing buffers and stopping background tasks.

#Step 12 — DisposableBean

public class UserService implements DisposableBean {

    @Override
    public void destroy() {
    }
}

Again, @PreDestroy is generally preferred because it avoids Spring-specific coupling.

#Step 13 — Custom destroyMethod

@Bean(destroyMethod = "cleanup")
public UserService service() {
    return new UserService();
}

Spring executes cleanup() during shutdown.

Destruction Order

#Bean Scopes

Interview favourite.

Singleton (Default)

@Service
public class UserService {
}

One bean for the entire ApplicationContext, shared everywhere. The default scope.

Prototype

@Scope("prototype")
@Component
public class Report {
}

Every request for the bean creates a new instance.

Request Scope

@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)

One bean per HTTP request. Only available in web applications. (@RequestScope is a shortcut that includes the proxy.)

Session Scope

@Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS)

One bean per HTTP session. Useful for user-specific state. (@SessionScope is the shortcut.)

Application Scope

@Scope(value = "application")

One bean for the entire web application (ServletContext).

Scope Comparison

#BeanFactoryPostProcessor vs BeanPostProcessor

A very important interview topic.

BeanFactoryPostProcessor works on BeanDefinitions, before beans are created — e.g. modifying bean definitions, changing bean properties, registering additional bean definitions (PropertySourcesPlaceholderConfigurer resolves ${...} placeholders this way).

BeanPostProcessor works on actual bean instances:

…e.g. AOP proxies, transaction proxies, security proxies and logging wrappers.

This comparison is frequently asked.

#Complete Internal Flow

#Key Takeaways

• A Spring bean goes through a well-defined lifecycle from creation to destruction.
• @PostConstruct is ideal for initialization after dependency injection.
• @PreDestroy releases resources during shutdown.
• BeanFactoryPostProcessor modifies metadata before instantiation; BeanPostProcessor customizes instances around initialization.
• singleton is the default scope; prototype beans aren't destroyed by Spring.
• Transactions, AOP, security, async execution and caching rely on BeanPostProcessor and proxies.