@PostConstruct and @PreDestroy in Spring Boot - Deep Dive

Overview - @PostConstruct and @PreDestroy

What is it?

@PostConstruct and @PreDestroy are special annotations in Spring Boot used to run methods automatically during the lifecycle of a bean. @PostConstruct marks a method to run right after the bean is created and all dependencies are set. @PreDestroy marks a method to run just before the bean is removed or the application shuts down. They help manage setup and cleanup tasks without manual calls.

Why it matters

Without these annotations, developers would have to call initialization and cleanup methods manually, which is error-prone and messy. These annotations ensure important setup and teardown code runs reliably and at the right time, improving application stability and resource management. This is especially important in large applications where many components depend on proper lifecycle handling.

Where it fits

Before learning these, you should understand basic Spring Boot beans and dependency injection. After mastering these, you can explore more advanced lifecycle hooks, custom bean post processors, and application event listeners to handle complex lifecycle scenarios.

Mental Model

Core Idea

@PostConstruct and @PreDestroy let you hook into the start and end moments of a Spring bean’s life to run setup and cleanup code automatically.

Think of it like...

It’s like when you enter a room: you turn on the lights (@PostConstruct), and when you leave, you turn them off (@PreDestroy). This ensures the room is ready when you arrive and properly closed when you leave.

┌───────────────┐
│ Bean Creation │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ @PostConstruct│ ← Runs after bean is ready
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Bean in Use   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ @PreDestroy   │ ← Runs before bean is destroyed
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Bean Removed  │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Spring Beans Lifecycle

Concept: Learn what a Spring bean is and how Spring manages its lifecycle.

In Spring Boot, a bean is an object managed by the Spring container. The container creates, configures, and manages these beans. The lifecycle includes creation, initialization, usage, and destruction. Knowing this helps understand where @PostConstruct and @PreDestroy fit.

Result

You know that Spring controls when beans are created and destroyed.

Understanding the bean lifecycle is essential because @PostConstruct and @PreDestroy hook into specific lifecycle moments.

2

Foundation

Basics of @PostConstruct Annotation

Concept: @PostConstruct marks a method to run after the bean is fully created and dependencies injected.

Add @PostConstruct above a method in your bean class. Spring calls this method automatically after the bean is ready. Use it to run setup code like opening connections or initializing values.

Result

The method annotated with @PostConstruct runs once after bean creation without manual calls.

Knowing that @PostConstruct runs after dependencies are set ensures your setup code can safely use injected resources.

3

Intermediate

Using @PreDestroy for Cleanup Tasks

Concept: @PreDestroy marks a method to run just before the bean is destroyed, useful for cleanup.

Add @PreDestroy above a method to have Spring call it before removing the bean or shutting down. Use it to close connections, release resources, or save state.

Result

Cleanup code runs automatically at the right time without manual intervention.

Understanding @PreDestroy prevents resource leaks and ensures graceful shutdown.

4

Intermediate

Lifecycle in Singleton vs Prototype Beans

🤔Before reading on: Do you think @PreDestroy runs for prototype-scoped beans automatically? Commit to yes or no.

Concept: Bean scope affects when and if lifecycle methods run automatically.

Singleton beans live throughout the application and have @PostConstruct and @PreDestroy called automatically. Prototype beans are created on demand and not managed fully by Spring after creation, so @PreDestroy is not called automatically for them.

Result

You learn that @PreDestroy may not run for prototype beans unless handled manually.

Knowing scope differences helps avoid bugs where cleanup code is skipped unexpectedly.

5

Intermediate

Combining @PostConstruct and @PreDestroy in One Bean

🤔Before reading on: Can a single bean have both @PostConstruct and @PreDestroy methods? Commit to yes or no.

Concept: A bean can have both annotations to manage setup and teardown cleanly.

Define one method with @PostConstruct for initialization and another with @PreDestroy for cleanup in the same bean. Spring calls them at the right lifecycle moments automatically.

Result

Your bean manages its own lifecycle tasks without extra code elsewhere.

Understanding this pattern leads to cleaner, more maintainable code by localizing lifecycle logic.

6

Advanced

Lifecycle with Proxy and AOP Beans

🤔Before reading on: Do you think @PostConstruct runs before or after Spring applies proxies like AOP? Commit to your answer.

Concept: Spring calls @PostConstruct after creating the actual bean but before returning the proxy to clients.

