Mastering Bean Lifecycle Management

What is a Bean's Scope?

A bean's scope defines the strategy the Spring container uses to create and manage instances of that bean. It answers the questions: How many instances of this bean should exist? And what is their lifetime?

Spring offers several scopes, but you will primarily work with two foundational ones: singleton and prototype. The others are specific to web applications.

This visual provides a great at-a-glance summary of the main scopes.

Let's explore these in more detail. The following resource provides excellent explanations of each scope.

To summarize the key points:

• Singleton: This is the default scope. Only one instance of the bean is created per Spring IoC container. Every time any other component asks for this bean, it gets the exact same object. This is ideal for stateless components like services, repositories, and configuration classes.
• Prototype: A new instance is created every single time the bean is requested from the container. This is suitable for stateful objects, where each client needs its own distinct copy to work with, for example, a builder object for creating a complex report.
• Web Scopes:
  • Request: A new instance for each HTTP request.
  • Session: A new instance for each user's HTTP session.
  • Application: A single instance for the entire web application's ServletContext.

The Singleton-Prototype Dependency Trap: An Interview Favorite

A classic interview question explores what happens when you inject a prototype-scoped bean into a singleton-scoped bean. Since you have experience building services (@Service, a singleton by default), this is a practical scenario.

Imagine your singleton OrderService needs a prototype ShoppingCart bean.

@Service // Singleton scope by default
public class OrderService {
    private final ShoppingCart cart;

    // Dependencies are injected only ONCE when the singleton is created
    public OrderService(ShoppingCart cart) {
        this.cart = cart;
    }

    public void processOrder() {
        // ... uses the 'cart' instance
    }
}

@Component
@Scope("prototype")
public class ShoppingCart {
    // ... stateful logic
}

You might expect that each call to processOrder() would get a fresh ShoppingCart. However, that's not what happens. The dependency injection occurs only once, when the OrderService singleton is first created. The OrderService will hold a reference to that single ShoppingCart instance for its entire lifetime, effectively treating it like a singleton.

The following video discusses this exact problem and the solution.

The Bean Lifecycle: Birth, Life, and Death

Beyond its scope, every bean follows a distinct lifecycle within the Spring container. The container doesn't just create an object; it orchestrates a series of steps from instantiation to destruction. Understanding these steps allows you to hook in your own custom logic at precise moments.

This diagram shows the major phases of a bean's life.

We can group the lifecycle into four main stages:

1. Instantiation: Spring creates an instance of the bean, typically by calling its constructor.
2. Populate Properties: Spring resolves and injects dependencies (as we saw in the previous lesson).
3. Initialization: Spring calls special callback methods to allow the bean to perform any setup tasks (e.g., populating a cache, connecting to a resource).
4. Destruction: Just before the container shuts down and removes the bean, it calls destruction callbacks to allow for cleanup (e.g., closing a file handle, shutting down a connection pool).

Initialization and Destruction Callbacks

For a developer, the most important parts of the lifecycle to interact with are initialization and destruction. Spring provides three primary mechanisms for this, which are a frequent subject of interview questions.

The following video is an excellent interview-focused preparation resource that walks through each mechanism with clear code examples.

After watching, let's turn our attention to the destruction phase.

To solidify this knowledge, the following article provides a textual reference detailing the precise order of execution when you combine multiple callback mechanisms.

Here is a summary of the callback mechanisms and their execution order:

An important note on prototype beans: The Spring container does not manage the complete lifecycle of prototype beans. It creates, configures, and initializes them, but then hands them over to the client. The container does not keep a reference to them, and therefore destruction callbacks like @PreDestroy or DisposableBean.destroy() are NOT called. You, the developer, are responsible for cleaning up any resources held by prototype-scoped beans.

Conclusion

In this lesson, we've gone deep into the life and death of a Spring bean. By combining your knowledge of dependency injection with bean scopes and lifecycle callbacks, you can now predict not just how your application components are wired, but also how they behave throughout their lifetime. This is a level of understanding that separates a junior developer from an experienced one and is critical for passing technical interviews.

Key Takeaways:

• Bean Scopes: singleton (the default) creates one shared instance, while prototype creates a new instance for every request. Web scopes (request, session, application) are tied to the lifecycle of web interactions.
• Singleton/Prototype Injection: Injecting a prototype bean into a singleton results in the singleton holding a single instance of that prototype. Use @Lookup for cases where a singleton needs fresh prototype instances at runtime.
• Lifecycle Callbacks: Use @PostConstruct for initialization logic and @PreDestroy for cleanup logic. They are the modern standard because they decouple your business logic from the Spring framework.
• Callback Order: Spring executes callbacks in a strict order: @PostConstruct -> InitializingBean -> init-method. For destruction, the order is @PreDestroy -> DisposableBean -> destroy-method.
• Prototype Destruction: Spring does not manage the destruction of prototype beans. Destruction callbacks are not invoked for them.

In our next lesson, we will tackle another crucial aspect of Spring's inner workings: auto-configuration. We'll learn how to use Spring Boot's condition evaluation report to understand exactly why a particular bean was—or was not—created, giving you powerful debugging capabilities.