Prototype Bean in Singleton Problem
Fast recall
Quick revision
Core answer
Understanding of how Spring resolves dependencies at container startup and the lifecycle interaction between bean scopes
Assuming Spring creates a new prototype instance each time the singleton uses it, when injection happens only once at singleton creation
Demonstrate all three fixes: ObjectProvider for lazy lookup, @Lookup method injection, and scoped proxies via proxyMode
Interview-ready guide
Interview answer
The problem is that Spring injects dependencies when it creates the singleton bean, not when you call methods on it.
So if you inject a prototype bean into a singleton using constructor or field injection, Spring creates that prototype instance once during application startup. The singleton holds onto that single instance forever, effectively making the prototype behave like a singleton. Let's say you have a RequestProcessor that's prototype-scoped because it holds request-specific data like a request ID.
If you inject it directly into a singleton OrderService, every order processed by that service uses the same RequestProcessor with the same request ID. That defeats the whole purpose. The cleanest fix is ObjectProvider.
Instead of injecting RequestProcessor directly, you inject ObjectProvider of RequestProcessor, then in your method you call provider dot getObject to get a fresh instance each time. Spring also supports @Lookup method injection where you define an abstract method that returns the prototype, and Spring implements it to return new instances.
You can also use scoped proxies by setting proxyMode equals TARGET_CLASS in the @Scope annotation, which makes Spring inject a proxy that delegates to fresh instances. The key thing to remember is that prototype scope only works at injection time — once injected, it's just a regular object reference.
Prototype Bean in Singleton Problem
Direct Answer
When a prototype bean is injected into a singleton via constructor or field, Spring resolves it only once — at singleton creation — so the singleton reuses that single instance forever, silently defeating prototype scope. Fix it with ObjectProvider, @Lookup method injection, or a scoped proxy.
Code Example
import org.springframework.beans.factory.annotation.Lookup;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import org.springframework.stereotype.Service;
import java.util.UUID;
@Component
@Scope("prototype")
class RequestProcessor {
private final String requestId = UUID.randomUUID().toString();
public String process(String data) {
return "Request " + requestId + " processed: " + data;
}
}
@Service
abstract class OrderService {
public String handleOrder(String order) {
return createProcessor().process(order); // a fresh instance each call
}
@Lookup // Spring overrides this to return a new prototype every call
protected abstract RequestProcessor createProcessor();
}
Common Mistakes & Pitfalls
- Expecting magic prototype behavior: Learners assume marking a bean prototype makes Spring create new instances whenever it's used, even after injection. Spring only honors prototype at injection time — inject once into a singleton and you get one instance forever.
- Using ApplicationContext.getBean() everywhere: Some Learners scatter context.getBean(PrototypeBean.class) through their code, turning Spring into a service-locator anti-pattern. Use ObjectProvider — it's type-safe and built for this.
- Marking beans prototype without justification: If your bean has no mutable state, singleton is better. Prototype is only for beans that hold per-use state that can't be shared.
Check your understanding
Answer these without looking back at the article.
- What is ObjectProvider in Spring?
- How does @Lookup method injection work?
- Is it ever correct to directly @Autowire a prototype into a singleton?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.