When Spring creates a bean with AOP proxies, it first creates the target bean and calls @PostConstruct on it. Then it wraps the bean in a proxy. This means @PostConstruct runs on the real bean, not the proxy. @PreDestroy runs similarly before destruction.

Result

You understand the timing of lifecycle methods in proxy scenarios.

Knowing this prevents confusion when lifecycle methods seem not to affect proxy behavior.

7

Expert

Limitations and Alternatives to @PostConstruct/@PreDestroy

🤔Before reading on: Are @PostConstruct and @PreDestroy the only ways to manage bean lifecycle in Spring? Commit to yes or no.

Concept: Spring offers other lifecycle management options beyond these annotations.

Besides @PostConstruct and @PreDestroy, Spring supports InitializingBean and DisposableBean interfaces, custom BeanPostProcessors, and application events. These provide more control or work in special cases. However, annotations are simpler and preferred for most uses.

Result

You see the bigger picture of lifecycle management and when to choose alternatives.

Understanding alternatives helps you pick the right tool for complex lifecycle needs and avoid annotation limitations.

Under the Hood

Spring scans bean classes for @PostConstruct and @PreDestroy annotations during bean creation. After creating the bean instance and injecting dependencies, Spring uses reflection to find and invoke the @PostConstruct method. Similarly, before destroying the bean (usually on context shutdown), Spring calls the @PreDestroy method. This is integrated into the bean lifecycle management inside the ApplicationContext.

Why designed this way?

These annotations come from the Java EE standard (JSR-250) to provide a simple, declarative way to manage lifecycle callbacks without forcing beans to implement interfaces. This design promotes loose coupling and cleaner code by separating lifecycle logic from business logic. Alternatives like interfaces were more rigid and less flexible.

┌─────────────────────────────┐
│ Spring Container Starts     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Create Bean Instance         │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Inject Dependencies          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Call @PostConstruct Method   │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Bean Ready for Use           │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Application Context Closing  │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Call @PreDestroy Method      │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Bean Destroyed              │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does @PreDestroy run automatically for prototype-scoped beans? Commit to yes or no.

Common Belief: Many believe @PreDestroy runs automatically for all bean scopes, including prototype.

Reality: @PreDestroy is not called automatically for prototype-scoped beans because Spring does not manage their full lifecycle after creation.

Why it matters: Assuming @PreDestroy runs for prototypes can cause resource leaks and unexpected behavior in applications.

Quick: Is @PostConstruct called before or after dependency injection? Commit to your answer.

Common Belief: Some think @PostConstruct runs before dependencies are injected.

Reality: @PostConstruct runs only after all dependencies are injected and the bean is fully initialized.

Why it matters: Running setup code before dependencies are ready can cause NullPointerExceptions or incorrect initialization.

Quick: Can you use multiple @PostConstruct methods in one bean? Commit to yes or no.

Common Belief: Some believe you can have multiple methods annotated with @PostConstruct in the same bean.

Reality: Only one method per bean can be annotated with @PostConstruct; multiple annotations cause errors.

Why it matters: Trying to use multiple @PostConstruct methods leads to runtime exceptions and application startup failure.

Quick: Does @PreDestroy guarantee cleanup if the JVM crashes? Commit to yes or no.

Common Belief: Many assume @PreDestroy always runs and guarantees cleanup.

Reality: @PreDestroy runs only during normal Spring context shutdown; it does not run if the JVM crashes or is killed abruptly.

Why it matters: Relying solely on @PreDestroy for critical cleanup can cause resource leaks if the application terminates unexpectedly.

Expert Zone

1

Spring calls @PostConstruct methods after dependency injection but before any proxies are applied, which can affect AOP behavior.

2

If a bean implements InitializingBean or DisposableBean interfaces alongside these annotations, the order of lifecycle callbacks matters and can cause subtle bugs.

3

Using @PreDestroy in combination with asynchronous shutdown hooks requires careful coordination to avoid premature resource release.

When NOT to use

@PostConstruct and @PreDestroy are not suitable for prototype-scoped beans or beans managed outside Spring. In those cases, manual lifecycle management or custom BeanPostProcessors are better. Also, for complex lifecycle needs, consider ApplicationListener events or smart lifecycle interfaces.

Production Patterns

In production, these annotations are used to initialize database connections, thread pools, or caches at startup and to close or flush them at shutdown. They are combined with configuration properties and conditional beans to manage resources efficiently and avoid leaks.

Connections

Dependency Injection

