The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A Spring-managed bean is created and populated, passes through initialization callbacks and post-processors, and may later receive destruction callbacks when its container-managed lifecycle ends. A post-processor can expose a proxy instead of the original instance. These steps describe the ordinary managed-bean path; not every Java object is managed by Spring, and not every bean is created eagerly.
What Spring means by a bean lifecycle
Spring works from bean definitions: metadata describing how a bean is created, its scope, dependencies and properties, and any configured initialization or destruction methods. A context can also register existing objects that were created outside the ordinary bean-definition process. The lifecycle callbacks discussed here apply to objects managed by the relevant Spring container.
As an Amazon Associate I earn from qualifying purchases.
For an ordinary managed bean, the useful ordering model is: instantiate and populate dependencies; run pre-initialization post-processors; invoke initialization callbacks; run post-initialization post-processors; and, when managed destruction is triggered, invoke destruction callbacks. The Spring Framework reference describes these container behaviors beneath Spring Boot.
Recommended Free Tools
How a bean is created and initialized
Instantiation and dependency population
The container creates the instance described by its bean definition and populates configured dependencies and properties. Ordinary initialization callbacks run after this population, so they can use the values injected into the bean.
#1 Best Overall
Post-processors before initialization
A BeanPostProcessor receives the populated bean through postProcessBeforeInitialization. It can return the same instance or another object, such as a wrapper. This callback is part of instance processing; changing bean-definition metadata is the job of a BeanFactoryPostProcessor, not a BeanPostProcessor. See the Spring Framework container extension points.
Initialization callbacks
Spring documents this order for the standard initialization callbacks:
@PostConstructInitializingBean.afterPropertiesSet()- A configured custom init method
These callbacks are alternatives as well as compatible mechanisms: a bean may use more than one, but each adds work to its startup path. Spring generally recommends @PostConstruct or a plain Java method configured as the init method when you want to avoid coupling the bean directly to a Spring callback interface. The Spring reference on customizing a bean describes the callback order and options.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Post-processors after initialization and proxies
After initialization callbacks, Spring invokes postProcessAfterInitialization. This is a common place for infrastructure such as Spring AOP to wrap a bean. As a result, code retrieving the bean may receive a proxy or another wrapper rather than the original object. The proxy is the instance through which the application interacts with the bean; the original instance is not necessarily the object exposed by the container.
There is a documented exception to the simple sequence: an InstantiationAwareBeanPostProcessor can short-circuit ordinary instantiation through postProcessBeforeInstantiation. In that case, the BeanPostProcessor API notes that a callback can occur after this short-circuit, unlike the usual callbacks. Treat the sequence above as the ordinary path, not a guarantee covering every specialized creation path. See the BeanPostProcessor API.
Which initialization and destruction callback should you use?
| Mechanism | Where it is declared | Spring-specific coupling | Typical role |
|---|---|---|---|
@PostConstruct / @PreDestroy |
On methods in the bean class | No direct implementation of a Spring callback interface | Per-bean initialization and cleanup callbacks |
InitializingBean.afterPropertiesSet() / DisposableBean.destroy() |
Implemented by the bean class | Yes | Per-bean callbacks using Spring interfaces |
| Configured init / destroy method | Bean metadata or an @Bean declaration |
No interface implementation required | Call a plain bean method at initialization or destruction |
Lifecycle.start() / Lifecycle.stop() |
Implemented by a bean participating in context lifecycle signals | Yes | Context-coordinated start and stop behavior, not per-bean init and destroy callbacks |
For @Bean methods, Spring supports the regular callback mechanisms and lets you name methods with initMethod and destroyMethod. For example, @Bean(initMethod = "open", destroyMethod = "close") configures ordinary methods without requiring the returned object to implement Spring callback interfaces. The Spring reference for @Bean explains these options.
Rank #4
What happens when a bean is destroyed?
When the container manages the bean’s destruction and triggers it, Spring documents this callback order:
Free tools Windows power users keep installed
One-click scans. No signup required.
@PreDestroyDisposableBean.destroy()- A configured custom destroy method
This is container-managed cleanup, not Java garbage collection. A bean may not receive these callbacks if Spring does not manage its destruction or if destruction is not triggered for its lifecycle.
Automatic close and shutdown inference
For an @Bean method, Spring infers a destruction method for a public close or shutdown method by default. If the resource is managed elsewhere—for example, an externally managed JNDI DataSource—calling that method as if Spring owned the resource’s lifecycle may be inappropriate. Use @Bean(destroyMethod = "") to disable the inferred destruction method when needed.
How Lifecycle start and stop differ
The Lifecycle interface’s start() and stop() signals are coordinated through the ApplicationContext‘s LifecycleProcessor when the context receives start or stop events. They express context-level lifecycle behavior; they do not replace the per-bean initialization callbacks or destruction callbacks described above. A bean can participate in these signals while also having its own initialization or cleanup callbacks.
Why post-processor configuration can affect other beans
Post-processors are local to their own container. An application context detects post-processor beans, but creates post-processors and beans directly referenced by them early. Beans instantiated too early may not be eligible for full post-processing, including auto-proxying.
When declaring a post-processor with @Bean, give the factory method a return type that identifies the post-processor clearly. Make the method static and, ideally, dependency-free. This reduces the risk that creating the post-processor will force early initialization of its configuration class or other beans. The container extension point guidance covers these timing and declaration cautions.
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.
