Lesson 6 · Spring Core

Bean Lifecycle & Proxies

What happens between "the container starts" and "your bean is ready" — and how Spring slips extra behaviour in without you seeing it.

Why this lesson matters most Nearly every Spring feature is a post-processor adding behaviour during the bean lifecycle. @Value, @PostConstruct, AOP, @Transactional, @Repository translation — all of them. Understand the lifecycle and these stop being magic.

The lifecycle, in order

Memorise this sequence — the exam asks "what runs first/last" repeatedly:

Bean definitions loaded — metadata read from config (annotations / Java / XML)
BeanFactoryPostProcessors run — modify the definitions (e.g. resolve ${...}) before any bean exists
Instantiate — the constructor runs
Populate properties — dependencies injected (@Autowired)
Aware callbacks — BeanNameAware, BeanFactoryAware, ApplicationContextAware
BeanPostProcessor — postProcessBeforeInitialization
@PostConstruct
InitializingBean.afterPropertiesSet()
Custom init-method
BeanPostProcessor — postProcessAfterInitialization ← proxies are created here
Bean is ready to use

Then at shutdown: @PreDestroy → DisposableBean.destroy() → custom destroy-method. (Recall from Lesson 4: prototype beans get none of these destroy callbacks.)

The two post-processors — don't confuse them

	`BeanFactoryPostProcessor` (BFPP)	`BeanPostProcessor` (BPP)
Operates on	Bean definitions (metadata)	Bean instances (objects)
When	Before any bean is instantiated	Around each bean's initialization (before & after)
Runs…	First	After all BFPPs
Classic example	`PropertySourcesPlaceholderConfigurer` (resolves `${...}`)	`AutowiredAnnotationBeanPostProcessor` (`@Autowired`/`@Value`); the AOP auto-proxy creator

The memory hook BFPP works on the bean factory's blueprints before beans exist. BPP works on the beans themselves. Both are auto-detected when declared as beans in an ApplicationContext.

How proxies add behaviour at runtime

That last BPP step (postProcessAfterInitialization) is where Spring can return a proxy wrapping your bean instead of the bean itself. The proxy intercepts calls and runs extra logic — transactions, security, AOP advice — around your real method.

Proxy type	Used when	How	Limitation
JDK dynamic proxy	Target implements an interface	Proxy implements the same interface	Only interface methods are advised
CGLIB	No interface (or `proxyTargetClass=true`)	Proxy subclasses the target	Class & methods must not be `final`

Self-invocation defeats the proxy Advice only runs when a call goes through the proxy. If a method calls another method on the same object via this.other(), that call never leaves the object, so the proxy is bypassed and its advice (e.g. a @Transactional(REQUIRES_NEW) on other()) does not run. This is the single most common AOP/transaction bug — and a favourite exam question.

Bean creation order

By default, order follows dependencies — a bean is created after the beans it depends on, so its collaborators exist when it's wired.
No dependency but need ordering? Use @DependsOn("otherBean") to force a bean to be created after named beans.
@Order is not for creation order — it orders items within a collection (e.g. a List of beans, or AOP advisor precedence), not the sequence of bean creation.
Post-processors are instantiated early, before the ordinary beans they act on.

Injecting by type — the recurring pitfall (1.5.5) When more than one bean matches a required type, autowiring-by-type is ambiguous → NoUniqueBeanDefinitionException at startup. Resolve with @Primary on the default, or @Qualifier at the injection point (Lesson 3).

Primary source — read this

Spring Framework 5.3 — Core: Container Extension Points & Lifecycle Callbacks

Read "Customizing beans using a BeanPostProcessor", "Customizing configuration metadata with a BeanFactoryPostProcessor", and "Lifecycle Callbacks".

Check yourself

The BFPP-vs-BPP distinction and self-invocation are the highest-value questions here. Options shuffle on every load.

Then drill the book Container section: the lifecycle-ordering questions (ways to call a method after init; which method runs last), the CGLIB proxy limitations question, and the @DependsOn/creation-order items. Re-run the Container Drill — you've now covered every concept in it.

I'm your teacher — ask me anything. Self-invocation is worth seeing concretely — ask me to show the two-bean fix that makes the transaction actually start. Say "continue" for Lesson 7 — Aspect-Oriented Programming, the last of Spring Core.

← Lesson 5 · Properties, Profiles & SpEL Lesson 7 · AOP → (coming next)