Spring Bean Scopes: Singleton, Prototype, Request, Session and the Prototype-in-Singleton Trap

Versions. Spring Boot 4.1.1 and Spring Framework 7.0.9 (both poms were published to Maven Central on 20 August 2026), on Java 25 (LTS, Temurin 25.0.4.1). The singleton and prototype scenarios use a plain Spring ApplicationContext; the web-scope scenario runs a real Spring Boot web application on a random port and calls it over HTTP with two clients.

A scope is a rule about how long a bean lives, and who shares it

/** No {@code @Scope}: the default. One instance per container, created at start-up. */
public class SingletonBean {

    private final int serial = Instances.next("singleton");

    public int serial() {
        return serial;
    }

    @PreDestroy
    void destroy() {
        Trace.log("singleton @PreDestroy called");
    }
}

Going deeper

• Reference: Spring Framework – Bean Scopes
• Related on this site: Singleton design pattern in Java, which is a different idea of “singleton” (one per JVM class loader) from Spring’s (one per container), as the next section shows
• Source: Instances.java

Singleton and prototype, counted

/** A new instance every time the container is asked for one. */
@Scope("prototype")
public class PrototypeBean {

    private final int serial = Instances.next("prototype");

    public int serial() {
        return serial;
    }

    @PreDestroy
    void destroy() {
        Trace.log("prototype @PreDestroy called");
    }
}

/** Still a singleton, but not created until something asks for it. */
@Lazy
public class LazySingletonBean {

    private final int serial = Instances.next("lazy");

    public int serial() {
        return serial;
    }
}

right after refresh():
  singleton instances : 1
  @Lazy singleton     : 0
  prototype           : 0

after getBean() twice for singleton and lazy, three times for prototype:
  singleton instances : 1   same object both times: true
  @Lazy singleton     : 1   same object both times: true
  prototype           : 3   serials: 1, 2, 3

two separate contexts, each with SingletonBean:
  singleton instances : 2   same object across contexts: false

“Singleton” means one per container, not one per JVM. The last block of the transcript starts two contexts that both register SingletonBean: two instances, and same object across contexts: false. The Java pattern called singleton is enforced by the class; Spring’s singleton is a promise made by one container, and a second container in the same process, such as a test context, or a parent and a child, makes its own.

prototype instances created: 1
callbacks after close(): [singleton @PreDestroy called]

Going deeper

• Reference: Spring Framework – Bean Scopes (singleton and prototype sections)
• Source: ScopesTest.java writes every transcript in this article
• Previous articles in this series: constructor, setter and field injection and @Autowired resolution

The prototype-in-singleton trap

/** The trap: a singleton that receives a prototype through its constructor. */
public class NaiveConsumer {

    private final PrototypeBean prototype;

    public NaiveConsumer(PrototypeBean prototype) {
        this.prototype = prototype;
    }

    public int use() {
        return prototype.serial();
    }
}

how the prototype is obtained      serials seen           instances built
---------------------------------- ---------------------- ---------------
constructor injection (naive)      [1, 1, 1, 1, 1]        1

The fingerprint. A bean documented as new-per-use, and a log or a counter that shows the same serial, id or timestamp on every call. There is no exception and no warning; the symptom is state that should have been fresh being shared. It is worst when the prototype holds per-user data or a non-thread-safe helper such as a formatter or a builder, because then every thread that uses the singleton is silently sharing one instance of it.

Going deeper

• Reference: Spring Framework – Singleton Beans with Prototype-bean Dependencies
• Source: NaiveConsumer.java

Four ways to get a fresh prototype, and the one to avoid

how the prototype is obtained      serials seen           instances built
---------------------------------- ---------------------- ---------------
constructor injection (naive)      [1, 1, 1, 1, 1]        1
ObjectProvider.getObject()         [1, 2, 3, 4, 5]        5
@Lookup method                     [1, 2, 3, 4, 5]        5
scoped proxy (TARGET_CLASS)        [1, 2, 3, 4, 5]        5
ApplicationContext.getBean()       [1, 2, 3, 4, 5]        5

ProxyConsumer's injected reference is a com.ankurm.corebeans.scopes.ScopedPrototypeBean$$SpringCGLIB$$0

