Detailed explanation
Spring bean scopes define how long a bean instance lives and where that instance is shared. A bean is an object managed by Spring’s IoC container, and its scope determines whether looking up or injecting it reuses an existing object or creates another one. Scope matters when designing services that hold mutable state: sharing user-specific data through a singleton can leak information between requests or cause concurrency bugs. Stateless services and repositories are normally good candidates for singleton scope.
Singleton is the default: Spring maintains one instance per bean definition per container, not one instance per Java class or JVM. Two bean definitions using the same class can therefore produce two singleton objects. Prototype creates a new instance each time that bean is requested from the container, such as through getBean() or ObjectProvider.getObject(). For example, @Component @Scope("prototype") class ShoppingCart {} declares a prototype component. Here, “requested” means a container lookup or dependency resolution, not necessarily an HTTP request. Spring creates, configures, and initializes prototype beans but does not automatically invoke their destruction callbacks; cleanup is the caller’s responsibility.
Web-aware contexts support request, session, and application scopes. Request scope provides one instance per HTTP request; session scope provides one per HTTP session across multiple requests; application scope provides one per ServletContext. Application scope differs from singleton because multiple Spring contexts can share one ServletContext. Spring also supports websocket scope, which binds a bean to a WebSocket session. These scopes require the relevant web infrastructure and active lifecycle context; they are not generally available in a plain standalone container.
A key interview detail is how scopes interact during injection. Injecting a prototype directly into a singleton resolves it once when the singleton is created, so subsequent calls reuse that injected instance. Use ObjectProvider or lookup-method injection when a fresh prototype is needed for each operation. For request- or session-scoped dependencies inside singletons, a scoped proxy can delegate calls to the instance for the current request or session. Finally, scope controls identity and lifetime, not thread safety: singleton beans need safe shared-state handling, and concurrent requests can access the same session-scoped bean.
Key points to remember
- Singleton is the default: one instance per bean definition per Spring container.
- Prototype creates a new instance for each container lookup or dependency resolution, not each HTTP request.
- Request, session, application, and websocket scopes bind instances to their respective web lifecycles.
- Direct injection of a prototype into a singleton happens once; use ObjectProvider for repeated fresh instances.
- Spring does not automatically run prototype destruction callbacks, and no scope inherently guarantees thread safety.
Common mistakes candidates make
- Describing a Spring singleton as one object per class across the entire JVM.
- Assuming a prototype dependency injected into a singleton is recreated for every method call.
- Storing user-specific mutable state in singleton beans or assuming session-scoped beans cannot face concurrent access.
Likely follow-up questions
How do you obtain a fresh prototype bean from a singleton?
Inject ObjectProvider<ShoppingCart> into the singleton and call getObject() whenever a new cart is required. Lookup-method injection using @Lookup is another option.
How can a singleton safely reference a request-scoped bean?
Use a scoped proxy, for example through @RequestScope, which enables a class-based proxy by default. The singleton holds the proxy, and calls are delegated to the bean associated with the active request; calling it without an active request normally fails.
When would session scope be more suitable than prototype scope for a shopping cart?
Session scope is suitable when the same cart must remain available across multiple requests in a user's HTTP session. Prototype scope creates independent objects but does not preserve or associate them with a user automatically.
Interview tip: Start with singleton and prototype, explain the web scopes, then demonstrate your understanding with the prototype-in-singleton injection caveat.