Spring Bean Scopes: Singleton, Prototype, Request, Session, Application
Fast recall
Quick revision
Core answer
ServletContext. `@RefreshScope` (Spring Cloud) re-creates the bean when config changes. Common pitfalls: injecting a prototype bean into a singleton freezes it to one instance (use ObjectProvider, @Lookup, or scoped proxy); stateful singletons cause race conditions; request-scoped beans require an active HTTP request. Default: keep beans singleton and stateless; use prototype rarely; avoid session-scope for horizontally scaled apps unless sticky sessions or a shared session store are in place.Understanding of scope trade-offs, prototype injection into singleton pitfall, stateless design
Treating singletons as stateful; naive @Autowired of prototype; session-scope in scaled-out apps
Discuss ObjectProvider, @Lookup, scoped proxy modes, @RefreshScope, thread-safety implications
Interview-ready guide
Interview answer
Spring's default is singleton — one instance per container, shared everywhere. Prototype creates a new instance every request. Request, session, and application scopes are web-only and tie the bean's lifetime to HTTP artifacts.
Spring Core scopes
- singleton — one per
ApplicationContext, shared - prototype — new instance every request; Spring stops managing it after construction
Web-aware scopes
- request — one per HTTP request
- session — one per HTTP session
- application — one per
ServletContext - websocket — one per WebSocket session
Additional
@RefreshScope(Spring Cloud) — recreated on/actuator/refresh
The classic pitfall — prototype injected into singleton
@Autowiredruns once at bean construction; the singleton gets one prototype instance forever- Fix with
ObjectProvider(recommended),@Lookup, or scoped proxy withproxyMode = TARGET_CLASS - Same fix needed for request/session-scoped beans injected into singletons
Best practice by scope
- singleton — 99% of beans, must be stateless and thread-safe
- prototype — rare; only when per-use mutable state is genuine; remember Spring won't run
@PreDestroy - request — per-request caches and tracing; MDC often simpler
- session — wizards and preferences; avoid in horizontally scaled apps without Spring Session + Redis or sticky sessions
Strategic take
- Default to stateless singletons — that's what makes Spring apps scale horizontally
- Fighting that default usually means you're storing state in the wrong place
Spring Bean Scopes: Singleton, Prototype, Request, Session, Application
Direct Answer
Spring's default is singleton — one instance per container, cached and reused. Prototype creates a new instance every time it's requested; useful for stateful helpers but Spring does not destroy them (you manage lifecycle). Request, session, and application scopes (web only) tie a bean's lifetime to an HTTP request, session, or ServletContext. @RefreshScope (Spring Cloud) re-creates the bean when config changes. Common pitfalls: injecting a prototype bean into a singleton freezes it to one instance (use ObjectProvider<T>, @Lookup, or scoped proxy); stateful singletons cause race conditions; request-scoped beans require an active HTTP request. Default: keep beans singleton and stateless; use prototype rarely; avoid session-scope for horizontally scaled apps unless sticky sessions or a shared session store are in place.
Common Mistakes & Pitfalls
Treating singletons as stateful; naive @Autowired of prototype; session-scope in scaled-out apps
Check your understanding
Answer these without looking back at the article.
- What's the pitfall of @Autowired-ing a prototype into a singleton?
- How does ScopedProxyMode.TARGET_CLASS work under the hood?
- Why avoid session scope in horizontally scaled apps?
- How do you implement a custom tenant-scoped bean?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.