引言

在Spring Boot開發中，你是否遇到過這樣的錯誤信息？
The dependencies of some of the beans in the application context form a cycle
這表示你的應用出現了循環依賴。盡管Spring框架通過巧妙的機制解決了部分循環依賴問題，但在實際開發中（尤其是使用構造器注入時），開發者仍需警惕此類問題。本文將深入探討循環依賴的根源，分析Spring的解決策略，并提供多種實戰解決方案。

---

一、什么是循環依賴？

循環依賴指兩個或多個Bean相互依賴對方，形成一個閉環。例如：

• ?Bean A? 的創建需要注入 ?Bean B?
• ?Bean B? 的創建又需要注入 ?Bean A?

此時，Spring容器在初始化Bean時會陷入“死循環”。以下是一個典型示例：

@Service
public class ServiceA {private final ServiceB serviceB;public ServiceA(ServiceB serviceB) { // 構造器注入ServiceBthis.serviceB = serviceB;}
}@Service
public class ServiceB {private final ServiceA serviceA;public ServiceB(ServiceA serviceA) { // 構造器注入ServiceAthis.serviceA = serviceA;}
}

啟動應用時，Spring會拋出異常：
BeanCurrentlyInCreationException: Error creating bean with name 'serviceA': Requested bean is currently in creation

---

二、Spring如何解決循環依賴？

Spring通過三級緩存機制解決單例Bean的循環依賴問題：

1. ?一級緩存?（singletonObjects）：存放完全初始化好的Bean。
2. ?二級緩存?（earlySingletonObjects）：存放提前曝光的半成品Bean（僅實例化，未填充屬性）。
3. ?三級緩存?（singletonFactories）：存放Bean的工廠對象，用于生成半成品Bean。

?解決流程?（以A和B相互依賴為例）：

1. 創建A時，先實例化A（未填充屬性），并將A的工廠放入三級緩存。
2. 填充A的屬性時發現需要B，開始創建B。
3. 創建B時，實例化B后，發現需要A，此時從三級緩存中通過工廠獲取A的半成品對象。
4. B完成初始化，放入一級緩存。
5. A繼續填充B的實例，完成初始化，放入一級緩存。

?關鍵限制?：該機制僅支持單例Bean且通過屬性注入的場景。?構造器注入會直接失敗！

---

三、為何構造器注入會導致循環依賴失敗？

構造器注入要求Bean在實例化階段立即獲得依賴對象，而三級緩存機制需要在屬性注入階段解決依賴。因此，當兩個Bean都使用構造器注入時，Spring無法提前曝光半成品Bean，導致循環依賴無法解決。

---

四、解決方案：打破循環依賴的四種方法

1. ?改用Setter/Field注入（謹慎使用）??

將構造器注入改為Setter或字段注入，允許Spring延遲注入依賴：

@Service
public class ServiceA {private ServiceB serviceB;@Autowired // Setter注入public void setServiceB(ServiceB serviceB) {this.serviceB = serviceB;}
}

• ?優點?：快速解決問題。
• ?缺點?：破壞了不可變性（字段非final），且可能掩蓋設計問題。

2. ?使用@Lazy延遲加載?

在依賴對象上添加@Lazy，告知Spring延遲初始化Bean：

@Service
public class ServiceA {private final ServiceB serviceB;public ServiceA(@Lazy ServiceB serviceB) {this.serviceB = serviceB; // 實際注入的是代理對象}
}

• ?原理?：Spring生成代理對象，只有在首次調用時才會真正初始化目標Bean。
• ?適用場景?：解決構造函數注入的循環依賴。

3. ?重新設計代碼結構?

通過分層或提取公共邏輯，消除循環依賴：

• ?方案一?：引入中間層（如ServiceC），將A和B的共同依賴轉移到C。
• ?方案二?：使用事件驅動（ApplicationEvent），解耦直接依賴。

// 事件驅動示例
@Service
public class ServiceA {@Autowiredprivate ApplicationEventPublisher eventPublisher;public void doSomething() {eventPublisher.publishEvent(new EventA());}
}@Service
public class ServiceB {@EventListenerpublic void handleEventA(EventA event) {// 處理事件}
}

4. ?使用ObjectProvider（推薦）??

在構造器中注入ObjectProvider，按需獲取依賴：

@Service
public class ServiceA {private final ServiceB serviceB;public ServiceA(ObjectProvider<ServiceB> serviceBProvider) {this.serviceB = serviceBProvider.getIfUnique();}
}

• ?優點?：保持構造器注入的不可變性，顯式控制依賴獲取時機。
• ?注意?：需確保依賴Bean存在且唯一。

---

五、最佳實踐與預防措施

1. ?優先使用構造器注入?：保持Bean的不可變性和明確依賴，但需警惕循環依賴。
2. ?定期檢測循環依賴?：
   • 使用IDE插件（如IntelliJ的Circular Dependencies分析）。
   • 通過Maven/Gradle插件（如spring-boot-dependencies-analysis）。
3. ?代碼分層規范?：
   • 嚴格遵循分層架構（Controller → Service → Repository）。
   • 避免同一層內的Bean相互依賴。
4. ?單元測試驗證?：編寫集成測試，驗證Bean的初始化過程。

@SpringBootTest
public class CircularDependencyTest {@Autowiredprivate ApplicationContext context;@Testvoid contextLoads() {// 若啟動無異常，則通過測試assertNotNull(context.getBean(ServiceA.class));}
}

---

六、總結

循環依賴是Spring開發中的常見陷阱，其本質是代碼設計問題。盡管Spring提供了部分解決方案，但重構代碼消除循環依賴才是根本之道。通過合理使用注入方式、代碼分層和工具檢測，開發者可以有效避免此類問題，構建高可維護性的應用。

?記住?：

• 慎用@Lazy和Setter注入，它們可能掩蓋設計缺陷。
• 構造器注入 + 合理分層 = 更健壯的系統！