/** Fix 1: inject a provider and ask it every time. */
public class ProviderConsumer {

    private final ObjectProvider<PrototypeBean> provider;

    public ProviderConsumer(ObjectProvider<PrototypeBean> provider) {
        this.provider = provider;
    }

    public int use() {
        return provider.getObject().serial();
    }
}

Fix 4 is a habit to avoid, and it is in the table on purpose. Injecting the ApplicationContext and calling getBean() works — the fourth row shows five instances — but the class now depends on the container and cannot be built or tested without one, and the dependency is invisible in the constructor signature. It is the “service locator” pattern; ObjectProvider gives the same behaviour with a narrower dependency.

/** Fix 2: Spring subclasses this at runtime and overrides the abstract method to call getBean(). */
public abstract class LookupConsumer {

    @Lookup
    protected abstract PrototypeBean create();

    public int use() {
        return create().serial();
    }
}

/** Prototype scope behind a proxy: every method call on the injected reference reaches a new target. */
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class ScopedPrototypeBean {

    private final int serial = Instances.next("scopedPrototype");

    public int serial() {
        return serial;
    }
}

/** Fix 3: inject a scoped proxy; the proxy fetches a fresh target for every call. */
public class ProxyConsumer {

    private final ScopedPrototypeBean prototype;

    public ProxyConsumer(ScopedPrototypeBean prototype) {
        this.prototype = prototype;
    }

    public int use() {
        return prototype.serial();
    }

    public String injectedClass() {
        return prototype.getClass().getName();
    }
}

ProxyConsumer's injected reference is a com.ankurm.corebeans.scopes.ScopedPrototypeBean$$SpringCGLIB$$0

Going deeper

• Reference: Spring Framework – Method Injection (@Lookup)
• Source: ContextConsumer.java (the version to avoid)
• Previous article: @Autowired Explained for ObjectProvider with zero, one and two beans

A singleton is shared by every thread, so its fields are too

/**
 * A singleton that keeps per-caller data in a field. The {@code pause} hook lets a test force the
 * interleaving that production traffic produces only occasionally, so the demonstration is exact.
 */
public class UnsafeGreeter {

    private String currentUser;

    public String greet(String user, Runnable pause) {
        this.currentUser = user;
        pause.run();
        return "Hello, " + currentUser;
    }
}

/** The same singleton with the state in a parameter and a local variable: nothing shared to corrupt. */
public class SafeGreeter {

    public String greet(String user, Runnable pause) {
        String currentUser = user;
        pause.run();
        return "Hello, " + currentUser;
    }
}

UnsafeGreeter (state in a field)   : alice's call returned "Hello, bob"
SafeGreeter   (state in a local)   : alice's call returned "Hello, alice"

