能够做冶金工程毕业设计的网站做网站用的编程工具

引言

在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注入，它们可能掩盖设计缺陷。
• 构造器注入 + 合理分层 = 更健壮的系统！