Spring中Bean循环依赖的底层原理与三种优雅解决方案

Spring Bean 循环依赖：原理、问题与优雅解决方案

大家好，今天我们来深入探讨 Spring 中 Bean 循环依赖这一常见但又需要谨慎处理的问题。循环依赖不仅会影响应用的启动，还可能导致不可预测的行为。理解其底层原理，掌握优雅的解决方案，对于构建健壮的 Spring 应用至关重要。

什么是循环依赖？

循环依赖指的是两个或多个 Bean 之间相互依赖，形成一个闭环。例如，Bean A 依赖 Bean B，而 Bean B 又依赖 Bean A。

// Bean A
@Component
public class BeanA {

    private final BeanB beanB;

    @Autowired
    public BeanA(BeanB beanB) {
        this.beanB = beanB;
    }

    public void doSomething() {
        beanB.doSomethingElse();
    }
}

// Bean B
@Component
public class BeanB {

    private final BeanA beanA;

    @Autowired
    public BeanB(BeanA beanA) {
        this.beanA = beanA;
    }

    public void doSomethingElse() {
        beanA.doSomething();
    }
}

在上述例子中，BeanA 的构造器需要 BeanB 的实例，而 BeanB 的构造器又需要 BeanA 的实例。这就是典型的构造器循环依赖。

循环依赖的类型

根据依赖注入的方式，循环依赖可以分为以下几种类型：

• 构造器循环依赖： 如上面的例子所示，通过构造器进行依赖注入，导致循环依赖。
• Setter 循环依赖： 通过 Setter 方法进行依赖注入，导致循环依赖。
• Field 循环依赖： 通过字段进行依赖注入，导致循环依赖。

// Setter 循环依赖
@Component
public class BeanC {

    private BeanD beanD;

    @Autowired
    public void setBeanD(BeanD beanD) {
        this.beanD = beanD;
    }

    public void doSomething() {
        beanD.doSomethingElse();
    }
}

@Component
public class BeanD {

    private BeanC beanC;

    @Autowired
    public void setBeanC(BeanC beanC) {
        this.beanC = beanC;
    }

    public void doSomethingElse() {
        beanC.doSomething();
    }
}

// Field 循环依赖
@Component
public class BeanE {

    @Autowired
    private BeanF beanF;

    public void doSomething() {
        beanF.doSomethingElse();
    }
}

@Component
public class BeanF {

    @Autowired
    private BeanE beanE;

    public void doSomethingElse() {
        beanE.doSomething();
    }
}

Spring 如何处理循环依赖？

Spring 利用三级缓存机制来尝试解决循环依赖。理解三级缓存是理解 Spring 如何处理循环依赖的关键。

三级缓存：

• singletonFactories (一级缓存): 存储的是 ObjectFactory，用于延迟创建 Bean。 只有在需要解决循环依赖时才会使用。
• earlySingletonObjects (二级缓存): 存储的是已经创建但尚未完成属性注入的 Bean 的早期引用 (Early Bean Reference)。
• singletonObjects (三级缓存): 存储的是完全初始化完成的 Bean 实例。

处理流程：

1. 创建 Bean A: Spring 尝试创建 BeanA 的实例。首先，将 BeanA 的 ObjectFactory (用于创建 BeanA 的实例) 放入 singletonFactories (一级缓存)。 然后，进行实例化，但此时还没有进行属性注入。 将 BeanA 的早期引用放入 earlySingletonObjects (二级缓存)。
2. 依赖 Bean B: 在填充 BeanA 的属性时，发现它依赖于 BeanB。 Spring 尝试创建 BeanB 的实例，重复步骤 1，将 BeanB 的 ObjectFactory 放入 singletonFactories，实例化，并将 BeanB 的早期引用放入 earlySingletonObjects。
3. 循环依赖: 在填充 BeanB 的属性时，发现它依赖于 BeanA。 Spring 首先检查 singletonObjects (三级缓存) 中是否已经存在 BeanA 的实例。如果不存在，则检查 earlySingletonObjects (二级缓存) 中是否存在 BeanA 的早期引用。如果存在，则直接使用该引用。 如果二级缓存中也不存在，则从 singletonFactories (一级缓存) 中获取 BeanA 的 ObjectFactory，并调用 getObject() 方法创建 BeanA 的早期引用，然后放入 earlySingletonObjects。
4. 完成注入: BeanB 使用 BeanA 的早期引用完成属性注入。 然后，BeanB 完成初始化，并将其从 earlySingletonObjects 移动到 singletonObjects (三级缓存)。
5. 继续 Bean A: 现在，Spring 回到 BeanA 的属性注入，使用 BeanB 的完整实例完成注入。 然后，BeanA 完成初始化，并将其从 earlySingletonObjects 移动到 singletonObjects (三级缓存)。

