Circular Dependency

A circular dependency occurs when two or more Spring beans depend on each other, either directly or indirectly, forming a loop.

Because of this loop, Spring cannot decide which bean to create first, leading to startup failure.

---

What is Circular Dependency?

When Bean A depends on Bean B, and Bean B depends back on Bean A, a circular dependency is formed.

Example (Direct Circular Dependency)

@Service
public class A {
    @Autowired
    private B b;
}

@Service
public class B {
    @Autowired
    private A a;
}

? What happens here?

• A needs B
• B needs A
• Spring enters an infinite creation loop
• Application fails at startup

---

Indirect Circular Dependency Example

A → B → C → A

Even indirect loops cause the same problem.

---

Why Circular Dependency Is a Problem

• Spring cannot resolve bean creation order
• Causes application startup failure
• Creates tight coupling
• Makes code hard to test
• Makes refactoring risky
• Reduces maintainability
• Indicates poor design

? Circular dependency is not just a Spring issue — it is a design smell.

---

How Spring Internally Handles Circular Dependencies

Spring tries to resolve circular dependencies only in limited cases.

Spring CAN resolve circular dependency when:

• Beans are singleton
• Dependency injection is:
  • Field injection
  • Setter injection

Spring CANNOT resolve circular dependency when:

• Using constructor injection
• Beans are prototype scoped
• Proxies are involved incorrectly (@Transactional, AOP edge cases)

---

Spring’s 3-Level Cache Mechanism (Internal)

Spring uses three internal caches to break circular references:

Cache	Purpose
singletonObjects	Fully initialized beans
earlySingletonObjects	Partially created beans
singletonFactories	Bean proxy factories

➡️ This mechanism works only for singleton beans

➡️ Constructor injection bypasses this mechanism intentionally

---

Prototype Scope Limitation

@Scope("prototype")
@Service
class A {
    @Autowired B b;
}

@Scope("prototype")
@Service
class B {
    @Autowired A a;
}

❌ Always fails

✔ Spring never resolves circular dependency for prototype beans

---

Circular Dependency Flow

Problem Flow

Spring Start
   ↓
Create Bean A
   ↓
A needs B
   ↓
Create Bean B
   ↓
B needs A
   ↓
❌ Circular Dependency
   ↓
Startup Failure

---

Best Solutions to Fix Circular Dependencies

1. Constructor Injection (Best Design Fix)

Constructor injection fails fast, which is actually a good thing.

@Service
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Why this is best?

• Exposes circular dependency early
• Forces clean architecture
• Improves immutability
• Improves testability

⚠️ Constructor injection does NOT allow circular dependency — and that’s intentional.

---

2. Refactor Using a Third Service (BEST SOLUTION )

Move shared logic to a separate service.

@Service
public class CommonService {
    public void commonLogic() {}
}

@Service
public class A {
    private final CommonService commonService;

    public A(CommonService commonService) {
        this.commonService = commonService;
    }
}

@Service
public class B {
    private final CommonService commonService;

    public B(CommonService commonService) {
        this.commonService = commonService;
    }
}

Benefits

• Loose coupling
• Clean design
• Scalable architecture
• Production-ready

---

3. Use @Lazy Annotation (Workaround )

@Service
public class A {

    @Autowired
    @Lazy
    private B b;
}

@Service
public class B {

    @Autowired
    private A a;
}

How it works?

• Spring injects a proxy
• Actual bean created later
• Hides design issues

Use only when refactoring is not possible

---

4. Setter Injection (Sometimes Works )

@Service
public class A {

    private B b;

    @Autowired
    public void setB(B b) {
        this.b = b;
    }
}

@Service
public class B {

    private A a;

    @Autowired
    public void setA(A a) {
        this.a = a;
    }
}

✔ Works in some cases

❌ Not ideal for mandatory dependencies

---

5. Interface-Based Design (Recommended )

public interface NotificationService {
    void notifyUser();
}

@Service
public class EmailService implements NotificationService {
    public void notifyUser() {}
}

@Service
public class UserService {

    private final NotificationService notificationService;

    public UserService(NotificationService notificationService) {
        this.notificationService = notificationService;
    }
}

• Reduces coupling
• Improves flexibility
• Helps avoid circular dependency

---

6. Event-Driven Architecture (@EventListener)

Instead of calling services directly, use events.

@Component
public class OrderService {

    @Autowired
    private ApplicationEventPublisher publisher;

    public void placeOrder() {
        publisher.publishEvent(new OrderCreatedEvent(this));
    }
}

@Component
public class NotificationListener {

    @EventListener
    public void handleOrder(OrderCreatedEvent event) {
        System.out.println("Order created notification sent");
    }
}

• Highly decoupled
• Scalable
• Best for microservices

---

7. Allow Circular References (NOT Recommended)

Spring Boot 2.6+ disables this by default.

spring.main.allow-circular-references=true

• Hides architectural problems
• Bad for long-term systems
• Only for legacy or temporary fixes

---

Circular Dependency + AOP (Hidden Pitfall)

When using:

• @Transactional
• @Async
• @Cacheable

Early bean references may bypass proxies, causing runtime issues.

? Another reason constructor injection is safest.

---

Testing Impact

Circular dependency:

• Makes unit testing difficult
• Requires complex mocking
• Creates brittle tests

Constructor injection improves testability:

new OrderService(mockPaymentService);

---

Lombok Tip (Real-World Usage)

@RequiredArgsConstructor
@Service
public class OrderService {
    private final PaymentService paymentService;
}

• Enforces constructor injection
• Prevents circular dependency
• Clean & modern style

---

Spring Boot Important Notes

• Circular dependency allowed only with:
  • Field injection
  • Setter injection
• Constructor injection never allows circular dependency
• Prototype scope never supports circular dependency
• Spring Boot 2.6+ disables circular references by default

---

Summary Table

Solution	Recommendation Level	Notes
Refactor with third service	Strongly Recommended	Clean, scalable, and best long-term solution
Constructor injection	Highly Recommended	Enforces clean design and fails fast
Events (@EventListener)	Highly Recommended	Loosely coupled and ideal for large systems
Interface-based design	Recommended	Improves flexibility and reduces coupling
@Lazy	Conditionally Acceptable	Temporary workaround; may hide design issues
Setter injection	Limited Use	Works in specific cases; not ideal for mandatory dependencies
Allow circular references	Not Recommended	Hides architectural problems; avoid in production

---

Conclusion

• Circular dependency = design smell
• Prefer constructor injection
• Refactor instead of workarounds
• Use events or shared services
• Avoid allow-circular-references in real projects