Spring 循环依赖深度解析：原理、解决方案与实践

Spring 循环依赖深度解析：原理、解决方案与实践

在 Spring 框架的日常使用中，循环依赖是一个既常见又容易让人困惑的问题。当两个或多个 Bean 之间相互依赖形成闭环时，若处理不当会导致容器初始化失败。本文将从循环依赖的基本概念出发，深入剖析 Spring 容器解决循环依赖的核心机制，揭示三级缓存的设计奥秘，并探讨特殊场景下的处理策略。

一、循环依赖的本质与表现形式

循环依赖指的是两个或多个 Bean 之间存在相互引用的关系，形成一个依赖闭环。在 Spring 容器中，这种依赖关系如果不能被正确处理，会导致 Bean 初始化过程陷入死循环或抛出BeanCurrentlyInCreationException异常。

常见的循环依赖场景

1. 构造器循环依赖

两个 Bean 通过构造方法相互依赖，例如：

@Servicepublic class AService {    private BService bService;        @Autowired    public AService(BService bService) {        this.bService = bService;    }}@Servicepublic class BService {    private AService aService;        @Autowired    public BService(AService aService) {        this.aService = aService;    }}

1. 字段循环依赖

通过字段注入形成的循环依赖，这是开发中最常见的形式：

@Servicepublic class CService {    @Autowired    private DService dService;}@Servicepublic class DService {    @Autowired    private CService cService;}

1. setter 方法循环依赖

通过 setter 方法注入形成的循环依赖：

@Servicepublic class EService {    private FService fService;        @Autowired    public void setFService(FService fService) {        this.fService = fService;    }}@Servicepublic class FService {    private EService eService;        @Autowired    public void setEService(EService eService) {        this.eService = eService;    }}

在这些场景中，Spring 对字段注入和 setter 注入的循环依赖能提供自动解决方案，而构造器注入的循环依赖则需要手动处理，这与 Spring 的 Bean 初始化流程密切相关。

二、Spring Bean 的初始化流程与循环依赖的产生

要理解循环依赖的解决方案，首先需要明确 Spring Bean 的完整初始化流程。简化来说，一个 Bean 的创建过程主要包括：

1. 实例化（Instantiation）：通过反射创建 Bean 的原始对象（尚未设置属性）
2. 属性注入（Populate）：为 Bean 的字段或 setter 方法注入依赖
3. 初始化（Initialization）：执行@PostConstruct注解方法、InitializingBean接口方法及自定义初始化方法
4. 注册 DisposableBean：为生命周期管理准备销毁逻辑

当 Bean A 在属性注入阶段需要依赖 Bean B，而 Bean B 的属性注入又依赖 Bean A 时，若没有特殊处理，就会出现 "Bean A 等待 Bean B 创建完成，Bean B 等待 Bean A 创建完成" 的死锁状态，这就是循环依赖问题的本质。

三、Spring 解决循环依赖的核心机制：三级缓存

Spring 通过三级缓存（Three-Level Cache）机制巧妙地解决了非构造器注入的循环依赖问题。这三级缓存分别是：

1. 一级缓存（singletonObjects）

• 定义：private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
• 作用：存储完全初始化完成的单例 Bean，这些 Bean 可以直接被应用程序使用

2. 二级缓存（earlySingletonObjects）

• 定义：private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
• 作用：存储提前暴露的单例 Bean 实例（原始对象经过 AOP 代理后的对象），此时 Bean 尚未完成属性注入和初始化

3. 三级缓存（singletonFactories）

• 定义：private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
• 作用：存储 Bean 的工厂对象，用于在需要时创建 Bean 的早期引用（可能是原始对象或代理对象）

三级缓存的协作流程

以字段循环依赖（CService 依赖 DService，DService 依赖 CService）为例，三级缓存的工作流程如下：

1. 创建 CService：
   • 实例化 CService 得到原始对象
   • 将 CService 的工厂对象存入三级缓存（singletonFactories）
   • 开始为 CService 注入依赖，发现需要 DService
2. 创建 DService：
   • 实例化 DService 得到原始对象
   • 将 DService 的工厂对象存入三级缓存（singletonFactories）
   • 开始为 DService 注入依赖，发现需要 CService
3. 解决 DService 对 CService 的依赖：
   • 从一级缓存查询 CService，未命中
   • 从二级缓存查询 CService，未命中
   • 从三级缓存查询到 CService 的工厂对象，通过工厂创建 CService 的早期引用（若有 AOP 增强则生成代理对象）
   • 将 CService 的早期引用存入二级缓存，同时从三级缓存移除
   • 将 CService 的早期引用注入 DService
   • DService 完成属性注入和初始化，存入一级缓存
