Spring Bean Scopes
Bean scopes determine how many instances Spring creates and how long those managed instances remain available. The most common scope is `singleton`; `prototype`, `request`, and `session` scopes change instance lifetime to match different application needs.
A Spring bean scope defines the lifecycle and sharing rules for an object managed by the Spring container. The scope is selected with annotations such as `@Scope("prototype")` or `@RequestScope`, or through configuration.
The default scope is `singleton`. Spring creates one bean instance per application context, and requests for that bean normally return the same instance. This is different from the GoF Singleton pattern because Spring controls the instance within its container rather than enforcing a process-wide static singleton.
With `prototype`, Spring creates a new instance each time the container is asked for that bean. Spring manages creation and dependency injection, but after returning a prototype object, the container generally does not manage its complete destruction lifecycle.
Web applications can use `request` and `session` scopes. A request-scoped bean has one instance for an HTTP request, while a session-scoped bean has one instance for an HTTP session. These scopes require an appropriate web-aware application context.
Scope matters when a bean contains mutable state. Stateless services are commonly singleton-scoped, while state tied to a request or user session may need a narrower scope. Injecting a shorter-lived bean into a longer-lived singleton may require a proxy or another indirection so the correct instance can be resolved at use time.
Key points
- `singleton` is the default Spring bean scope and provides one instance per application context.
- `prototype` creates a new instance whenever the Spring container obtains the bean.
- `request` creates one instance per HTTP request.
- `session` creates one instance per HTTP session.
- Scope should match the lifetime of the state a bean owns.
- A shorter-lived bean injected into a longer-lived bean may require a scoped proxy or provider.
Interview questions
Is a Spring singleton thread-safe?
No. Singleton scope controls how many instances Spring creates; it does not automatically make the instance thread-safe. In a web application, many requests can invoke the same singleton concurrently. Singleton beans should therefore generally avoid mutable shared state or protect such state with an appropriate concurrency mechanism.
When would you use request scope or session scope?
Request scope is appropriate when state should exist only during one HTTP request. Session scope is useful when state should persist across multiple requests associated with the same HTTP session. Both should be used deliberately because storing mutable conversational state in server-side objects affects concurrency, memory usage, and application design.
What is the default scope of a Spring bean?
The default Spring bean scope is `singleton`. Spring normally creates one instance of that bean for a given application context and returns that instance when the bean is requested again. It does not mean there can only be one instance across an entire JVM. Multiple application contexts can therefore have separate singleton instances.
What happens when a bean is declared with prototype scope?
Spring creates a new instance whenever the container obtains the prototype bean. This is useful when each consumer needs an independently stateful object. Spring still performs dependency injection and initialization, but its lifecycle management after creation is more limited than for singleton beans.
Why can directly injecting a prototype bean into a singleton be surprising?
A singleton is created once, so a directly injected prototype dependency is normally resolved when that singleton is constructed. Repeated calls on the singleton therefore keep using the same injected prototype object. If a fresh prototype is required for each operation, use an appropriate indirection such as `ObjectProvider`, `Provider`, or a scoped proxy.