core
Bean Lifecycle & Scopes
Control when beans are created, initialized, and destroyed — and how many instances exist.
A Spring bean is not just constructed and forgotten — it moves through a defined lifecycle from instantiation, through dependency injection and initialisation callbacks, to destruction when the context closes. Knowing this sequence lets you hook in setup and teardown logic at the right moment, and understanding scopes tells you how many instances exist and how long each lives.
A singleton is the office coffee machine — one for everyone. A prototype is a paper cup — fresh each time. Request scope is a desk for the duration of one visitor.
Key Concepts
1
After Spring instantiates a bean and injects its dependencies, it runs initialisation callbacks in order: methods annotated @PostConstruct, then afterPropertiesSet if the bean implements InitializingBean, then any custom initMethod. This is where you open resources, validate configuration, or warm a cache — safely, because all dependencies are now wired. At shutdown, the mirror image runs: @PreDestroy, then DisposableBean.destroy, then a custom destroyMethod, giving you a place to close connections and flush buffers. Scope determines instance count and lifetime: the default singleton means one shared instance per container, created eagerly at startup; prototype creates a fresh instance on every injection or lookup; and web scopes request and session tie a bean's life to an HTTP request or user session.
@PostConstructafterPropertiesSetInitializingBeaninitMethod@PreDestroy
2
The classic interview trap lives at the intersection of scopes: injecting a shorter-lived bean (prototype or request) into a long-lived singleton. Because the singleton is wired once at startup, it captures a single instance of the inner bean and never asks for a new one, defeating the shorter scope. The fix is a scoped proxy or a Provider/ObjectFactory lookup. It is also worth knowing that Spring does not manage the full lifecycle of prototype beans — it creates and hands them over but does not call their destroy callbacks, so cleanup is the caller's responsibility.
ProviderObjectFactory
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What scopes exist and which is the default?" *Probing:* the fundamentals. *Stalls:* "One per
app." *Moves up:* singleton by default, plus prototype, and request, session and application in a
web context.
1. "What scopes exist and which is the default?"
5
2. "What is the danger of injecting prototype into singleton?" *Probing:* the classic trap.
*Stalls:* "None." *Moves up:* it is injected once, so the singleton keeps the same instance forever
— a provider or lookup method is needed for a fresh one.
2. "What is the danger of injecting prototype into singleton?"
6
3. "Are singleton beans thread-safe?" *Probing:* the critical point. *Stalls:* "Yes." *Moves
up:* not automatically — one instance serves every request, so mutable state in a singleton is a
race condition.
3. "Are singleton beans thread-safe?"
7
4. "What are the lifecycle callbacks?" *Probing:* the detail. *Stalls:* "A constructor." *Moves
up:* @PostConstruct after injection and @PreDestroy before shutdown, plus the InitializingBean and
DisposableBean interfaces.
4. "What are the lifecycle callbacks?"