注意：

• Spring 只能解决Setter 循环依赖和Field 循环依赖，而不能解决构造器循环依赖。 这是因为构造器循环依赖在创建 Bean 实例之前就发生了，而三级缓存机制需要在 Bean 实例创建之后才能发挥作用。
• 即使解决了循环依赖，也应该尽量避免。 循环依赖通常意味着设计上的问题，应该通过重构代码来消除。

代码模拟 (简化版):

虽然无法完全模拟 Spring 容器的内部机制，但以下代码可以帮助理解三级缓存的概念：

import java.util.HashMap;
import java.util.Map;
import java.util.function.Supplier;

public class SimpleIocContainer {

    private final Map<String, Object> singletonObjects = new HashMap<>(); // 三级缓存
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(); // 二级缓存
    private final Map<String, Supplier<?>> singletonFactories = new HashMap<>(); // 一级缓存

    public Object getBean(String beanName) {
        // 1. 从三级缓存中获取
        Object singletonObject = singletonObjects.get(beanName);
        if (singletonObject != null) {
            return singletonObject;
        }

        // 2. 从二级缓存中获取
        singletonObject = earlySingletonObjects.get(beanName);
        if (singletonObject != null) {
            return singletonObject;
        }

        // 3. 从一级缓存中获取并创建早期 Bean
        Supplier<?> objectFactory = singletonFactories.get(beanName);
        if (objectFactory != null) {
            singletonObject = objectFactory.get();
            earlySingletonObjects.put(beanName, singletonObject); // 放入二级缓存
            singletonFactories.remove(beanName); // 从一级缓存移除
            return singletonObject;
        }

        return null; // Bean 不存在
    }

    public void registerSingleton(String beanName, Supplier<?> objectFactory) {
        singletonFactories.put(beanName, objectFactory);
    }

    public void registerSingleton(String beanName, Object singletonObject) {
        singletonObjects.put(beanName, singletonObject);
    }

    public static void main(String[] args) {
        SimpleIocContainer container = new SimpleIocContainer();

        // 模拟 BeanA 的创建
        container.registerSingleton("beanA", () -> {
            BeanA beanA = new BeanA();
            // 在这里，我们先不注入 BeanB，稍后再注入
            return beanA;
        });

        // 模拟 BeanB 的创建
        container.registerSingleton("beanB", () -> {
            BeanB beanB = new BeanB();
            // 注入 BeanA 的早期引用
            beanB.setBeanA((BeanA) container.getBean("beanA"));
            return beanB;
        });

        // 获取 BeanA 的早期引用，并注入 BeanB
        BeanA beanA = (BeanA) container.getBean("beanA");
        beanA.setBeanB((BeanB) container.getBean("beanB"));

        // 将 BeanA 和 BeanB 放入三级缓存（模拟完成初始化）
        container.registerSingleton("beanA", beanA);
        container.registerSingleton("beanB", container.getBean("beanB"));

        System.out.println("BeanA: " + container.getBean("beanA"));
        System.out.println("BeanB: " + container.getBean("beanB"));
    }

    static class BeanA {
        private BeanB beanB;

        public void setBeanB(BeanB beanB) {
            this.beanB = beanB;
        }

        @Override
        public String toString() {
            return "BeanA{" +
                    "beanB=" + beanB +
                    '}';
        }
    }

    static class BeanB {
        private BeanA beanA;

        public void setBeanA(BeanA beanA) {
            this.beanA = beanA;
        }

        @Override
        public String toString() {
            return "BeanB{" +
                    "beanA=" + beanA +
                    '}';
        }
    }
}

这个例子展示了 SimpleIocContainer 如何使用 singletonFactories、earlySingletonObjects 和 singletonObjects 来模拟 Spring 解决循环依赖的过程。 请注意，这只是一个简化的示例，Spring 的实际实现要复杂得多。

如何优雅地解决循环依赖？

虽然 Spring 能够处理某些类型的循环依赖，但最佳实践是避免循环依赖。以下是一些优雅的解决方案：