Builds-on

Understanding dependency injection is crucial because @PostConstruct runs only after dependencies are injected, ensuring setup code has all needed resources.

Observer Pattern

Similar pattern

Lifecycle callbacks like @PostConstruct and @PreDestroy resemble observer notifications triggered at specific lifecycle events, helping manage state changes cleanly.

Operating System Signals

Analogy in system design

Just as OS signals notify programs to clean up before termination, @PreDestroy signals beans to release resources before shutdown, showing a cross-domain pattern of graceful termination.

Common Pitfalls

#1 Assuming @PreDestroy runs for prototype beans automatically.

Wrong approach:

@PreDestroy
public void cleanup() {
// close resources
}
// Bean is prototype scoped, expecting cleanup to run automatically

Correct approach:

// For prototype beans, manage cleanup manually or use custom scope
public void cleanup() {
// close resources
}
// Call cleanup explicitly when done

Root cause:

Misunderstanding Spring’s lifecycle management scope differences.

#2 Placing @PostConstruct on a method that requires parameters.

Wrong approach:

@PostConstruct
public void init(String config) {
// initialization
}

Correct approach:

@PostConstruct
public void init() {
// initialization without parameters
}

Root cause:

Lifecycle methods must have no arguments; misunderstanding method signature requirements.

#3 Using multiple @PostConstruct methods in one bean.

Wrong approach:

@PostConstruct
public void init1() {}
@PostConstruct
public void init2() {}

Correct approach:

@PostConstruct
public void init() {
init1();
init2();
}

Root cause:

Believing multiple lifecycle methods are allowed instead of consolidating logic.

Key Takeaways

@PostConstruct and @PreDestroy automate running setup and cleanup code at the right bean lifecycle moments.

They run after dependencies are injected and before bean destruction, ensuring safe resource management.

These annotations work automatically for singleton beans but require manual handling for prototype beans.

Understanding their timing with proxies and scopes prevents common bugs and resource leaks.

Alternatives exist for complex lifecycle needs, but these annotations offer a simple, declarative approach.

Practice

1. What is the main purpose of the @PostConstruct annotation in a Spring Boot application?

easy

A. To run a method immediately after the bean is created and dependencies are injected

B. To mark a method that should run before the bean is destroyed

C. To define a method that runs only when the application starts

D. To schedule a method to run repeatedly at fixed intervals

Solution

1. Step 1: Understand the role of @PostConstruct

   @PostConstruct is used to run initialization code after the Spring bean is fully created and dependencies are set.

2. Step 2: Compare with other lifecycle annotations

   @PreDestroy runs before bean removal, and scheduling annotations run repeatedly, so they don't match @PostConstruct's purpose.

3. Final Answer:

   To run a method immediately after the bean is created and dependencies are injected -> Option A

4. Quick Check:

   @PostConstruct = run after bean creation [OK]

Hint: Remember: PostConstruct runs right after bean setup [OK]

Common Mistakes:

• Confusing @PostConstruct with @PreDestroy
• Thinking @PostConstruct runs before bean creation
• Assuming it schedules repeated tasks

2. Which of the following is the correct way to use @PreDestroy in a Spring Boot bean?

easy

A. Place @PreDestroy on a static method to run after application shutdown

B. Annotate a method with @PreDestroy to run cleanup code before bean destruction

C. Use @PreDestroy on a constructor to initialize resources

D. Annotate the class with @PreDestroy to mark it for destruction

Solution

1. Step 1: Identify correct usage of @PreDestroy

   @PreDestroy is placed on a method to run cleanup code before the bean is destroyed.

2. Step 2: Eliminate incorrect options

   @PreDestroy cannot annotate a class or constructor, and static methods are not lifecycle callbacks.

3. Final Answer:

   Annotate a method with @PreDestroy to run cleanup code before bean destruction -> Option B

4. Quick Check:

   @PreDestroy = method cleanup before bean removal [OK]

Hint: Use @PreDestroy only on instance methods for cleanup [OK]

Common Mistakes:

• Annotating the class instead of a method
• Using @PreDestroy on constructors
• Marking static methods with @PreDestroy

3. Consider the following Spring Boot bean code snippet:

public class MyBean {

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

    @PreDestroy
    public void cleanup() {
        System.out.println("Bean is about to be destroyed");
    }

}

What will be printed when the application context starts and then shuts down?

medium

A. Bean is about to be destroyedBean is initialized

