Bean scopes, and the prototype that stopped being one

A bean's scope decides how many instances the container makes and when. Two scopes exist in every Spring application:

• singleton (the default) — one instance per container, created at startup and shared by every bean that injects it. "Singleton" here means one per ApplicationContext, not one per JVM: two contexts hold two instances.
• prototype — a new instance every time the bean is requested, whether by getBean or by being injected into another bean. The container creates and wires it, then hands it over; it does not track it, so @PreDestroy is never called for a prototype.

A web application adds request, session and application scopes (one instance per HTTP request, per HTTP session, per ServletContext), plus websocket.

@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
class RequestCounter { private int count; int next() { return ++count; } }

@Service
class ReportService {
    private final RequestCounter counter;   // injected ONCE
    ReportService(RequestCounter counter) { this.counter = counter; }
}

The trap: a prototype inside a singleton

Injection happens when the receiving bean is built. A singleton is built once, so its constructor runs once, so it asks for the prototype once. Every later call uses that same instance — the prototype scope has no effect at all from the singleton's point of view. The model below runs both versions: one service holds the prototype directly, the other holds a provider and asks the container for a fresh instance on every call.

The real fixes all do what the provider does — defer the lookup to call time:

• Inject ObjectProvider<RequestCounter> and call getObject() where you need an instance.
• Declare an abstract or stub method annotated @Lookup; Spring overrides it to return a fresh bean on each call.
• Give the prototype a scoped proxy (@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)). The singleton receives a proxy, and the proxy fetches a new target for every method call — which also means two calls on "the same" field hit two different objects, a surprise of its own.

Request- and session-scoped beans have the same problem in reverse: a singleton is created before any request exists. That is why @RequestScope and @SessionScope default to a target-class proxy — the singleton gets a proxy that resolves the current request's instance on each call.

Singletons are shared between threads

Every request thread in a web application calls the same singleton instance. A mutable field on a singleton (private int count;, a non-thread-safe SimpleDateFormat, a "current user" field) is shared state with a race condition. Keep singletons stateless, put per-call data in local variables, and reach for a narrower scope only when the state genuinely belongs to one request or session.

Common mistakes

• Marking a bean prototype and injecting it into a singleton constructor, expecting a new instance per call — the example shows it is created once.
• Storing per-request data (the current user, a running total) in a field of a singleton , so concurrent requests overwrite each other.