4. 完成 CService 的初始化：
   • DService 已创建完成，将其注入 CService
   • CService 完成属性注入和初始化，存入一级缓存
   • 从二级缓存移除 CService 的早期引用

通过这种缓存升级机制，Spring 在不破坏 Bean 初始化流程的前提下，实现了循环依赖的解耦。三级缓存的设计精髓在于：通过工厂对象延迟生成代理对象，避免了提前创建代理可能导致的状态不一致问题。

四、为什么需要三级缓存？二级缓存不够吗？

很多开发者会疑惑：既然二级缓存已经能存储早期引用，为什么还需要三级缓存？这个问题的核心与 Spring 的 AOP 机制密切相关。

当 Bean 需要被 AOP 增强时，Spring 会为其创建代理对象。如果在循环依赖场景中直接使用二级缓存存储原始对象，那么注入的将是未被增强的原始对象，这与最终存入一级缓存的代理对象不一致，会导致业务逻辑错误。

三级缓存中的ObjectFactory提供了一个延迟生成代理对象的机会：当发生循环依赖时，通过工厂的getObject()方法判断是否需要创建代理对象，确保注入的是正确的代理实例；若没有循环依赖，则在 Bean 初始化完成后再创建代理对象。这种设计既解决了循环依赖问题，又保证了 AOP 增强的正确性。

五、Spring 无法解决的循环依赖场景

尽管三级缓存机制非常强大，但 Spring 并非能解决所有循环依赖场景，以下情况需要特别注意：

1. 构造器注入的循环依赖

构造器注入的循环依赖会导致 Spring 容器启动失败，因为构造器注入发生在 Bean 实例化阶段，此时 Bean 尚未被放入三级缓存，无法提前暴露引用。

解决方案：

• 将构造器注入改为字段注入或 setter 注入
• 使用@Lazy注解延迟依赖对象的初始化：

@Servicepublic class AService {    private BService bService;        @Autowired    public AService(@Lazy BService bService) {        this.bService = bService;    }}

2. 原型 Bean 的循环依赖

原型（Prototype）Bean 每次获取都会创建新实例，Spring 不会对其进行缓存管理，因此无法解决循环依赖，会直接抛出BeanCurrentlyInCreationException。

解决方案：

• 尽量避免原型 Bean 之间的循环依赖
• 将原型 Bean 改为单例 Bean，或通过Provider接口延迟获取：

@Service@Scope("prototype")public class GService {    @Autowired    private Provider<HService> hServiceProvider;        public void doSomething() {        HService hService = hServiceProvider.get();        // 使用hService    }}

3. 手动调用getBean()导致的循环依赖

在 Bean 的初始化方法（如@PostConstruct）中手动调用getBean()获取依赖 Bean，可能会绕过三级缓存机制，导致循环依赖问题。

解决方案：

• 避免在初始化方法中获取循环依赖的 Bean
• 通过ApplicationContextAware接口在需要时再获取依赖

六、循环依赖的检测与调试

当怀疑应用存在循环依赖问题时，可以通过以下方式进行检测和调试：

1. 启用 Spring 调试日志：

在application.properties中添加配置，查看 Bean 的创建过程：

logging.level.org.springframework.beans.factory=DEBUG

1. 使用 Spring 的循环依赖检测工具：

Spring 提供了AbstractApplicationContext的getBeansInCreation()方法，可在调试时查看正在创建的 Bean。

1. 分析异常栈信息：

当循环依赖导致异常时，栈信息中会包含BeanCurrentlyInCreationException，并提示正在创建的 Bean 名称，据此可定位循环依赖链。

七、最佳实践：如何避免循环依赖

虽然 Spring 能解决大部分循环依赖问题，但在设计层面避免循环依赖仍是更优选择，以下是一些实践建议：

1. 遵循单一职责原则：拆分职责过重的 Bean，减少依赖关系
2. 引入中间层：通过一个中间服务协调两个相互依赖的 Bean
3. 使用事件驱动模型：通过 Spring 的事件机制（ApplicationEvent）替代直接依赖
4. 依赖抽象而非具体：通过接口定义依赖，降低耦合度
5. 定期代码审查：及时发现并重构循环依赖关系

总结

Spring 的三级缓存机制是解决循环依赖问题的精妙设计，它通过singletonObjects、earlySingletonObjects和singletonFactories的协作，在保证 Bean 初始化完整性的同时，巧妙地打破了依赖闭环。理解这一机制不仅能帮助我们解决实际开发中的问题，更能深入体会 Spring 框架的设计哲学。

需要注意的是，Spring 并非银弹，对于构造器注入、原型 Bean 等场景的循环依赖仍需手动处理。在实际开发中，我们应尽量从设计层面避免循环依赖，辅以 Spring 提供的解决方案，才能构建出健壮、可维护的应用系统。