Explain Bean Scopes.

Hook: Bean scopes are Spring’s way of answering a simple but important question: who owns this object, and for how long? Interviewers love this because it reveals whether you understand both dependency injection and object lifecycle.

Question: Explain Bean Scopes.

Answer: A bean scope tells Spring how many instances of a bean to create and how long to keep them. The default is singleton, which means one shared instance per Spring application context. Other common scopes are prototype for a new instance on each lookup, and web scopes like request and session for per-request or per-user state.

Interview-Ready Answer: In Spring Boot, a bean scope defines the lifecycle and visibility of a bean. By default, beans are singleton, so I get one shared instance per application context. If I need a fresh object each time, I use prototype; and in web apps, I can use request or session scope for request-specific or user-specific state. One important detail is that Spring manages singleton destruction automatically, but prototype beans are created on demand and are not fully tracked for cleanup.

What a bean scope means

A scope is the rule Spring uses to decide whether to reuse an object or create a new one. Think of the application context as a factory plus a registry: the scope tells Spring whether to cache the result or hand out fresh copies. In modern Spring Boot, the default is still singleton in both Boot 2 and Boot 3.

1. Spring reads the bean definition and stores the scope metadata with it.
2. When a singleton bean is requested the first time, Spring creates it, resolves its dependencies, applies post-processors, and stores it in the singleton cache.
3. Later requests for the same singleton return the cached instance, so lookup is effectively O(1) after creation.
4. When a prototype bean is requested, Spring creates a brand-new instance every time and does not keep it in the singleton cache.
5. For web scopes such as request or session, Spring stores the bean in request or session attributes, and a proxy is often used so a singleton can refer to it safely.
6. On shutdown, Spring destroys singleton beans and calls their cleanup callbacks, but prototype beans are not automatically destroyed by the container.

Common scopes and when to use them

Use singleton for most services, repositories, utilities, and clients because it is simple and memory-efficient. Use prototype only when you truly need a fresh object every time, usually with mutable state. Use request or session scope only in web applications, and prefer them for user-specific state rather than putting that state into a singleton.

How injection changes the story

The tricky part is not the scope annotation itself, but how you inject the bean. If you inject a prototype bean directly into a singleton, the singleton gets one prototype instance at creation time and then keeps it forever. That surprises many candidates because they expect a new prototype every method call. If you need a fresh prototype inside a singleton, use ObjectProvider, Provider, or method lookup so Spring can fetch a new instance at the moment you need it.

For request and session scope, Spring usually creates a proxy, which is a small wrapper that looks like the bean but resolves the real object only when there is an active request or session. Without a proxy or provider, a singleton trying to use a request-scoped bean can fail because there is no active web request during startup.

Performance and edge cases

From a practical point of view, singleton lookup is cheap after the first creation, while prototype creation pays the full cost each time: object allocation, dependency wiring, and any initialization logic. If a prototype bean graph is large, repeated creation can become expensive under load. The real risk, though, is usually correctness rather than speed: shared mutable singletons can cause data leaks across users, and misused prototypes can create hidden stale state.

Two important gotchas interviewers like to probe:

• Singleton does not mean thread-safe. It only means one instance exists; if that instance has mutable fields, multiple threads can still race on them.
• Prototype does not mean auto-managed forever. Spring creates it, but you own cleanup of external resources like sockets, files, or threads.

Real-World Story: Imagine an e-commerce checkout service. The team uses Spring Boot for the pricing engine, tax calculator, and cart flow. The pricing service stays singleton because it is stateless, but the cart state should be per user session. A developer accidentally makes the cart holder a singleton because it looks like a simple helper bean.

Under load, user A adds a laptop, user B adds headphones, and both requests hit the same Java object. Now totals change unpredictably, coupons appear on the wrong account, and support tickets start saying, "My cart changed by itself." In logs, you may see the same bean identity or hash-like value repeated across requests, and the checkout API may return inconsistent totals even though the database is fine.

The outage symptom is subtle at first: items seem to flicker in the UI, totals are wrong only under concurrency, and tests pass locally because one user at a time does not expose the shared-state bug. The fix is to keep the service singleton and stateless, move user data into session scope or the HTTP layer, and avoid storing mutable user-specific fields in shared beans.

Follow-up & Tricky Questions:

• How do you inject a prototype bean into a singleton? Use ObjectProvider, Provider, or lookup methods so the singleton asks Spring for a new instance only when it needs one.
• What happens to prototype beans when the application shuts down? Spring does not manage their full destruction lifecycle, so @PreDestroy is not called automatically for them.
• When should I use request scope vs session scope? Use request scope for data that lives for one HTTP call, and session scope for user-specific state that must survive across multiple requests in the same login session.
• What is application scope? It is one bean per ServletContext, so it is shared by the entire web application, not by one user.
• Does singleton mean thread-safe? No. It only means one instance exists in the container; if that instance has mutable state, you still need to make access safe across threads.
• Can I inject a request-scoped bean directly into a singleton? Not safely without a proxy or provider. The singleton is created at startup, but a request-scoped bean only exists when there is an active web request.
• Does prototype create a new object on every method call? No, it creates a new object on every container lookup. If a singleton stores one prototype in a field, that field still points to the same object.
• Is prototype enough for cleanup of files or sockets? No. Prototype only changes creation timing; if the bean owns external resources, you must close them yourself or use a managed lifecycle elsewhere.

Common Mistakes:

• Putting mutable user data in a singleton — correction: keep singleton beans stateless, or move per-user data to request/session scope.
• Thinking prototype means auto-cleaned-up — correction: Spring creates prototypes, but you are responsible for resource cleanup.
• Assuming direct injection of a prototype gives a fresh object each time — correction: direct injection happens once during singleton creation; use ObjectProvider or a proxy for lazy retrieval.
• Confusing scope with thread safety — correction: scope is about lifecycle and sharing, not automatic safety under concurrency.

Memory Hook: Remember this picture: singleton = one house key for everyone, prototype = a new key every time you ask, request = a key that works for one visit, session = a key that lasts for one guest stay.

Cheat Sheet:

• Default bean scope in Spring Boot is singleton.
• singleton means one instance per application context.
• prototype means a new instance on each lookup.
• Request/session/application scopes are for web apps.
• Singletons are shared; make them stateless when possible.
• Prototype beans are not automatically destroyed by Spring.

Practice Tasks:

• Create one singleton bean and verify that two lookups return the same object.
• Create a prototype bean and print two different IDs from two lookups.
• Inject a prototype into a singleton, then fix the stale-instance problem with ObjectProvider.