@Scope for bean scope in Spring Boot - Performance & Optimization

Performance: @Scope for bean scope

MEDIUM IMPACT

This affects application startup time and memory usage by controlling bean lifecycle and instantiation frequency.

Managing bean lifecycle to optimize resource usage

Spring Boot

@Component
@Scope("prototype")
public class MyService {
  // new instance created on each injection
}

Prototype scope creates fresh instances only when needed, reducing shared state and memory pressure.

📈 Performance GainReduces memory footprint and avoids stale state, improving runtime stability.

Managing bean lifecycle to optimize resource usage

Spring Boot

@Component
public class MyService {
  // default singleton scope
}

// Injected everywhere, always created once and shared

Using singleton scope for beans that hold state or are expensive to create can cause memory bloat or stale data.

📉 Performance CostIncreases memory usage and can cause thread-safety issues, impacting responsiveness.

Performance Comparison

Pattern	Bean Instantiation	Memory Usage	Thread Safety	Verdict
Singleton scope for stateful beans	1 instance at startup	High if stateful	Low, shared instance	[X] Bad
Prototype scope for stateful beans	New instance per injection	Moderate	High, isolated instances	[OK] Good
Request scope for web beans	New instance per HTTP request	Moderate	High, per request isolation	[OK] Good
Lazy singleton for heavy beans	Instance created on first use	Low at startup	High	[OK] Good

Rendering Pipeline

Bean scopes influence when and how many bean instances are created and managed by Spring's container, affecting memory and CPU usage during app lifecycle.

→Application Startup

→Runtime Memory Management

→Request Handling

⚠️ BottleneckExcessive singleton beans with heavy initialization or improper scope causing memory bloat and thread contention.

Optimization Tips

1Use prototype or request scope for beans with user-specific or stateful data.

2Apply @Lazy to heavy singleton beans to improve startup time.

3Avoid singleton scope for beans that require thread safety or hold request data.

Performance Quiz - 3 Questions

Which @Scope is best to avoid shared state issues in beans handling user-specific data?

A application

B singleton

C prototype

D session

DevTools: Spring Boot Actuator and JVM Monitoring Tools

How to check: Use Actuator endpoints to monitor bean creation counts and JVM tools (like VisualVM) to observe memory usage and thread activity during app runtime.

What to look for: Look for excessive singleton bean memory retention and thread contention patterns indicating scope misuse.

Practice

1. What does the @Scope("prototype") annotation do in a Spring Boot bean?

easy

A. Creates a new bean instance per HTTP request

B. Creates only one shared instance of the bean for the entire application

C. Creates a new bean instance per HTTP session

D. Creates a new instance of the bean every time it is requested

Solution

1. Step 1: Understand the prototype scope meaning

   The prototype scope means Spring creates a new bean instance each time it is requested from the container.

2. Step 2: Compare with other scopes

   Unlike singleton which shares one instance, prototype always returns a fresh object.

3. Final Answer:

   Creates a new instance of the bean every time it is requested -> Option D

4. Quick Check:

   @Scope("prototype") = new instance each request [OK]

Hint: Prototype means new bean each request, singleton means shared [OK]

Common Mistakes:

• Confusing prototype with singleton scope
• Thinking prototype beans are shared
• Mixing prototype with web scopes like session or request

2. Which of the following is the correct way to declare a singleton scoped bean using @Scope annotation in Spring Boot?

easy

A. @Scope("session")

B. @Scope("prototype")

C. @Scope("singleton")

D. @Scope("request")

Solution

1. Step 1: Recall default and explicit singleton scope

   Singleton is the default scope in Spring, but explicitly it is declared as @Scope("singleton").

2. Step 2: Verify other scopes

   prototype creates new instances, session and request are web scopes, not singleton.

3. Final Answer:

   @Scope("singleton") -> Option C

4. Quick Check:

   Singleton scope = @Scope("singleton") [OK]

Hint: Singleton scope is default but use @Scope("singleton") explicitly [OK]

Common Mistakes:

• Using @Scope("prototype") for singleton beans
• Confusing web scopes with singleton
• Omitting @Scope and expecting prototype behavior

3. Consider this Spring Boot bean declaration:

@Component
@Scope("request")
public class UserRequestBean { }

What happens when this bean is injected into two different HTTP requests?

medium

A. Each request gets a new bean instance

B. Both requests share the same bean instance

C. Only the first request gets a bean, others get null

D. Bean is created once per session, shared across requests

Solution

1. Step 1: Understand request scope behavior

   The request scope means Spring creates a new bean instance for each HTTP request.

2. Step 2: Apply to two different requests

   Since the requests are different, each gets its own separate bean instance.

3. Final Answer:

   Each request gets a new bean instance -> Option A

4. Quick Check:

   @Scope("request") = new bean per HTTP request [OK]

Hint: Request scope means new bean per HTTP request [OK]

Common Mistakes:

• Assuming request scope shares bean across requests
• Confusing request scope with session scope
• Thinking request scope behaves like singleton

4. Given this bean declaration:

@Component
@Scope("session")
public class ShoppingCart { }

What is the likely error if you try to inject this bean into a singleton scoped bean without special handling?

medium

A. No error, injection works normally

B. Runtime error due to incompatible scopes

C. Compilation error due to missing @Scope annotation

D. Bean is created once and shared across all sessions

Solution

1. Step 1: Understand scope mismatch problem

   Injecting a session-scoped bean into a singleton bean causes a scope mismatch because singleton lives longer than session beans.

2. Step 2: Result of mismatch without proxy

   Without proxy or special configuration, Spring throws a runtime error as it cannot inject a shorter-lived bean into a longer-lived one safely.

3. Final Answer:

   Runtime error due to incompatible scopes -> Option B

4. Quick Check:

   Session bean into singleton without proxy = runtime error [OK]

Hint: Injecting shorter scope bean into singleton causes runtime error [OK]

Common Mistakes:

• Assuming injection always works regardless of scope
• Ignoring need for proxyMode in such injections
• Confusing compilation and runtime errors

5. You want a Spring Boot bean to create a new instance for each HTTP session but share the same instance within that session. Which @Scope annotation and configuration should you use?

hard

A. @Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS)

B. @Scope("prototype")

C. @Scope("singleton")

D. @Scope(value = "request", proxyMode = ScopedProxyMode.INTERFACES)

Solution

1. Step 1: Identify session scope for per-session bean

   The session scope creates one bean instance per HTTP session, which fits the requirement.

2. Step 2: Use proxyMode for injection into singleton beans

   Adding proxyMode = ScopedProxyMode.TARGET_CLASS allows safe injection into other beans by creating a proxy that resolves the correct session instance.

3. Final Answer:

   @Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS) -> Option A

4. Quick Check:

   Session scope + proxyMode = new instance per session shared inside session [OK]

Hint: Use session scope with proxyMode for per-session shared bean [OK]

Common Mistakes:

• Using prototype scope which creates new instance every injection
• Using singleton scope which shares one instance globally
• Using request scope which creates new instance per HTTP request