Bean Scopes

🔍 What Is It?

Bean scope controls the lifecycle and number of bean instances created by the IoC container.

Available scopes:

singleton (default)

• →One instance per ApplicationContext
• →Shared across all threads and all injection points
• →Created at startup (eager) or first use (lazy)
• →Destroyed when context closes

prototype

• →New instance created every time the bean is requested
• →Spring does NOT manage its destruction (@PreDestroy not called)
• →Use for stateful objects that must not be shared

request (web apps only)

• →One instance per HTTP request
• →Created when request starts, destroyed when it ends
• →Thread-safe by design (one request = one thread = one bean)

session (web apps only)

• →One instance per HTTP session
• →Lives as long as the user's session
• →Stored in HTTP session, serializable

application (web apps only)

• →One instance per ServletContext (essentially singleton for web apps)

Custom scopes

• →Spring allows defining custom scopes (e.g., Spring Batch defines job and step scopes)

🎯 Why Do We Need It?

Different objects have different lifecycle requirements:

• →A UserService is stateless — one singleton instance handles all users safely
• →A ShoppingCart is stateful per user — needs session scope
• →A ReportGenerator accumulates state during generation — needs prototype scope
• →A RequestContext holds per-request data — needs request scope

Using the wrong scope causes bugs: a singleton with mutable state is a concurrency disaster; a new prototype for every call is wasteful if the object is stateless.

🏗️ What Happens in Real Projects?

In enterprise Spring Boot apps:

• →99% of beans are singleton — services, repositories, controllers, config beans
• →Prototype used for: batch job processors, report builders, objects with mutable state
• →Request scope used for: request ID tracking, per-request audit context, security context holders
• →Session scope used for: shopping carts, user preferences, wizard/multi-step form state

⚙️ How It Works

Singleton bean:

Spring creates one instance and returns the same reference every time it's injected or looked up. This is why all singleton beans MUST be thread-safe (stateless or using thread-safe data structures).

Prototype bean injected into singleton:

This is the classic scope mismatch problem. If a singleton bean has a prototype dependency, Spring injects the prototype ONCE at creation time. The singleton holds a reference to that one prototype instance forever — defeating the purpose of prototype scope.

Solution: ObjectProvider<T>

@Service
public class ReportService {
    private final ObjectProvider<ReportGenerator> generatorProvider;
    
    public void generateReport(ReportRequest request) {
        ReportGenerator generator = generatorProvider.getObject(); // new instance each call
        generator.generate(request);
    }
}

💻 Example

Bean Scopes in Practice — Singleton services, prototype processors, and request-scoped context.

// Singleton by default — no @Scope annotation needed
@Service
public class UserService {
    // MUST be stateless — shared across all threads
    // Never store request-specific data in instance fields
    
    private final UserRepository userRepository; // also singleton
    private final PasswordEncoder passwordEncoder; // also singleton

    public UserService(UserRepository userRepository,
                        PasswordEncoder passwordEncoder) {
        this.userRepository = userRepository;
        this.passwordEncoder = passwordEncoder;
    }

    // Thread-safe: all state is local to the method
    public UserDto getUser(Long id) {
        return userRepository.findById(id)
            .map(UserDto::from)
            .orElseThrow(() -> new UserNotFoundException(id));
    }
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits