Spring框架中循环依赖问题的解决方案与设计建议：从“死亡拥抱”到优雅解耦
在多年的Spring项目开发中，我遇到过一个令人印象深刻的线上问题：服务在凌晨启动时，控制台疯狂打印Bean创建日志，最终抛出那个经典的“BeanCurrentlyInCreationException”异常，然后应用启动失败。团队排查了半小时，最终定位到罪魁祸首——两个Service之间隐蔽的循环依赖。这种场景，我戏称为Bean之间的“死亡拥抱”。今天，我就结合自己的实战和踩坑经验，来系统聊聊Spring中的循环依赖问题，它的原理、Spring的“缓兵之计”以及更根本的设计规避方案。
一、循环依赖：到底是什么在“循环”？
简单来说，循环依赖就是两个或以上的Bean，彼此持有对方的引用，构成一个闭环。比如，AService 依赖 BService，而 BService 反过来又依赖 AService。在Spring IoC容器初始化Bean的过程中，这会形成一个“先有鸡还是先有蛋”的死结。
Spring默认支持单例（Singleton）作用域下的Setter方法注入和字段注入的循环依赖，但对于构造器注入（Constructor Injection）的循环依赖是无解的。理解这一点至关重要，也是我们设计时的第一个决策点。
二、Spring的解决方案：三级缓存与提前曝光
Spring解决单例Bean循环依赖的核心，在于其精妙的“三级缓存”机制。这可以看作是一种“缓兵之计”，它打破了Bean“必须完全初始化完成才能被引用”的严格顺序。我们来模拟一下这个流程：
// 假设有循环依赖 A -> B -> A
@Component
public class A {
@Autowired
private B b;
}
@Component
public class B {
@Autowired
private A a;
}
Spring容器的解决步骤大致如下：
- 开始创建A，实例化（调用构造器）后，将其早期引用（一个ObjectFactory）放入三级缓存（`singletonFactories`）。
- 为A进行属性填充（populate），此时发现需要B，于是去获取B。
- 开始创建B，实例化后，同样将其早期引用放入三级缓存。
- 为B进行属性填充，发现需要A。此时关键点来了：容器不会从头开始创建A，而是依次从一级（`singletonObjects`，成品Bean）、二级（`earlySingletonObjects`，早期成品）、三级缓存中查找。
- 在三级缓存中找到了A的ObjectFactory，并通过它获取到A的早期引用（虽然A的属性B还未填充，但对象已存在）。将这个早期引用放入二级缓存，并从三级缓存移除。
- B成功注入A的早期引用，完成属性填充和初始化，成为一个完整Bean，放入一级缓存。
- 此时流程回到步骤2，A终于可以获取到完整的B进行注入，随后A也完成初始化，放入一级缓存。
踩坑提示：如果Bean有AOP代理，这个过程会更复杂一些。代理对象的创建也是通过三级缓存中的ObjectFactory来完成的，确保注入的是代理对象而非原始对象。这也是为什么在某些复杂的AOP场景下，循环依赖可能引发诡异问题的原因。
三、构造器注入：为何被“判了死刑”？
上面提到，构造器注入的循环依赖Spring无法解决。原因很直观：Bean的实例化（调用构造器）是第一步，如果构造器参数需要另一个Bean，而另一个Bean的构造器又需要这个Bean，那么连第一步“创建对象”都无法完成，根本没有机会使用三级缓存来提前曝光引用。
// 以下代码会导致 BeanCurrentlyInCreationException
@Component
public class ServiceA {
private final ServiceB b;
public ServiceA(ServiceB b) { // 构造器依赖
this.b = b;
}
}
@Component
public class ServiceB {
private final ServiceA a;
public ServiceB(ServiceA a) { // 构造器依赖
this.a = a;
}
}
启动应用，你会立刻得到异常。Spring官方实际上更推荐使用构造器注入，因为它能明确依赖关系，保证Bean在构造完成后就处于完全初始化的状态（不可变对象）。这迫使开发者必须从设计上避免循环依赖，这是一种“将问题暴露在编译期/启动期”的积极做法。
四、实战建议：如何从根本上避免与解决循环依赖
依赖Spring的三级缓存只是治标。一个良好的系统设计，应该致力于从根源上消除循环依赖。以下是我总结的几种实战策略：
1. 代码重构：应用设计模式解耦
策略一：提取公共逻辑到第三个类
这是最常用和直接的方法。如果A和B因为某些共同业务逻辑而相互调用，尝试将这部分逻辑抽离到一个新的ServiceC中，让A和B都依赖C。
// 重构前
@Service
public class UserService {
@Autowired
private OrderService orderService;
public void doSomething() {
// ... 一些业务
orderService.updateUserStats(this);
}
}
@Service
public class OrderService {
@Autowired
private UserService userService;
public void updateUserStats(UserService userService) {
// ... 需要用户信息
}
}
// 重构后：引入 UserStatisticsService
@Service
public class UserStatisticsService {
public void updateStats(Long userId) { /* ... */ }
}
@Service
public class UserService {
@Autowired
private UserStatisticsService statService;
// 不再直接依赖 OrderService
}
@Service
public class OrderService {
@Autowired
private UserStatisticsService statService;
// 不再直接依赖 UserService
}
策略二：使用事件驱动（ApplicationEvent）
如果Bean间的调用不是即时的、强结果依赖的，可以考虑使用Spring的事件发布/监听机制进行解耦。A完成某动作后，发布一个事件，由B来监听并处理。
// 用户注册后，需要初始化订单模块的一些数据，原来直接调用，现在改为事件
@Service
public class UserService {
@Autowired
private ApplicationEventPublisher publisher;
public void register(User user) {
// ... 保存用户等逻辑
publisher.publishEvent(new UserRegisteredEvent(this, user.getId()));
}
}
// 事件对象
public class UserRegisteredEvent {
private final Long userId;
// ... constructor, getter
}
@Component
public class OrderServiceInitListener {
@EventListener
public void handleUserRegistered(UserRegisteredEvent event) {
// 根据 userId 初始化订单相关数据
Long userId = event.getUserId();
// ... 初始化逻辑
}
}
策略三：将依赖关系改为单向，并使用接口或回调
仔细审视业务，依赖关系是否真的必须是双向的？很多时候可以通过接口将单向调用“反向”通知。例如，B需要A的某个状态，可以改为A在状态变化时，通过一个由B实现的接口来回调B。
2. 配置与注解的权衡
使用 @Lazy 注解
这是一个快速但应谨慎使用的“创可贴”方案。在其中一个注入点加上`@Lazy`，告诉Spring延迟初始化这个依赖。它实际上创建了一个代理对象，在第一次真正使用时才去获取目标Bean，从而打破了初始化时的死循环。
@Component
public class A {
private final B b;
public A(@Lazy B b) { // 在构造器参数上使用 @Lazy
this.b = b;
}
}
// 这样即使B也依赖A，A也能先被创建出来。
注意：滥用`@Lazy`会掩盖设计问题，并可能将启动期异常推迟到运行时，增加调试难度。它适用于确有必要且影响可控的场景（如某些第三方库Bean的相互依赖）。
3. 架构层面的思考
对于大型项目，循环依赖常常是模块边界模糊的征兆。考虑使用模块化（Java 9+ Modules）或更清晰的微服务/子域划分。在架构设计初期，使用依赖关系图工具（如Spring Boot的`spring-boot-dependencies-graph`或IDEA插件）来可视化Bean的依赖，定期审查，防患于未然。
五、总结：拥抱更清晰的设计
Spring的三级缓存机制是其容器成熟度的体现，它为我们处理某些历史遗留或不可避免的依赖场景提供了缓冲。然而，作为一名追求代码质量的开发者，我们应当将其视为最后的保障，而非设计的依靠。
我的个人实践是：优先使用构造器注入，让循环依赖在启动时立刻暴露；在代码评审中，将循环依赖视为一个需要重点说明的“例外情况”；对于新项目，在架构上明确模块的依赖方向。记住，解决循环依赖的过程，往往正是你重新审视领域模型、优化代码结构、提升系统内聚性的宝贵机会。从“死亡拥抱”中解脱出来，你的Spring应用会变得更加健壮和优雅。
评论(0)