The Complete Bean Lifecycle: From Instantiation to Destruction

A Java object exists the moment you new it, but "exists" and "is safe to use" are two different things. When the constructor returns, your @Autowired fields may still be null; once they are filled you may still need to validate config, warm caches or open connections; and before the process exits those resources must be released. Spring standardises the whole road from "born" to "usable" to "retired" into eight phases and leaves a socket at each one for your own code — that is the bean lifecycle.

Five words, one line each (used throughout):

• Bean: not an object Spring invented, but your plain Java object that you handed to the container to create and manage
• Container: the "housekeeper" object (ApplicationContext) that news your objects, wires their dependencies and manages birth to death; you ask it for things with getBean
• Reflection: the technique of "calling a constructor or method by name at runtime" — the container never hard-codes your class, it builds your object through reflection
• Hook: a slot the framework reserves inside its own flow; put a method in it and the container calls you when it reaches that step
• @PostConstruct: an annotation meaning "all dependencies are filled — run this method before I am used from outside"

Read that timeline left to right and you have the real growth path of a singleton: the further left, the fewer injected fields you can safely read. Section 3 turns it into runnable log output.

After this article you should be able to answer three questions:

• Which runs first, @PostConstruct, afterPropertiesSet or initMethod — and why that order?
• Why does a prototype bean's @PreDestroy never print? Didn't the container promise to manage it?
• At which step is the AOP proxy created, and how does that decide whether @Transactional works inside a constructor?

Start with a "why": why do lifecycle callbacks exist at all? Because an object being "created" and an object being "safe to use" are two different things. When the constructor returns, the object only has memory — dependencies are not injected yet. After injection you may still need to validate config, warm caches or open connections; and when done, you must release resources. Spring standardizes these "insertion points" into eight stages of life.

The eight stages in order: instantiation → population → Aware callbacks → before-init processing → initialization → after-init processing → ready & pooled → destroy callbacks. Note it is a "ring", not a straight line — a singleton goes round once and then lives in the container until it shuts down and takes the final destroy stage.

Here are "who triggers it, where, and what for" in one table:

The table says who triggers each stage; what actually stalls beginners is what is readable at that moment. Can I use an injected field in the constructor? Is the proxy there yet inside @PostConstruct? Click the eight stations one by one — each gives one honest answer:

The ring answers which stations exist; the debugger answers who pushes you along them. On the left is the real skeleton of getBean → doGetBean → doCreateBean; the right panel tracks variables and the call stack as you step. Two things to watch: the cache hit at step ②, and where the pool insert happens at step ⑦:

First call versus second call, drawn once more as an animation — notice how frame ④ (cache hit) and frame ⑤ (prototypes never pool) jointly produce every destroy symptom in Section 5:

Talk is cheap; run it. This bean implements three callback interfaces and layers annotation callbacks on top:

The config class and the bootstrap code:

The console output mapped onto the stages:

Now replay that log against the animation — each frame maps onto one output line: [1] is frame one, [6][7][8] are the final frame. When a second read of the code stalls, use it to locate "which line am I on":

This is a favorite interview follow-up. The answer is precise: during the "after-init" stage, by AbstractAutoProxyCreator#postProcessAfterInitialization.

The destroy stage is full of symmetry — and traps. Four symptoms, one underlying cause (whether the container still holds a reference). Pair them up first and the three rules below become obvious:

• Why are prototypes not destroyed? Because the container lets go immediately after creating one — it keeps no reference, so there is nothing to destroy. Release resources yourself with try-with-resources
• Why reverse order for singletons? DefaultSingletonBeanRegistry records order in disposableBeans, and destroySingletons() iterates backwards
• If @PreDestroy did not run, debug in three steps: "was close() called → is it a singleton → was it ever created"

Reverse ordering is hard to feel from prose alone, so the animation plays "who was built first, who is torn down first" — watch frames ③ and ④ in particular:

Isolate the single most misremembered fork — singleton versus prototype — into one side-by-side picture: on the left the singleton that walks the pipeline once and then sits in the pool; on the right the prototype that re-runs everything per lookup while the container lets go immediately:

Want to find the number-one suspect for slow startup? One custom BeanPostProcessor suffices — it straddles both ends of the lifecycle:

• @PostConstruct precedes afterPropertiesSet because "BPP callbacks" as a whole run before "InitializingBean callbacks"
• To do dependency-related work in a constructor, the only correct approach is constructor injection: public UserService(UserDao dao) — dao is ready before the constructor runs
• With @Autowired field injection, accessing the field in the constructor yields null

The demo below turns the eight stages into an interactive timeline; switch the "prototype" option to see the destroy difference at a glance:

Then switch to the destroy argument to isolate the destroy triple (@PreDestroy → destroy → destroyMethod) and confirm it mirrors the init order exactly.

