The Spring Bean Lifecycle

The Conceptual Lifecycle: Why We Need Custom Hooks

At its heart, the Spring IoC (Inversion of Control) container is responsible for managing the lifecycle of objects, which we call "beans." This process is more sophisticated than a simple new MyObject(). The container handles creating the object, injecting its dependencies, and finally, destroying it when it's no longer needed.

Often, you need to execute custom logic at specific points in this lifecycle. For example:

• After creation and dependency injection: You might need to open a network connection, read a configuration file, or pre-populate a cache. The bean isn't truly "ready" until this is done.
• Before destruction: You need a chance to release resources gracefully, such as closing file handles, shutting down a thread pool, or flushing pending data to a database.

The following video provides an excellent introduction to this concept and illustrates the basic stages of a bean's life.

This gives us our basic mental model. Now, let's zoom in and look at the detailed sequence of events that occur within the "Bean Creation" and "Bean Destruction" phases.

A Detailed Look at the Bean Lifecycle Phases

The lifecycle of a Spring bean is a well-defined sequence of steps. The flowchart below provides a comprehensive map of this journey, from the initial instantiation to the final destruction. We will refer to this diagram as we break down each phase.

To complement the diagram, the following article provides a concise, text-based summary of the phases.

Bean Creation Sequence

Based on the diagram and article, here is the detailed sequence of events during bean creation:

1. Instantiation: Spring creates an instance of the bean, typically by calling its constructor.
2. Populating Properties: Spring resolves and injects the bean's dependencies. This is where field, constructor, or setter injection (e.g., using @Autowired) happens.
3. Aware Interfaces: If the bean implements specific Aware interfaces, Spring calls their methods to provide the bean with access to parts of its container environment. Common examples include:
   • BeanNameAware: Provides the bean with its own ID in the container.
   • ApplicationContextAware: Gives the bean access to the ApplicationContext itself.
4. BeanPostProcessor (Before Initialization): Before any custom initialization methods are called, BeanPostProcessors get their first chance to process the bean. This is a powerful mechanism for implementing cross-cutting concerns.
5. Initialization Callbacks: Spring invokes the bean's initialization methods. If a bean has multiple types of initialization callbacks defined, they are executed in this specific order:
   1. Method annotated with @PostConstruct.
   2. afterPropertiesSet() method (if the bean implements the InitializingBean interface).
   3. The custom initMethod specified in a @Bean annotation.
6. BeanPostProcessor (After Initialization): BeanPostProcessors get their second chance to process the bean. This is where frameworks often wrap the original bean in a proxy to add behaviors like transaction management or security.
7. Bean is Ready: The bean is now fully initialized and ready to be used by the application.

Bean Destruction Sequence

When the application shuts down and the Spring container is closed, the destruction process is initiated for singleton beans.

1. Destruction Callbacks: Similar to initialization, if multiple destruction callbacks are defined, they are called in a specific order:
   1. Method annotated with @PreDestroy.
   2. destroy() method (if the bean implements the DisposableBean interface).
   3. The custom destroyMethod specified in a @Bean annotation.
2. Bean is Destroyed: The bean is removed from the container.

Implementing Lifecycle Callbacks: Modern vs. Legacy

Now that you know the sequence, let's see how to implement these callbacks. While there are three primary methods, the modern, annotation-based approach is strongly recommended.

The Recommended Approach: @PostConstruct and @PreDestroy

The JSR-250 annotations @PostConstruct and @PreDestroy are the modern standard for defining lifecycle callbacks. They are clean, unintrusive, and don't tie your code to Spring-specific interfaces.

The CodeSnippet video we watched earlier demonstrates this approach perfectly.

As the video shows, you simply annotate any public, void, no-argument method with @PostConstruct or @PreDestroy.

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.springframework.stereotype.Component;

@Component
public class ResourceManager {

    @PostConstruct
    public void initialize() {
        System.out.println("ResourceManager: Initializing resources...");
        // e.g., open file, connect to a remote service
    }

    public void useResources() {
        System.out.println("ResourceManager: Using resources...");
    }

    @PreDestroy
    public void cleanup() {
        System.out.println("ResourceManager: Cleaning up resources...");
        // e.g., close file, disconnect from service
    }
}

Legacy Approaches

You may encounter two other approaches, especially in older projects or third-party libraries:

1. Interface-based (InitializingBean, DisposableBean): Your bean implements these Spring-specific interfaces and overrides the afterPropertiesSet() and destroy() methods. This couples your component directly to the Spring Framework.
2. Method-based (initMethod, destroyMethod): When defining a bean via a @Bean annotation in a @Configuration class, you can specify the names of the init and destroy methods as string attributes. This is useful when you can't modify the source code of the class itself.

@Configuration
public class AppConfig {

    @Bean(initMethod = "initialize", destroyMethod = "cleanup")
    public LegacyResourceHandler legacyResourceHandler() {
        return new LegacyResourceHandler();
    }
}

The Shutdown Hook: Ensuring Destruction

A common point of confusion is when the @PreDestroy method doesn't seem to be called. In a standalone Java application, the JVM exits immediately after the main method completes. It doesn't wait for the Spring container to shut down gracefully.

To ensure your destruction callbacks are executed, you must register a shutdown hook with the application context. This tells the JVM to close the Spring container before the application exits.

The article below explains this critical, practical detail.

In a Spring Boot application that runs continuously (like a web application), this is handled for you. But for command-line applications or simple tests, it's something you must manage yourself.

The Full Execution Order in Action

To put all this theory together, let's see the definitive order of execution with a concrete example that uses all the different types of callbacks.

As you can see from the logs in the article, the execution order is exactly as we described: BeanPostProcessor (before) -> @PostConstruct -> InitializingBean -> init-method -> BeanPostProcessor (after).

Conclusion

You now have a detailed map of the Spring bean lifecycle. This knowledge moves you from being just a user of the framework to an informed developer who understands how its core container operates.

Key Takeaways:

• The Spring container manages the full lifecycle of beans, from instantiation and dependency injection to initialization and eventual destruction.
• You can hook into this lifecycle to perform custom logic using annotations, interfaces, or configuration attributes.
• The modern, recommended approach is to use the @PostConstruct and @PreDestroy annotations, as they are part of a standard (JSR-250) and don't couple your code to Spring.
• The order of initialization callbacks is: @PostConstruct, then InitializingBean.afterPropertiesSet(), then custom initMethod.
• The order of destruction callbacks is: @PreDestroy, then DisposableBean.destroy(), then custom destroyMethod.
• For non-web applications, you must register a shutdown hook to ensure destruction methods are called.

This theoretical foundation is essential. In our next lesson, "Use @PostConstruct and @PreDestroy to hook into bean lifecycle events," we will put this knowledge into practice with hands-on coding exercises. After that, we'll explore how the lifecycle differs for beans with different scopes, such as singleton versus prototype.