Spring Framework FAQ: Top Questions

Spring beans move through a well-defined lifecycle managed by the IoC container: creation, dependency injection, initialization, usage, and destruction. You can hook into these stages to prepare resources (e.g., open DB connections, warm caches) and clean them up (e.g., close pools, stop schedulers).

📘 Key Methods:

• @PostConstruct — run after dependency injection but before the bean is used.
• InitializingBean.afterPropertiesSet() — interface-based init callback.
• @PreDestroy — run right before container destroys the bean.
• DisposableBean.destroy() — interface-based destroy callback.
• Custom @Bean(initMethod="…", destroyMethod="…") or XML init-method/destroy-method.

🔎 Extended Lifecycle Order (what actually happens):

1. Instantiate — container creates the bean (constructor or factory method).
2. Populate Properties — dependency injection (constructor/setter/field).
3. Aware Interfaces (optional) — if implemented:
   • BeanNameAware.setBeanName()
   • BeanFactoryAware.setBeanFactory()
   • ApplicationContextAware.setApplicationContext()
4. BeanPostProcessor: before init — postProcessBeforeInitialization() for all processors.
5. Initialization callbacks (any/all that apply, in this general order):
   • @PostConstruct
   • afterPropertiesSet() (from InitializingBean)
   • custom initMethod
6. BeanPostProcessor: after init — postProcessAfterInitialization().
7. Ready for Use — bean participates in your app logic.
8. Destruction callbacks (on context shutdown):
   • @PreDestroy
   • destroy() (from DisposableBean)
   • custom destroyMethod

📥 Example:

@Component
public class MyService {

  @PostConstruct
  public void init() {
    System.out.println("Bean is initialized");
    // e.g., warm up caches, start a scheduler, validate configuration
  }

  @PreDestroy
  public void cleanup() {
    System.out.println("Bean is about to be destroyed");
    // e.g., flush metrics, stop scheduler, close resources
  }
}

🏆 Expected Output:

Bean is initialized
... (application runs) ...
Bean is about to be destroyed

🛠️ Use Cases:

• Resource setup (DB pools, HTTP clients, caches, message consumers).
• Graceful cleanup (closing sockets, stopping threads/executors, persisting state).
• Validating configuration and precomputing expensive data at startup.

⚖️ Annotations vs Interfaces vs Config Methods:

• Prefer @PostConstruct/@PreDestroy for concise, framework-agnostic code (JSR-250).
• Use InitializingBean/DisposableBean when you need explicit Spring interfaces.
• For third-party classes you can’t modify, set @Bean(initMethod="…", destroyMethod="…") in a @Configuration class.

📌 Notes, Tips & Pitfalls:

• Order of init callbacks: @PostConstruct → afterPropertiesSet() → custom initMethod.
• Singleton vs Prototype: destruction callbacks are invoked automatically for singletons. For prototype beans, the container does not call destroy methods—manage cleanup yourself.
• Conditional creation: if a BeanPostProcessor proxies/wraps the bean, your postProcessAfterInitialization() runs on the proxy.
• Async resources: make sure background threads or schedulers are shut down in @PreDestroy.
• Testing: with @SpringBootTest, the context closes after tests, so @PreDestroy will run—avoid long-running cleanup.

🔄 Lifecycle Flow:

      graph TD
    A[Bean Instantiation] --> B[Populate Properties / Dependency Injection]
    B --> C[Aware Interfaces: setBeanName/Factory/Context]
    C --> D[BeanPostProcessor: postProcessBeforeInitialization()]
    D --> E[@PostConstruct → afterPropertiesSet() → initMethod]
    E --> F[BeanPostProcessor: postProcessAfterInitialization()]
    F --> G[Bean Ready for Use]
    G --> H[@PreDestroy → destroy() → destroyMethod]