B. Only Bean is initialized

C. Bean is initializedBean is about to be destroyed

D. Only Bean is about to be destroyed

Solution

1. Step 1: Understand @PostConstruct behavior on startup

   The init() method runs after bean creation, printing "Bean is initialized" when the app context starts.

2. Step 2: Understand @PreDestroy behavior on shutdown

   The cleanup() method runs before bean destruction, printing "Bean is about to be destroyed" when the app context shuts down.

3. Final Answer:

   Bean is initialized
   Bean is about to be destroyed -> Option C

4. Quick Check:

   Startup prints init, shutdown prints cleanup [OK]

Hint: PostConstruct runs on start, PreDestroy runs on shutdown [OK]

Common Mistakes:

• Mixing order of printed messages
• Expecting only one message to print
• Thinking @PreDestroy runs on startup

4. Given this Spring Boot bean code:

public class ResourceBean {

    @PostConstruct
    public void setup() {
        System.out.println("Setup resources");
    }

    @PreDestroy
    public void cleanup() {
        System.out.println("Cleanup resources");
    }

    public void start() {
        System.out.println("Start method called");
    }

}

When running the application, the developer notices that "Cleanup resources" is never printed on shutdown. What is the most likely cause?

medium

A. The @PostConstruct method prevents @PreDestroy from running

B. The @PreDestroy method must be static to run correctly

C. The cleanup() method must be called manually to run

D. The bean is not managed by Spring, so lifecycle annotations are ignored

Solution

1. Step 1: Check if bean is managed by Spring

   @PostConstruct and @PreDestroy only work if Spring manages the bean lifecycle (e.g., via @Component or @Bean).

2. Step 2: Understand why cleanup isn't called

   If the bean is created manually (new keyword), Spring won't call lifecycle methods, so cleanup() won't run automatically.

3. Final Answer:

   The bean is not managed by Spring, so lifecycle annotations are ignored -> Option D

4. Quick Check:

   Lifecycle annotations need Spring-managed beans [OK]

Hint: Lifecycle methods run only on Spring-managed beans [OK]

Common Mistakes:

• Thinking @PreDestroy must be static
• Assuming @PostConstruct blocks @PreDestroy
• Believing cleanup() runs without Spring management

5. You want to ensure a Spring Boot bean opens a database connection after creation and closes it before destruction. Which code snippet correctly uses @PostConstruct and @PreDestroy to achieve this?

hard

A. public class DbBean {

private Connection conn;

@PostConstruct
public void open() {
conn = DriverManager.getConnection("url");
System.out.println("Connection opened");
}

@PreDestroy
public void close() {
conn.close();
System.out.println("Connection closed");
}

}

B. public class DbBean {

private Connection conn;

public void open() {
conn = DriverManager.getConnection("url");
System.out.println("Connection opened");
}

public void close() {
conn.close();
System.out.println("Connection closed");
}

}

C. public class DbBean {

private Connection conn;

@PreDestroy
public void open() {
conn = DriverManager.getConnection("url");
System.out.println("Connection opened");
}

@PostConstruct
public void close() {
conn.close();
System.out.println("Connection closed");
}

}

D. public class DbBean {

private Connection conn;

@PostConstruct
public void open() {
System.out.println("Connection opened");
}

@PreDestroy
public void close() {
System.out.println("Connection closed");
}

}

Solution

1. Step 1: Identify correct lifecycle method usage

   @PostConstruct should open the connection after bean creation; @PreDestroy should close it before destruction.

2. Step 2: Check code correctness

   public class DbBean { private Connection conn; @PostConstruct public void open() { conn = DriverManager.getConnection("url"); System.out.println("Connection opened"); } @PreDestroy public void close() { conn.close(); System.out.println("Connection closed"); } } correctly uses @PostConstruct to open and @PreDestroy to close the connection with proper method calls.

3. Final Answer:

   public class DbBean { private Connection conn; @PostConstruct public void open() { conn = DriverManager.getConnection("url"); System.out.println("Connection opened"); } @PreDestroy public void close() { conn.close(); System.out.println("Connection closed"); } } -> Option A

4. Quick Check:

   Open after creation, close before destruction [OK]

Hint: Open in @PostConstruct, close in @PreDestroy for resource management [OK]

Common Mistakes:

• Swapping @PostConstruct and @PreDestroy methods
• Not calling connection methods inside lifecycle methods
• Missing lifecycle annotations on resource methods