Why Singleton Is the Default Spring Bean Scope

Direct Answer

Singleton is a practical default because most infrastructure, repository, and service beans represent reusable collaborators rather than per-call state. The container creates one instance for each bean definition and shares it at injection points. That reduces construction and keeps one configured collaboration graph, but singleton scope alone does not make a bean stateless or thread-safe.

Code Example

@Repository
class OrderRepository {
    // stateless: no instance fields holding per-request data
    public Optional<Order> findById(Long orderId) {
        return Optional.empty();
    }
}

@Service
class OrderService {
    private final OrderRepository repository; // same instance
    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
    public Order getOrder(Long id) {
        return repository.findById(id).orElseThrow();
    }
}

@Service
class InvoiceService {
    private final OrderRepository repository; // the SAME singleton instance
    public InvoiceService(OrderRepository repository) {
        this.repository = repository;
    }
    public void generateInvoice(Long orderId) {
        var order = repository.findById(orderId);
        // both services share one OrderRepository instance
    }
}

Common Mistakes & Pitfalls

• Storing request data in singleton fields: Freshers add instance fields like private String currentUserId to a singleton service and update them during request processing. Concurrent requests overwrite each other's data. Pass request-specific data as method parameters.
• Thinking singleton means single-threaded: Singleton doesn't mean only one thread uses the bean at a time. Hundreds of threads can call methods on the same instance concurrently, so any mutable shared state causes race conditions. Singleton plus stateless equals thread-safe.
• Using prototype without reason: Some freshers mark beans prototype thinking it's safer, but prototype creates a new instance per injection (not per method call), increases memory use, and is usually wrong unless the bean holds mutable per-use state.