Spring Boot循环依赖的陷阱与解决方案：如何打破“Bean创建死循环”？

引言

在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的循环依赖问题：

一级缓存（singletonObjects）：存放完全初始化好的Bean。
二级缓存（earlySingletonObjects）：存放提前曝光的半成品Bean（仅实例化，未填充属性）。
三级缓存（singletonFactories）：存放Bean的工厂对象，用于生成半成品Bean。

解决流程（以A和B相互依赖为例）：

创建A时，先实例化A（未填充属性），并将A的工厂放入三级缓存。
填充A的属性时发现需要B，开始创建B。
创建B时，实例化B后，发现需要A，此时从三级缓存中通过工厂获取A的半成品对象。
B完成初始化，放入一级缓存。
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存在且唯一。

五、最佳实践与预防措施

优先使用构造器注入：保持Bean的不可变性和明确依赖，但需警惕循环依赖。
定期检测循环依赖：
- 使用IDE插件（如IntelliJ的Circular Dependencies分析）。
- 通过Maven/Gradle插件（如spring-boot-dependencies-analysis）。
代码分层规范：
- 严格遵循分层架构（Controller → Service → Repository）。
- 避免同一层内的Bean相互依赖。
单元测试验证：编写集成测试，验证Bean的初始化过程。

@SpringBootTest
public class CircularDependencyTest {@Autowiredprivate ApplicationContext context;@Testvoid contextLoads() {// 若启动无异常，则通过测试assertNotNull(context.getBean(ServiceA.class));}
}