Spring Singleton Bean Scope
Fast recall
Quick revision
Core answer
Whether you understand the most commonly used scope and its boundaries
Saying singleton means one instance per JVM — it's actually one per ApplicationContext, so multiple contexts can have separate singleton instances
Explain why singleton beans must be stateless to be thread-safe in a multi-threaded web application
Interview-ready guide
Interview answer
OrderService is normally a singleton whose request data lives in method-local variables. A singleton metrics registry or cache deliberately holds mutable shared state and can be correct because its implementation is thread-safe. The rule is not 'no mutable fields'; it is 'do not store unsafely shared per-request state or mutate state without a concurrency design'. Two application contexts can each create their own instance.
Spring Singleton Bean Scope
Direct Answer
Singleton is Spring's default scope: one object is created and cached for one bean definition in one BeanFactory/ApplicationContext, then the same object is returned to callers. It is not one object per JVM. Stateless services are a simple safe use, but a singleton may hold shared state when that state and its collaborators are designed for concurrency and lifecycle requirements.
Code Example
import org.springframework.stereotype.Service;
import org.springframework.stereotype.Repository;
@Service // singleton by default
public class OrderService {
private final OrderRepository repository; // injected once
public OrderService(OrderRepository repository) {
this.repository = repository; // constructor runs once
System.out.println("OrderService created: " + this);
}
public void placeOrder(Long userId, String item) {
// called by multiple threads concurrently
var order = new Order(userId, item); // local variable, thread-safe
repository.save(order);
}
}
@Repository // also singleton
public class OrderRepository {
// no mutable instance state, thread-safe
public void save(Order order) {
// save to database
}
}
record Order(Long userId, String item) {}
Common Mistakes & Pitfalls
- Thinking singleton means one per JVM: Freshers often say singleton creates one instance per JVM, but it's one per ApplicationContext. With a parent-child context hierarchy or multiple Spring apps in one JVM (like integration tests), you'll have multiple singleton instances.
- Storing mutable state in instance variables: Adding a field like private String currentUser to a singleton service causes thread-safety bugs. Thread A sets it to Alice, then Thread B sets it to Bob before Thread A's request finishes — now Thread A sees Bob's data.
- Expecting singleton state to survive restarts: Singleton instances are created when the ApplicationContext starts and destroyed on shutdown. They're not persisted, so state is lost between application restarts.
Check your understanding
Answer these without looking back at the article.
- Why must singleton beans be stateless?
- Is Spring singleton the same as the Singleton design pattern?
- What happens if you store request data in a singleton bean field?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.