Spring Bean Lifecycle
Fast recall
Quick revision
Core answer
@Autowired fields/setters) → `*Aware` callbacks (BeanNameAware, ApplicationContextAware) → `BeanPostProcessor.postProcessBeforeInitialization` → initialization callbacks (@PostConstruct → InitializingBean.afterPropertiesSet() → @Bean(initMethod)) → `BeanPostProcessor.postProcessAfterInitialization` (where AOP proxies are created) → bean ready → `@PreDestroy` on context shutdown. Two facts most developers miss: `@Autowired` fields are null in the constructor body (field injection fires after construction), and `@PreDestroy` never runs on prototype beans or on SIGKILL — only on graceful singleton shutdown.Whether the candidate understands the container's role and can reason about ordering bugs (e.g., using a dependency before injection is complete).
Confusing @PostConstruct with the constructor, or not knowing that InitializingBean.afterPropertiesSet runs before @PostConstruct.
Mention BeanPostProcessor hooks (postProcessBeforeInitialization / postProcessAfterInitialization) and how they power AOP proxying.
Interview-ready guide
Interview answer
The Spring bean lifecycle is a precisely ordered sequence of phases. Every annotation-driven feature — @Autowired, @PostConstruct, @Transactional, @PreDestroy — fires at a specific point in that sequence. Knowing the order explains the bugs.
Instantiation and injection
- Constructor injection: dependencies are resolved first, then the constructor runs — the object is fully wired from line one
- Field/setter injection: the constructor runs first (no-arg), then
AutowiredAnnotationBeanPostProcessorfires inpostProcessProperties—@Autowiredfields are null inside the constructor body
Initialization callbacks — in this order
@PostConstructfires first — the safe place for startup logic that depends on injected collaboratorsInitializingBean.afterPropertiesSet()fires second — Spring's older interface approach, avoid in new code@Bean(initMethod)fires last — for third-party classes you cannot annotate
`BeanPostProcessor` — where proxies are created
postProcessAfterInitializationruns after all callbacks; it can return a different object- This is how
@Transactional,@Async, and@Cacheablereplace the bean with a CGLIB proxy - Self-invocation via
thisbypasses the proxy — which is why@Transactionalon an internal call does not work
Destruction
@PreDestroyruns on singletons in reverse creation order when the context shuts down- Prototype beans are handed off and never get
@PreDestroy— Spring cannot call what it does not track - SIGKILL skips destruction entirely — only SIGTERM and explicit
context.close()trigger callbacks
Spring Bean Lifecycle
Direct Answer
A Spring bean follows a precise sequence: instantiation (constructor) → dependency injection (@Autowired fields/setters) → *Aware callbacks (BeanNameAware, ApplicationContextAware) → BeanPostProcessor.postProcessBeforeInitialization → initialization callbacks (@PostConstruct → InitializingBean.afterPropertiesSet() → @Bean(initMethod)) → BeanPostProcessor.postProcessAfterInitialization (where AOP proxies are created) → bean ready → @PreDestroy on context shutdown. Two facts most developers miss: @Autowired fields are null in the constructor body (field injection fires after construction), and @PreDestroy never runs on prototype beans or on SIGKILL — only on graceful singleton shutdown.
Common Mistakes & Pitfalls
Confusing @PostConstruct with the constructor, or not knowing that InitializingBean.afterPropertiesSet runs before @PostConstruct.
Check your understanding
Answer these without looking back at the article.
- What happens to prototype-scoped beans during destruction — does Spring call @PreDestroy on them?
- How does BeanPostProcessor differ from BeanFactoryPostProcessor?
- Why does calling a @Transactional method via 'this' bypass the transaction?
- What is the difference between @PostConstruct and InitializingBean.afterPropertiesSet?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.