SpringBoot循环依赖：三级缓存机制解析与实战解决方案
1. 项目概述：当SpringBoot告诉你“Bean们陷入了循环”
如果你正在开发一个SpringBoot应用，突然在启动时看到控制台抛出这么一段红字：“The dependencies of some of the beans in the application context form a cycle”，心里多半会咯噔一下。这个错误翻译过来就是“应用上下文中一些Bean的依赖关系形成了一个循环”。说白了，就是你的Bean A依赖Bean B，Bean B又依赖Bean A，或者依赖链更长，最终形成了一个闭环，Spring的IoC容器在创建这些Bean时陷入了“先有鸡还是先有蛋”的困境，无法决定谁该先被实例化，最终只能报错罢工。
这个错误在SpringBoot项目中并不少见，尤其是随着业务逻辑变得复杂，模块拆分更细，开发者一不小心就容易设计出这种循环依赖的结构。它不仅仅是启动失败那么简单，更深层次地，它暴露了代码结构设计上的缺陷——高耦合。即使通过某些技巧绕过了启动报错，这种结构也会让代码变得难以理解、测试和维护。因此，理解循环依赖的成因、Spring的解决机制以及如何从根本上避免它，是每一位SpringBoot开发者必须掌握的技能。本文将从一个资深开发者的视角，带你彻底拆解这个报错，不仅告诉你如何“救火”解决眼前的问题，更会深入原理，分享如何从设计上“防火”，构建更健壮的应用。
2. 循环依赖的根源与Spring的“三级缓存”机制
要解决问题，首先要理解问题是如何产生的，以及Spring框架本身为此做了哪些努力。
2.1 循环依赖是如何发生的？
让我们从一个最简单的场景开始。假设我们有一个UserService，它内部需要调用OrderService的方法；同时，OrderService也需要查询用户信息，因此也注入了UserService。
@Service public class UserService { @Autowired private OrderService orderService; // UserService 依赖 OrderService // ... 其他方法 } @Service public class OrderService { @Autowired private UserService userService; // OrderService 反过来依赖 UserService // ... 其他方法 }这就是一个典型的双向循环依赖。在Spring IoC容器启动，扫描并创建Bean的过程中，它会尝试构建完整的依赖关系图。当它开始创建UserService时，发现它依赖OrderService，于是暂停UserService的创建，转而去创建OrderService。而在创建OrderService时，又发现它依赖UserService。此时，UserService正在创建中（尚未完成初始化），但又不是一个完全可用的状态。于是，容器陷入了死锁：要完成UserService需要先有OrderService，要完成OrderService又需要先有UserService。在默认配置下，Spring无法处理这种局面，于是抛出我们看到的循环依赖异常。
2.2 Spring的破局之道：三级缓存
那么，Spring是不是完全没办法处理循环依赖呢？并不是。对于最常见的单例（Singleton）作用域且通过属性注入（Field Injection）或Setter方法注入的Bean，Spring提供了一套巧妙的解决方案，其核心就是三级缓存。
这里需要先理解Spring创建一个单例Bean的粗略生命周期：
- 实例化（Instantiate）：调用构造函数，创建一个“原始对象”。此时对象属性都是默认值（null, 0等）。
- 属性填充（Populate）：通过反射，为对象注入其依赖的其他Bean。
- 初始化（Initialize）：调用
@PostConstruct方法、执行InitializingBean.afterPropertiesSet()等。 - 放入单例池：完成后的Bean被放入“单例池”（一级缓存），供后续使用。
三级缓存就是在上述过程中插入的“临时寄存处”，目的是将实例化但未初始化的“早期引用”暴露出去，打破循环。这三层缓存分别是：
- 一级缓存（
singletonObjects）：存放已经完全初始化好的Bean。这就是我们常说的“单例池”。一旦Bean在这里，就表示它随时可用。 - 二级缓存（
earlySingletonObjects）：存放“早期暴露”的Bean。这些Bean已经完成了实例化，但可能还没有完成属性填充和初始化。它的存在是为了解决通过AOP代理产生的循环依赖。 - 三级缓存（
singletonFactories）：存放Bean的ObjectFactory（对象工厂）。当Bean实例化完成后，Spring会将其包装成一个ObjectFactory放入此缓存。这个工厂能在必要时（比如检测到循环依赖）提前生成代理对象或原始对象。
解决循环依赖的关键流程（以A、B互相依赖为例）：
- 开始创建A，实例化A（一个原始对象），然后将能生成A的
ObjectFactory放入三级缓存。 - 准备为A填充属性，发现它依赖B。于是暂停A的创建，转去创建B。
- 开始创建B，实例化B，同样将B的
ObjectFactory放入三级缓存。 - 准备为B填充属性，发现它依赖A。此时，B会依次去查找：
- 一级缓存（没有A）
- 二级缓存（没有A）
- 三级缓存（找到了A的ObjectFactory！）
- 通过A的
ObjectFactory，获取到A的“早期引用”（可能是原始对象，也可能是AOP代理对象）。将这个早期引用放入二级缓存，同时从三级缓存移除A的工厂。 - B成功获得了A的早期引用，完成了属性填充和初始化，变成一个完整的Bean，放入一级缓存。
- 流程回到A的创建。此时A可以从一级缓存中拿到已经初始化好的B，完成自己的属性填充和初始化，最终也放入一级缓存。
注意：Spring默认只支持单例Bean且通过Setter或属性注入的循环依赖。如果使用构造器注入（Constructor Injection），循环依赖将无法解决，因为Bean在实例化（调用构造函数）的那一刻就需要所有依赖项就绪，此时依赖的Bean可能连“早期引用”都还没有生成，死锁必然发生。这也是为什么社区普遍推荐使用构造器注入的原因之一——它能在编译期就暴露出循环依赖的设计问题。
2.3 为什么需要三级缓存？二级不够吗？
这是一个经典的面试题。关键在于AOP代理。 如果Bean不需要被AOP代理（比如没有@Transactional,@Async等注解），那么二级缓存确实可能够用：实例化后直接把原始对象扔进二级缓存。但当Bean需要被代理时，问题来了：最终放入单例池的必须是代理对象，而不是原始对象。
三级缓存中的ObjectFactory是一个“智能工厂”。它被调用的时机（即发生循环依赖时）决定了它要生产什么：
- 如果没有循环依赖：Bean按部就班地走完生命周期，在初始化后由
BeanPostProcessor（如AbstractAutoProxyCreator）统一生成代理对象，然后放入一级缓存。 - 如果发生了循环依赖：
ObjectFactory会被提前触发。它需要判断：如果这个Bean最终需要被代理，那么我现在就生成代理对象并返回；如果不需要，就返回原始对象。这个提前生成的代理对象会被放入二级缓存。
二级缓存（earlySingletonObjects）的角色是“早期暴露对象的缓存”。它缓存的就是ObjectFactory生产出来的结果（可能是原始对象，也可能是代理对象）。如果没有三级缓存，我们无法实现这种“按需、提前”生成代理的逻辑。直接放原始对象到二级缓存，万一后面需要代理，就产生了不一致（单例池是代理对象，二级缓存是原始对象）。直接放代理对象到二级缓存，如果这个Bean根本没有循环依赖，那就过早地创建了代理，可能影响一些生命周期回调的执行顺序。
所以，三级缓存的核心价值在于将“实例化”与“代理生成”的时机解耦，并提供了一个懒加载的机制，仅在真正发生循环依赖时才提前生成代理，保证了行为的一致性和性能。
3. 实战：诊断与解决循环依赖报错
当你的应用启动失败，并抛出循环依赖异常时，不要慌张。Spring的错误信息通常非常详细，是我们排查问题的第一手资料。
3.1 解读错误信息与依赖链条
错误信息通常会打印出完整的依赖循环路径。例如：
The dependencies of some of the beans in the application context form a cycle: ┌─────┐ | userService defined in file [/.../UserService.class] ↑ ↓ | orderService defined in file [/.../OrderService.class] └─────┘这个ASCII艺术图非常直观地展示了userService和orderService之间形成了闭环。对于更复杂的循环，路径也会更长。第一步就是仔细阅读这个路径，找到参与循环的所有Bean。
3.2 常用解决方案与实操步骤
根据不同的场景和根本原因，我们可以采取不同的解决策略。
3.2.1 方案一：使用@Lazy注解（治标不治本，但快速）
@Lazy注解可以延迟依赖的加载。将它加在注入点（字段、构造参数、方法参数或@Bean方法上），告诉Spring：“先给我一个代理，等真正用到这个Bean的方法时，再去初始化它。”
应用场景：快速解决启动问题，适用于依赖并非启动就必须的场景，或者你明确知道循环依赖是设计上的特例。
@Service public class UserService { @Autowired @Lazy // 关键在这里：延迟加载OrderService private OrderService orderService; // ... }或者用在另一个Bean上：
@Service public class OrderService { @Autowired @Lazy // 延迟加载UserService private UserService userService; // ... }实操心得：通常只需要在循环依赖的其中一方的注入点上加@Lazy即可打破循环。加在哪一方？一个简单的原则是：加在理论上可以后初始化的那一方。例如，订单服务需要立即调用用户服务，但用户服务在启动时不一定需要订单服务，那么就把@Lazy加在UserService对OrderService的依赖上。@Lazy会引入一个代理，可能对调试和某些极端情况下的性能有细微影响，但对于大多数业务来说可以接受。
3.2.2 方案二：改用Setter方法或字段注入（如果当前是构造器注入）
如前所述，Spring默认无法解决构造器注入的循环依赖。如果你的循环依赖是由于构造器注入引起的，一个快速的修改方案是将其改为Setter注入或字段注入。
// 改造前（构造器注入，循环依赖报错） @Service public class UserService { private final OrderService orderService; public UserService(OrderService orderService) { // 构造器注入 this.orderService = orderService; } } // 改造后（Setter注入） @Service public class UserService { private OrderService orderService; @Autowired // 或使用 @Setter(onMethod = @__(@Autowired)) (Lombok) public void setOrderService(OrderService orderService) { this.orderService = orderService; } }注意事项：这只是一个临时绕过方案。它掩盖了设计问题，并且放弃了构造器注入带来的好处（如不可变字段、明确的依赖关系、易于测试）。强烈建议在解决启动问题后，立即着手进行方案三（重构设计）。
3.2.3 方案三：重构设计，从根本上消除循环依赖（推荐）
这是最彻底、最优雅的解决方案。循环依赖通常是职责划分不清的征兆。我们可以通过以下几种模式来解耦：
提取公共逻辑到第三个类（Service）： 如果A和B互相调用是因为它们有共同的业务逻辑，可以将这部分逻辑提取到一个新的
C（例如CommonService）中，让A和B都依赖C，而A和B之间不再直接依赖。// 重构前：A <-> B // 重构后：A -> C <- B @Service public class CommonService { public void sharedBusinessLogic() { /* ... */ } } @Service public class ServiceA { @Autowired private CommonService commonService; // 不再直接依赖ServiceB } @Service public class ServiceB { @Autowired private CommonService commonService; // 不再直接依赖ServiceA }使用事件驱动（ApplicationEvent）： 如果A的动作需要触发B的更新，而B的更新又需要通知A，这种“互相通知”容易导致循环。可以引入Spring的事件机制，让它们都去监听一个第三方事件，从而解耦。
// 定义事件 public class DataUpdatedEvent extends ApplicationEvent { /* ... */ } // A和B都监听事件，而不是互相调用 @Service public class ServiceA { @EventListener public void handleEvent(DataUpdatedEvent event) { /* ... */ } } @Service public class ServiceB { public void someMethod() { // 执行操作... applicationEventPublisher.publishEvent(new DataUpdatedEvent(this)); // 不再直接调用ServiceA } }使用回调接口或模板方法模式： 如果依赖关系是单向的但设计成了双向，可以考虑将其中一个方向改为接口回调。
// 定义回调接口 public interface OperationCallback { void doAfterOperation(); } @Service public class ServiceA implements OperationCallback { @Autowired private ServiceB serviceB; public void process() { serviceB.doSomething(this); // 将自身作为回调传入 } @Override public void doAfterOperation() { // ServiceB完成后回调这里 } } @Service public class ServiceB { public void doSomething(OperationCallback callback) { // ... 执行操作 callback.doAfterOperation(); // 回调 } }这样，
ServiceA依赖ServiceB，但ServiceB不再依赖ServiceA的具体实现，而是依赖一个抽象的接口，循环被打破。
3.2.4 方案四：调整Bean的加载顺序（@DependsOn）
@DependsOn注解可以显式指定Bean的创建顺序。虽然它不能直接解决循环依赖，但可以通过强制让某个Bean先初始化，来避免某些因顺序问题暴露的循环。
@Service @DependsOn("orderService") // 明确告诉Spring，先初始化orderService public class UserService { @Autowired private OrderService orderService; }使用场景有限：这只在循环是因为某些非直接注入的依赖（如@PostConstruct方法中的调用、实现了特定接口等）导致时才可能有效。对于直接的属性注入循环，它无能为力。
3.3 终极武器：allowCircularReferences配置与风险
Spring Boot 2.6+ 版本开始，默认禁用了循环依赖（spring.main.allow-circular-references=false）。如果你使用的是旧版本项目升级上来，或者想临时允许循环依赖，可以在application.properties中配置：
spring.main.allow-circular-references=true强烈警告：这只是一个全局的开关，它允许Spring用三级缓存机制去解决它所能解决的循环依赖（单例、非构造器注入）。它并不能解决所有循环依赖（比如构造器注入的）。更重要的是，打开这个开关意味着你向糟糕的设计妥协了。它掩盖了问题，让代码潜伏着更高的耦合风险，不利于长期维护。这个配置应该仅作为临时调试手段，或者在你完全理解风险且确有特殊原因的遗留系统中使用。在新项目中，永远不要默认打开它。
4. 深入排查：当常规方法失效时
有时候，循环依赖的链条可能很长、很隐蔽，或者涉及一些特殊的Bean（如@Configuration配置类、@Bean方法、AOP切面等）。这时需要更系统的排查方法。
4.1 利用Spring Boot Actuator的beans端点
如果你的项目引入了spring-boot-starter-actuator依赖，并暴露了beans端点，可以通过HTTP请求查看所有Bean的依赖关系图。
- 添加依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> - 配置
application.properties：management.endpoints.web.exposure.include=beans,health management.endpoint.beans.enabled=true - 启动应用（如果因为循环依赖启动失败，此方法可能不适用，需先通过
@Lazy等方式临时启动）。 - 访问
http://localhost:8080/actuator/beans。你会得到一个巨大的JSON，其中包含了每个Bean的详细信息，包括它的依赖（dependencies）。搜索报错中提到的Bean名，仔细查看它们的依赖列表，可以帮你可视化复杂的依赖网。
4.2 分析@Configuration类与@Bean方法
在配置类中通过@Bean方法手动声明Bean，也可能意外引入循环依赖。
@Configuration public class AppConfig { @Bean public ServiceA serviceA(ServiceB serviceB) { // 方法参数注入 return new ServiceA(serviceB); } @Bean public ServiceB serviceB(ServiceA serviceA) { // 循环依赖！ return new ServiceB(serviceA); } }这种情况的报错信息可能不那么直接。排查时，要仔细检查所有@Configuration类，看@Bean方法是否存在相互引用。解决方法同样是重构，或者将其中一个@Bean方法的依赖改为从ApplicationContext中@Autowired，并在方法内部通过context.getBean()获取（不推荐，应优先考虑重构设计）。
4.3 关注AOP代理与@Async,@Transactional等注解
被@Transactional,@Async,@Cacheable等注解标记的Bean会被Spring动态代理（CGLIB或JDK Proxy）。这有时会干扰循环依赖的解决，尤其是在配合@Lazy使用时。
一个常见的坑是：在同一个类内部，一个@Transactional方法调用另一个@Transactional方法，由于代理机制，内部的调用不会经过代理，导致事务不生效。虽然这不直接导致循环依赖报错，但原理相关。当循环依赖涉及代理Bean时，确保你理解三级缓存中提前暴露的是代理对象。如果遇到奇怪的问题，可以尝试在类上添加@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS)或检查CGLIB代理的生成情况。
5. 设计预防：将循环依赖扼杀在摇篮里
最好的解决方式是不让它发生。以下是一些在项目初期和开发过程中就应该遵循的最佳实践：
优先使用构造器注入：这是Spring团队官方推荐的方式。它强制你在编译期就声明所有必需的依赖，使得类是不可变的（
final字段），并且更容易进行单元测试（无需Spring容器，直接new）。更重要的是，构造器注入会让循环依赖在应用启动时立即失败，迫使你早期就发现并修复设计缺陷。使用Lombok的@RequiredArgsConstructor可以大大简化代码。@Service @RequiredArgsConstructor // 为所有final字段生成构造函数 public class UserService { private final OrderService orderService; private final AnotherService anotherService; // 没有setter，依赖通过构造器明确注入 }遵循单一职责原则（SRP）：一个类只做一件事。如果
UserService既管用户又管订单，那它自然容易和自己“循环”。清晰地划分服务边界，是避免循环依赖的基石。依赖倒置原则（DIP）：高层模块不应依赖低层模块，二者都应依赖抽象。多使用接口。
ServiceA依赖IServiceB接口，ServiceB实现IServiceB。这样即使ServiceB需要反向通信，也可以通过接口回调、事件等方式，而不是直接依赖ServiceA的具体类，降低了耦合度。进行依赖关系审查：在团队开发中，定期（如在代码评审时）审视新增的依赖注入。画一个简单的模块依赖图，可以快速发现潜在的循环苗头。一些IDE插件或静态分析工具也能帮助检测循环依赖。
分层架构清晰：严格遵循Controller -> Service -> Repository/Mapper的分层。禁止层内循环（如Service A 调用 Service B， Service B 又调用 Service A），也禁止反向依赖（如Service直接注入Controller）。让依赖关系始终保持单向流动。
循环依赖报错不是一个需要惧怕的“黑盒”错误。它更像是一个严厉的架构师，在提醒你的代码结构出现了不良的耦合。理解其背后的三级缓存机制，掌握快速定位和临时解决的方法，并最终通过重构走向更清晰的设计，是每一位SpringBoot开发者成长的必经之路。下次再遇到这个错误时，希望你能从容地把它看作一次优化代码结构的机会。