1. 重构代码，消除循环依赖: 这是最根本的解决方案。 重新审视你的代码设计，找出循环依赖的原因，并通过合理的重构来消除它。 常见的重构方法包括：

   • 合并 Bean: 如果两个 Bean 之间的依赖关系过于紧密，可以考虑将它们合并成一个 Bean。
   • 提取公共接口: 将两个 Bean 的公共行为提取到接口中，然后让它们都实现这个接口。 这样，它们就可以通过接口进行通信，而不需要直接依赖彼此。
   • 引入中间类: 引入一个中间类来协调两个 Bean 之间的交互。 这样，两个 Bean 就不需要直接依赖彼此。
   • 事件驱动: 使用事件驱动架构，一个 Bean 发布事件，另一个 Bean 监听事件并做出响应。 这样，它们就可以异步地进行通信，而不需要直接依赖彼此。

2. 使用 Setter 或 Field 注入，避免构造器循环依赖: 如果无法避免循环依赖，并且你使用的是构造器注入，可以考虑改用 Setter 或 Field 注入。 Spring 能够解决 Setter 和 Field 循环依赖，但无法解决构造器循环依赖。

3. 使用 @Lazy 注解延迟加载 Bean: @Lazy 注解可以延迟 Bean 的初始化，直到第一次使用时才创建 Bean 实例。 这可以解决某些类型的循环依赖问题。

   @Component
   public class BeanG {
   
       private final BeanH beanH;
   
       @Autowired
       public BeanG(@Lazy BeanH beanH) {
           this.beanH = beanH;
       }
   
       public void doSomething() {
           beanH.doSomethingElse();
       }
   }
   
   @Component
   public class BeanH {
   
       private final BeanG beanG;
   
       @Autowired
       public BeanH(@Lazy BeanG beanG) {
           this.beanG = beanG;
       }
   
       public void doSomethingElse() {
           beanG.doSomething();
       }
   }

   在这个例子中，@Lazy 注解告诉 Spring 延迟创建 BeanH 和 BeanG 的实例，直到第一次使用它们时才创建。 这可以避免构造器循环依赖。

4. 使用 ApplicationContextAware 接口: ApplicationContextAware 接口允许 Bean 访问 Spring 容器。 你可以使用它来手动获取 Bean 实例，从而避免循环依赖。

   @Component
   public class BeanI implements ApplicationContextAware {
   
       private ApplicationContext applicationContext;
       private BeanJ beanJ;
   
       @Override
       public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
           this.applicationContext = applicationContext;
       }
   
       public void doSomething() {
           if (beanJ == null) {
               beanJ = applicationContext.getBean(BeanJ.class);
           }
           beanJ.doSomethingElse();
       }
   }
   
   @Component
   public class BeanJ {
   
       private final BeanI beanI;
   
       @Autowired
       public BeanJ(@Lazy BeanI beanI) {
           this.beanI = beanI;
       }
   
       public void doSomethingElse() {
           beanI.doSomething();
       }
   }

   在这个例子中，BeanI 实现了 ApplicationContextAware 接口，并使用 applicationContext.getBean(BeanJ.class) 方法手动获取 BeanJ 的实例。 这可以避免构造器循环依赖。

5. 使用 ObjectFactory 或 Provider 接口: ObjectFactory 和 Provider 接口可以延迟获取 Bean 实例，类似于 @Lazy 注解。

   import org.springframework.beans.factory.ObjectFactory;
   import org.springframework.stereotype.Component;
   
   @Component
   public class BeanK {
   
       private final ObjectFactory<BeanL> beanLFactory;
   
       public BeanK(ObjectFactory<BeanL> beanLFactory) {
           this.beanLFactory = beanLFactory;
       }
   
       public void doSomething() {
           BeanL beanL = beanLFactory.getObject();
           beanL.doSomethingElse();
       }
   }
   
   @Component
   public class BeanL {
   
       private final BeanK beanK;
   
       public BeanL(BeanK beanK) {
           this.beanK = beanK;
       }
   
       public void doSomethingElse() {
           beanK.doSomething();
       }
   }

   在这个例子中，BeanK 使用 ObjectFactory<BeanL> 来延迟获取 BeanL 的实例。 这可以避免构造器循环依赖。

各种解决方案的比较

