Free tools Windows power users keep installed
One-click scans. No signup required.
The Spring bean lifecycle is the sequence Spring uses to create an object, configure its dependencies, run initialization callbacks, make it available to the application, and—when the bean’s scope and container ownership allow it—run cleanup callbacks. For initialization, @PostConstruct runs before InitializingBean.afterPropertiesSet(), which runs before a configured custom init method. Destruction callbacks run in the corresponding order: @PreDestroy, DisposableBean.destroy(), then a configured custom destroy method.
What happens during a Spring bean’s lifecycle?
A bean’s lifecycle begins when a Spring container creates its instance. Spring then supplies its configured dependencies and applies the initialization and post-processing steps associated with that bean. Once ready, the bean is made available according to its scope. When the container shuts down or otherwise destroys a managed bean, Spring may run its destruction callbacks.
- Create: Spring instantiates the bean.
- Configure: Spring injects or otherwise supplies the bean’s dependencies and configuration.
- Process before initialization: Registered
BeanPostProcessors can inspect or alter the bean before its initialization callbacks. - Initialize: Spring invokes applicable initialization callbacks in their defined order.
- Process after initialization: Post-processors can further process the bean, including returning a wrapper or proxy in place of the original instance.
- Use and destroy: The bean is available according to its scope. If Spring controls its destruction, applicable cleanup callbacks run when it is destroyed.
Post-processing can occur on both sides of initialization callbacks. It is not a single step that always happens only after initialization: postProcessBeforeInitialization and postProcessAfterInitialization provide distinct opportunities around those callbacks.
In what order do initialization callbacks run?
Spring supports three common ways to define initialization work. When a bean uses more than one, Spring’s documented order is annotation, interface, then configured method.
#1 Best Overall
| Mechanism | When it runs | Coupling or configuration |
|---|---|---|
@PostConstruct |
First, after dependency configuration | Annotation on a bean method; current Spring 6.x uses jakarta.annotation.PostConstruct. |
InitializingBean.afterPropertiesSet() |
After @PostConstruct |
Requires the bean to implement a Spring-specific interface. |
| Configured init method | After afterPropertiesSet() |
Named in the bean’s configuration, for example with @Bean(initMethod = "initialize"). |
Use initialization callbacks for setup that needs the bean’s dependencies to be available. Spring’s general guidance favors @PostConstruct over implementing InitializingBean when you want to avoid coupling application classes to a Spring interface. A configured method can also keep lifecycle configuration outside the class.
If the same method is designated through more than one callback mechanism, Spring avoids invoking that method twice. Do not rely on duplicate declarations to make setup run repeatedly.
In what order do destruction callbacks run?
For a bean whose destruction Spring manages, the order is @PreDestroy, then DisposableBean.destroy(), then a configured custom destroy method.
| Mechanism | When it runs | Coupling or configuration |
|---|---|---|
@PreDestroy |
First | Annotation on a cleanup method; current Spring 6.x uses jakarta.annotation.PreDestroy. |
DisposableBean.destroy() |
After @PreDestroy |
Requires the bean to implement a Spring-specific interface. |
| Configured destroy method | After destroy() |
Named in the bean’s configuration, for example with @Bean(destroyMethod = "close"). |
The @Bean API also documents inference of public no-argument close() or shutdown() methods as destroy methods, unless that inference is disabled. This inference is separate from Spring’s detection of DisposableBean.
Rank #3
Destruction callbacks are for releasing resources or performing cleanup, not for guaranteeing work at every possible process exit. A container must get an opportunity to destroy the bean; an abrupt termination cannot be treated as a reliable callback trigger. Spring’s general guidance prefers @PreDestroy to implementing DisposableBean when avoiding Spring-specific coupling matters.
Why might a BeanPostProcessor not be applied?
A BeanPostProcessor is Spring’s main extension point for custom logic around bean initialization. Spring also uses post-processors internally—for example, to recognize lifecycle annotations. A processor can return the original bean or a wrapped or proxied object, so the object ultimately injected elsewhere may not be the same instance that was first created.
- Check registration and timing. The processor must be registered with the relevant bean factory early enough to participate in that bean’s creation. If a bean is created before the processor is available, it cannot receive that processor’s treatment retroactively.
- Check which callback is involved. Logic in
postProcessBeforeInitializationandpostProcessAfterInitializationruns at different points. Compare the expected behavior with the callback where the logic is implemented. - Check the bean actually being used. A processor may wrap a target. Inspect the bean reference obtained from the container rather than assuming that reference is the original instance.
- Check early creation and ordering. Infrastructure setup and processor ordering affect which beans are eligible for processing. Review how the processor is declared and whether the bean is being instantiated before that infrastructure is ready.
When a lifecycle annotation is not firing, also verify that the annotation comes from jakarta.annotation in a Spring 6.x application and that the annotation-processing infrastructure is present.
Which annotation package should a current Spring application use?
Spring Framework 6.x processes jakarta.annotation.PostConstruct and jakarta.annotation.PreDestroy through CommonAnnotationBeanPostProcessor. The older javax.annotation package was separated from the JDK modules after JDK 9 and removed from the core JDK by JDK 11. As a result, a current application may need the Jakarta annotation API dependency rather than expecting those types to come with the JDK.
Best Value
Check the import in the source file as well as the project’s dependencies. An annotation with the familiar name from the wrong package is not interchangeable with the Jakarta annotation Spring 6.x processes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Does Spring destroy prototype beans?
Not automatically in the same way it manages singleton destruction. The default scope for an @Bean is singleton. Spring retains and manages singleton beans in the factory, including their destruction callbacks when the factory shuts down. A prototype bean is created for the requesting code, and Spring does not guarantee to track each instance through destruction.
| Scope or ownership | Destruction behavior | What to plan for |
|---|---|---|
| Singleton managed by the factory | Spring manages applicable destruction callbacks as part of factory shutdown. | Use the callback mechanism appropriate for the cleanup. |
| Prototype | Spring does not guarantee destruction callbacks for each instance. | Arrange explicit cleanup in the code that obtains or owns the instance, especially if it holds resources. |
| Other scopes | Destruction guarantees depend on the scope and whether the factory controls that bean’s lifecycle. | Check the lifecycle contract for the particular scope rather than assuming singleton behavior. |
When should a component use Lifecycle or SmartLifecycle?
Initialization callbacks prepare a bean after its dependencies have been set. They are not the right mechanism for coordinating a component’s ongoing start and stop with the application context. For managed background processes or other components that must participate in context startup and shutdown, use Spring’s Lifecycle or SmartLifecycle model.
Also consider where expensive work belongs. Regular singleton creation happens under a creation lock, so lengthy work in an initialization callback can affect startup and bean creation. If work should happen after singleton creation, Spring’s reference points to later hooks such as SmartInitializingSingleton or a context refresh event.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