The fingerprint. Data from one user appearing in another user’s response, intermittently, only under load, and never in a single-threaded test. The cause is almost always an instance field on a singleton that is written by request-handling code. The remedy is to keep per-call state in locals and parameters, or in a request-scoped bean if it truly belongs to the request.

    /** Alice sets her name and pauses; Bob sets his name meanwhile; Alice then reads. Returns Alice's result. */
    private static String interleave(java.util.function.BiFunction<String, Runnable, String> greet) throws Exception {
        CountDownLatch bobHasSet = new CountDownLatch(1);
        String[] aliceResult = new String[1];
        Thread alice = Thread.ofPlatform().start(() -> aliceResult[0] = greet.apply("alice", () -> {
            try {
                bobHasSet.await(5, TimeUnit.SECONDS);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }));
        Thread bob = Thread.ofPlatform().start(() -> greet.apply("bob", bobHasSet::countDown));
        alice.join();
        bob.join();
        return aliceResult[0];
    }

Going deeper

• Source: UnsafeGreeter.java and SafeGreeter.java
• Related on this site: @Async in Spring Boot 4 for what happens when the work moves to another thread

Request, session and application scope, over real HTTP

/** {@code @RequestScope} is {@code @Scope("request")} plus a TARGET_CLASS scoped proxy. */
@Component
@RequestScope
public class RequestBean {

    private final int serial = Instances.next("request");

    public int serial() {
        return serial;
    }
}

/**
 * A singleton controller holding three differently scoped collaborators. The injected references
 * are scoped proxies, so each request reaches the instance that belongs to it.
 * Diagnostic only: delete before shipping.
 */
@RestController
public class ScopesController {

    private final RequestBean request;
    private final SessionBean session;
    private final ApplicationBean application;

    public ScopesController(RequestBean request, SessionBean session, ApplicationBean application) {
        this.request = request;
        this.session = session;
        this.application = application;
    }

    @GetMapping("/scopes")
    public String scopes() {
        return "request=" + request.serial() + " session=" + session.serial() + " application="
                + application.serial() + " injectedRequestClass=" + request.getClass().getSimpleName();
    }
}

client     response
A #1       request=1 session=1 application=1 injectedRequestClass=RequestBean$$SpringCGLIB$$0
A #2       request=2 session=1 application=1 injectedRequestClass=RequestBean$$SpringCGLIB$$0
A #3       request=3 session=1 application=1 injectedRequestClass=RequestBean$$SpringCGLIB$$0
B #1       request=4 session=2 application=1 injectedRequestClass=RequestBean$$SpringCGLIB$$0
B #2       request=5 session=2 application=1 injectedRequestClass=RequestBean$$SpringCGLIB$$0

instances constructed: request=5 session=2 application=1

The injected class is a proxy. injectedRequestClass=RequestBean$$SpringCGLIB$$0. @RequestScope is shorthand for @Scope("request") plus a class-based scoped proxy, and that proxy is the reason the singleton controller can hold a request-scoped collaborator at all: each call finds the instance that belongs to the request being handled. @SessionScope and @ApplicationScope do the same for their scopes.

Going deeper

• Reference: Spring Framework – Request, Session, Application, and WebSocket Scopes
• Source: SessionBean.java, ApplicationBean.java and WebScopesApp.java

Request scope without a proxy fails at start-up

/** A singleton that takes a request-scoped bean WITHOUT a scoped proxy: the classic start-up failure. */
public class BrokenRequestConsumer {

    /** Registered by hand in the test, with proxyMode left at its default (NO). */
    @Scope("request")
    public static class RawRequestBean {
    }

    public BrokenRequestConsumer(RawRequestBean bean) {
    }
}

top exception : org.springframework.beans.factory.UnsatisfiedDependencyException
top message   : Error creating bean with name 'brokenRequestConsumer': Unsatisfied dependency expressed through constructor parameter 0: Error creating bean with name 'brokenRequestConsumer.RawRequestBean': Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton

root cause    : java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.

The fingerprint. Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton, with the root cause No thread-bound request found. The message is unusually helpful: it names the fix. The same root message appears at run time, not only at start-up, when a request-scoped bean is used on a thread that is not handling the request — for example inside an @Async method or a task you started yourself — because the request is bound to the receiving thread.

Going deeper

• Reference: Spring Framework – Scoped Beans as Dependencies
• Source: ScopesTest.java (requestScopeWithoutProxyFailsAtStartup)

Which scope, and when

Should you even care, on a small project? If your beans are stateless singletons you can ignore prototypes and the web scopes for a long time; this article’s value then is the thread-safety section and the habit of putting a counter in a constructor when you are not sure. If you do reach for a prototype, the honest advice is to ask first whether a plain new inside a factory method would be clearer — a prototype bean buys dependency injection for its dependencies at the price of the trap above and no destroy callback. That last point is opinion, not measurement.

Going deeper

• Previous articles in this series: Constructor vs Setter vs Field injection and @Autowired Explained
• Next: Spring Bean Lifecycle in Boot 4 for what happens between construction and destruction
• Related on this site: Spring Security 7 method security and proxy traps (more consequences of injecting proxies)

Further reading

• Companion repository for this article: asmhatre/spring-boot-demo, core-beans module
• Other articles in this series: Constructor vs Setter vs Field injection, @Autowired Explained, Spring Bean Lifecycle
• Interview preparation: Top 50 Spring Boot 4 Interview Questions and Answers (2026)
• Official reference: Spring Framework – Bean Scopes
• Official reference: Spring Framework – Method Injection