Spring Bean Lifecycle and Scopes

1. Spring Bean Scopes: How Many Instances?

When the Spring container creates a bean, it also decides its scope. The scope defines the lifecycle and visibility of that bean instance. For interviews, you must be fluent in the two most fundamental scopes: singleton and prototype.

Let's recap the two most important scopes:

• Singleton (Default): Only one single instance of the bean is created per Spring IoC container. Every time any other bean requests a dependency of this type, the container injects a reference to that same, single instance.
  • Best for: Stateless services, repositories, and configuration beans. Since these beans are shared across threads, they must be thread-safe. This is why it's best practice to make them stateless.
• Prototype: A new instance is created every single time the bean is requested from the container.
  • Best for: Stateful objects, like a shopping cart or a report builder, where each user or task needs a unique, isolated instance.

The other scopes (request, session, application) are specific to web applications and define the bean's lifetime relative to an HTTP request, a user's session, or the entire web application's lifecycle, respectively. While good to know, singleton and prototype are the most universally applicable and frequently discussed in interviews.

The Singleton-Prototype Injection Problem

Here's a classic senior-level interview question: "What happens if you inject a prototype-scoped bean into a singleton-scoped bean?"

At first glance, you might think the singleton will get a fresh instance of the prototype every time it's needed. However, that's incorrect. The dependency injection happens only once—when the singleton bean is created. At that time, it receives a single instance of the prototype bean, and it will hold on to that same instance for its entire lifetime, defeating the purpose of the prototype scope.

So how does Spring solve this?

To summarize the solutions:

1. Scoped Proxy (proxyMode): You annotate the prototype bean with @Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS). Spring then injects a proxy object into the singleton instead of the actual prototype. When the singleton calls a method on this proxy, the proxy intercepts the call and asks the container for a new instance of the prototype, forwarding the call to it.
2. Lookup Method Injection (@Lookup): You define an abstract method in your singleton class that returns the prototype type and annotate it with @Lookup. Spring dynamically creates an implementation of this method that, when called, looks up a fresh instance of the prototype bean from the container.

2. The Spring Bean Lifecycle

Now that we understand scopes, let's zoom out and look at the entire journey of a bean. The Spring bean lifecycle refers to the sequence of events from its instantiation by the container to its final destruction.

This lifecycle diagram provides a great visual overview of all the steps involved.

To get a more structured understanding of this flow, let's refer back to our primary resource.

The key phases we are interested in are:

1. Instantiation: Spring creates the bean instance (e.g., calls the constructor).
2. Populate Properties: Spring injects dependencies (DI).
3. Initialization: Custom initialization logic is run.
4. In Use: The bean is ready and being used by the application.
5. Destruction: The bean is being removed, and custom cleanup logic is run.

3. Implementing Lifecycle Callbacks

Spring provides hooks that allow you to execute custom code during the initialization and destruction phases. This is essential for tasks like acquiring or releasing resources (e.g., database connections, file handles, network sockets).

There are three primary ways to implement these callbacks. For a senior-level interview, you're expected to know all three and articulate the pros and cons of each.

Here’s a summary table, perfect for interview prep:

Interview Pro Tip: If asked about the order, Spring executes initialization callbacks in this sequence:

1. @PostConstruct annotated methods
2. afterPropertiesSet() from InitializingBean
3. Custom initMethod

4. The Prototype Lifecycle "Gotcha"

We've discussed the lifecycle for singleton beans, but what about prototypes? This is another critical distinction that interviewers love to probe.

Once the Spring container creates and initializes a prototype bean and gives it to the client, it relinquishes all further responsibility for it. The container does not manage the complete lifecycle of a prototype bean.

What does this mean in practice?

The key takeaway is this: for a prototype-scoped bean, Spring will execute initialization callbacks (like @PostConstruct), but it will never call any destruction callbacks (like @PreDestroy).

The responsibility for cleaning up a prototype bean and releasing any resources it holds falls entirely on the client code that requested it. If you fail to do this, you will have a resource leak in your application.

// In your service (the client of the prototype)
// Assuming you get the prototype from the ApplicationContext

try (ReportGenerator generator = context.getBean(ReportGenerator.class)) {
    generator.createReport();
    // The generator.close() method will be called automatically here.
} catch (Exception e) {
    // Handle exception
}

Finally, let's see these concepts in action within a familiar layered architecture.

Conclusion

Well done! You have now explored the complete lifecycle of a Spring bean. Understanding scopes and lifecycle hooks is fundamental to writing robust, resource-efficient Spring applications and a key area of knowledge for any senior developer.

Key Takeaways:

• Bean Scopes define the number of instances and lifetime of a bean. Singleton (one instance, the default) and Prototype (new instance per request) are the most important.
• The Bean Lifecycle for a singleton involves instantiation, dependency injection, initialization, being in use, and finally, destruction.
• Lifecycle Callbacks allow you to run custom logic during initialization and destruction. The modern, recommended approach is using the JSR-250 annotations @PostConstruct and @PreDestroy.
• Prototype Lifecycles are different: Spring creates, configures, and initializes a prototype bean but does not manage its destruction. @PreDestroy and other destruction callbacks are not called. The client is responsible for cleanup.

Preview of the Next Lesson:
We've seen how Spring meticulously manages the lifecycle of individual beans that we define. But what about the hundreds of beans that Spring Boot seems to configure for us "magically" when we add a dependency like spring-boot-starter-data-jpa? In our next lesson, we will demystify this magic by diving into Spring Boot's auto-configuration mechanism and even learn how to create a custom auto-configuration.