Knowing the eight stages is not enough — you also need to know who pushes a bean through them. The answer lives in the previous article: step 11 of refresh(), finishBeanFactoryInitialization, walks every non-lazy singleton and drives it down the whole pipeline. This lab spreads the twelve steps out; watch step 11 and see beans pop into existence batch by batch:

Section 8 says "the AOP proxy is born at after-init". Who does the wrapping? The auto-proxy creator — a BeanPostProcessor whose only job is to decide "should this bean be wrapped in a proxy". The lab below unfolds its checkpoint logic: first the candidate check, then the interception inside post-processing:

Finally, back to the population stage itself. How a dependency is injected decides whether the object is still a half-finished shell after step ① — constructor injection is complete at birth, field injection only becomes complete at step ②:

The prototype-does-not-destroy rule from Section 5 is really a scope question. This lab puts all four scopes side by side and counts instances: pick "count the instances" to watch the counter move on every lookup, then "who destroys it" to see the destroy log appear exactly once:

One more special case of "when is it actually born": a FactoryBean definition registers a factory, yet getBean hands you a product. So when does the product exist? Pick "when it really produces" and line it up against getObjectForBeanInstance, the last cell of the debugger in Section 2:

This console is wired to the real container running in your browser; beans, di and query are answered by the kernel on the spot, so every command below tests one claim of this article:

Beginners ask the same two questions: "why does my app take 40 seconds to boot?" and "why did @PreDestroy stop printing after I added @Scope("prototype")?" Neither answer is in your code — both come from how scope and init timing are chosen. The sandbox below folds "scope + lazy or not" into one three-position switch; each position shows startup cost, lookup cost and the destroy log side by side:

A warm-up question, straight from the symmetry table in Section 5:

Now a combined question threading Sections 3, 4, 7 and 8 together:

Copy every snippet below straight into a search box — do not paraphrase or shorten it. Beginners stall in three places: an annotation that silently does nothing, a null field inside a constructor, and a prototype that never gets destroyed.

Row five is the only one that shouts, and its culprit sits in a specific cell of the lifecycle. Skip the answer and click the guilty frame:

Goal: with a minimal runnable project, print the whole chain "constructor → Aware → @PostConstruct → afterPropertiesSet → initMethod → the destroy triple", then watch a prototype lose the last three lines.

Step one, a Maven pom.xml that needs only spring-context and the jakarta annotations:

Step two, the bean (src/main/java/com/example/demo/LifeBean.java):

Step three, the config class and launcher (new Main.java in the same package):

Run main. Expected output — every line must match, otherwise your import came from the wrong package:

Acceptance checklist: ① you can explain why line 1 prints null while line 3 has a value; ② change the @PostConstruct import to a package that does not exist — the app still starts but one line disappears, and you have reproduced "silent failure" yourself; ③ say who invokes lines 6, 7 and 8 respectively.

Change exactly one thing per run and the conclusion flips completely:

1. Add @Scope("prototype") to singletonLife() (remember import org.springframework.context.annotation.Scope;). You will observe lines 1-5 printing as usual and not a single one of 6/7/8; call ctx.getBean(LifeBean.class) twice and 1-5 repeats verbatim. That is the "the container lets go immediately" rule from Section 5 and the comparison figure.
2. Print System.out.println(this.hashCode()) inside @PostConstruct, then compare it with the identity of what getBean returns for a class carrying @Transactional. You will observe the two differ — the proxy is pulled on after your init callback ran.
3. Make customInit() throw new IllegalStateException("config validation failed"). You will observe the entire startup aborting with BeanCreationException: Error creating bean with name 'singletonLife': Invocation of init method failed, while lines 6/7/8 still execute — the "leave no half-built context behind" behaviour from the previous article.

Tip: after variant 1, revisit the sandbox in Section 11, flip the switch to prototype, and confirm both tell exactly the same story.

Write yourself a "lifecycle probe" component so that any future project's slow boot or leaking resource can be measured rather than guessed.

Requirements:

• A LifecycleProbe implementing InstantiationAwareBeanPostProcessor that records each bean's "instantiated at" and "initialization finished at" timestamps
• Additionally distinguish three facts: whether @PostConstruct ran (inferable from the presence of CommonAnnotationBeanPostProcessor), and whether the bean got proxied (compare getClass() of the object returned from postProcessAfterInitialization with the one passed in)
• On shutdown (via SmartLifecycle or a ContextClosedEvent listener) print a summary table: top 10 slowest beans, how many were proxied, and which lazy beans were never created
• Not one line of business bean code may change

Acceptance checklist: ① run it on an empty Boot project and the top 10 includes auto-configured beans such as dataSource; ② mark one bean prototype, fetch it three times, and the table reports three creations; ③ add @Transactional to a bean and it shows up in the "proxied" count; ④ the probe itself costs under 5% extra startup time (verify against the baseline total).