Spring中循环依赖问题及解决原理

一、循环依赖是什么？

在 Spring IOC（控制反转）容器中，循环依赖指的是两个或多个 Bean 之间存在相互依赖的关系。例如，Bean A 依赖于 Bean B，而 Bean B 又依赖于 Bean A，形成了循环依赖的情况。循环依赖问题可能导致 Bean 的初始化失败或产生不正确的结果。

以下是一个循环依赖的简单示例：

public class A {
    private B b;

    public void setB(B b) {
        this.b = b;
    }
}

public class B {
    private A a;

    public void setA(A a) {
        this.a = a;
    }
}

在上述示例中，类 A 和类 B 相互依赖，形成了循环依赖关系。

二、解决循环依赖问题策略

为了解决循环依赖问题，Spring IOC 容器采用了以下策略：

1. 提前暴露半成品对象（Early-Stage Object）： 当容器检测到循环依赖时，它会在对象创建过程中提前暴露一个半成品对象给依赖的对象，而不是等待整个对象完全创建后再注入依赖。这样，依赖对象就可以使用半成品对象进行操作，避免了因循环依赖而导致的无法获取完整对象的问题。

2. 使用三级缓存解决循环依赖： Spring IOC 容器使用三级缓存来解决循环依赖问题。三级缓存分为 singletonObjects、earlySingletonObjects 和 singletonFactories 三个缓存。当创建一个 Bean 时，首先将该 Bean 的 ObjectFactory 添加到 singletonFactories 缓存中。然后，创建 Bean 的过程中，如果发现循环依赖，会提前暴露一个半成品对象，并将其添加到 earlySingletonObjects 缓存中。最后，在创建完成后，将完整的 Bean 对象放入 singletonObjects 缓存中。通过这种三级缓存的机制，确保在循环依赖时能够正确地获取到半成品对象或完整对象。

三、Spring中解决循环依赖的步骤

以上述示例为例，当 Spring IOC 容器创建这两个类的实例时，它会按照以下步骤解决循环依赖问题：

1. 容器创建 A 类的实例，并将自身的半成品对象提前添加到 singletonFactories 缓存中。此时发现 A 类依赖于 B 类，Spring 尝试从容器中获取B类对象，容器中不存在B类对象。

2. 容器创建 B 类的实例，并将自身的半成品对象提前添加到 singletonFactories 缓存中。此时发现 B 类依赖于 A 类，Spring尝试从容器中获取A类对象，此前已将 A 类的半成品对象提前暴露到 Spring 容器中，因此可以获得 A 类半成品对象。

3. 容器将 A 类的半成品对象提前暴露给 B 类，并将其添加到 earlySingletonObjects 缓存中。

4. 容器将 B 类的半成品对象提前暴露给 A 类，并将其添加到 earlySingletonObjects 缓存中。

5. A 类完成创建，将 A 类的半成品对象放入 singletonObjects 缓存中。

6. B 类完成创建，将 B 类的完整对象放入 singletonObjects 缓存中。

7. 将 A 类的完整对象注入到 B 类中。

8. 将 B 类的完整对象注入到 A 类中。

通过上述步骤，Spring IOC 容器成功解决了 A 类和 B 类之间的循环依赖问题。

需要注意的是，循环依赖问题只有在单例作用域的 Bean 之间才会出现。因为单例作用域的 Bean 在容器启动时就创建好了，并且在整个应用程序的生命周期中保持单一实例。而在prototype 原型作用域或其他非单例作用域的 Bean 之间，Spring IOC 容器不会进行循环依赖的检测和解决，因为它们的创建和销毁由应用程序代码控制。

需要指出的是，虽然 Spring IOC 容器可以解决大多数情况下的循环依赖问题，但是如果存在复杂的循环依赖链或者构造函数循环依赖的情况，容器可能无法解决。在这种情况下，建议通过重新设计类的依赖关系来避免循环依赖。

四、为什么prototype类型的 bean之间的循环依赖问题不能直接解决？

在 Spring IOC 中，原型（prototype）作用域的 Bean 不能直接解决循环依赖问题。原型作用域的 Bean 在每次被请求时都会创建一个新的实例，而不是像单例作用域那样保持单一实例。因此，在原型作用域的 Bean 之间出现循环依赖时，Spring IOC 容器无法提供解决方案。

原因如下：

1. 创建时机不同： 原型作用域的 Bean 是在每次请求时创建的，而循环依赖的解决需要在对象创建过程中进行半成品对象的暴露和提前注入。由于原型作用域的 Bean 在每次请求时都会创建新的实例，所以无法在对象创建过程中暴露半成品对象并注入依赖。

2. 容器控制能力有限： Spring IOC 容器在单例作用域的 Bean 中通过三级缓存的方式实现了循环依赖的解决，但对于原型作用域的 Bean，容器的控制能力有限。原型作用域的 Bean 是由应用程序主动请求创建的，容器无法提前探测到循环依赖并提供半成品对象。

虽然原型作用域的 Bean 不能直接解决循环依赖问题，但你可以考虑通过以下方式间接解决：

1. 使用方法注入： 在原型作用域的 Bean 中，避免使用构造函数注入或字段注入，而使用方法注入。方法注入可以在每次请求时延迟注入依赖，从而避免在对象创建过程中的循环依赖问题。

2. 使用代理或延迟初始化： 可以考虑使用代理或延迟初始化的方式创建原型作用域的 Bean。通过代理或延迟初始化，可以在运行时动态地解决循环依赖问题，而不是依赖于容器的提前控制。

需要注意的是，尽管上述方法可以间接解决原型作用域的 Bean 的循环依赖问题，但这些解决方案可能引入额外的复杂性和性能开销。因此，在设计应用程序时，最好避免原型作用域的 Bean 之间存在循环依赖，或者重新考虑应用程序的架构和依赖关系，以避免循环依赖的发生。