解决方案	优点	缺点	适用场景
重构代码	最根本的解决方案，消除设计缺陷	需要对代码进行较大的改动	任何存在循环依赖的场景，尤其是在项目初期，应该优先考虑重构
Setter/Field 注入	简单易用，Spring 可以处理	可能会导致代码可读性降低，因为依赖关系不明确	无法避免循环依赖，且使用的是构造器注入时
@Lazy 注解	简单易用，延迟 Bean 的初始化	可能会导致性能问题，因为 Bean 的创建被延迟到第一次使用时	循环依赖不是非常严重，并且可以接受一定的性能损失时
ApplicationContextAware	可以手动获取 Bean 实例，灵活性高	代码侵入性强，需要实现 Spring 接口	需要手动控制 Bean 的创建和销毁时
ObjectFactory/Provider	可以延迟获取 Bean 实例，解耦性好	代码相对复杂，需要了解 ObjectFactory 和 Provider 的使用	需要延迟获取 Bean 实例，并且希望代码具有更好的可测试性和可维护性时

避免循环依赖的最佳实践

• 遵循单一职责原则: 每个 Bean 应该只负责一个明确的职责。 这可以减少 Bean 之间的依赖关系，从而降低循环依赖的风险。
• 使用接口隔离原则: 使用接口来定义 Bean 之间的交互。 这可以减少 Bean 之间的耦合，从而降低循环依赖的风险。
• 优先使用组合而不是继承: 组合比继承更灵活，可以减少 Bean 之间的依赖关系。
• 及早发现循环依赖: 在开发过程中，尽早发现循环依赖问题。 这可以避免在项目后期进行大规模的重构。 可以使用静态代码分析工具来检测循环依赖。
• 编写单元测试: 编写单元测试可以帮助你发现循环依赖问题。 如果你的单元测试无法运行，可能是因为存在循环依赖。

Spring处理Bean的生命周期中重要的步骤

为了更好的理解循环依赖，我们需要了解Spring Bean的生命周期。以下是Spring Bean生命周期中的关键步骤：

1. BeanDefinition 的解析和注册: Spring容器读取Bean的配置信息（如XML配置、注解等），将每个Bean定义封装成一个BeanDefinition对象，并注册到BeanDefinitionRegistry中。

2. Bean 的实例化（Instantiation）: 根据BeanDefinition的信息，使用反射或者CGLIB等方式创建Bean的实例对象。 这一步只是创建对象，还没有进行属性注入。

3. 属性填充（Populate）: 根据Bean的依赖关系，将依赖的Bean注入到当前Bean的属性中。 这一步会涉及到循环依赖的解决。

4. Aware接口的处理: 如果Bean实现了BeanNameAware、BeanClassLoaderAware、BeanFactoryAware、ApplicationContextAware等接口，Spring容器会调用相应的set方法，将Bean的名称、ClassLoader、BeanFactory、ApplicationContext等信息注入到Bean中。

5. BeanPostProcessor 的前置处理（Before Initialization）: 在Bean初始化之前，Spring容器会调用所有注册的BeanPostProcessor的postProcessBeforeInitialization方法，对Bean进行一些自定义的处理。

6. InitializingBean 接口的处理: 如果Bean实现了InitializingBean接口，Spring容器会调用afterPropertiesSet方法，允许Bean在所有属性设置完成后进行一些自定义的初始化操作。

7. 自定义的 init-method: 如果在Bean的配置中指定了init-method，Spring容器会调用该方法，进行自定义的初始化操作。

8. BeanPostProcessor 的后置处理（After Initialization）: 在Bean初始化之后，Spring容器会调用所有注册的BeanPostProcessor的postProcessAfterInitialization方法，对Bean进行一些自定义的处理。

9. Bean 的使用: Bean创建完成后，就可以被其他Bean使用了。

10. Bean 的销毁（Destruction）: 当Spring容器关闭或者Bean不再需要时，会销毁Bean。

11. DisposableBean 接口的处理: 如果Bean实现了DisposableBean接口，Spring容器会调用destroy方法，允许Bean在销毁之前进行一些自定义的清理操作。

12. 自定义的 destroy-method: 如果在Bean的配置中指定了destroy-method，Spring容器会调用该方法，进行自定义的清理操作。

关键在于设计

总而言之，循环依赖是一个需要谨慎处理的问题。 尽管 Spring 提供了三级缓存机制来解决某些类型的循环依赖，但最佳实践是避免循环依赖。 通过重构代码、使用 Setter 或 Field 注入、延迟加载 Bean 等方式，可以优雅地解决循环依赖问题。 最重要的是，要遵循良好的设计原则，减少 Bean 之间的依赖关系，从而降低循环依赖的风险。理解Spring Bean的生命周期也有助于我们更好的理解循环依赖的产生。最终，好的设计才是解决问题的关键。