Spring 循环依赖

序言

什么是循环依赖？
Spring 循环依赖指的是在 Spring 容器中存在两个或多个 Bean 之间的相互依赖，导致它们之间形成了一个循环依赖关系的情况。这种循环依赖关系通常是因为 Bean A 依赖于 Bean B，而 Bean B 又依赖于 Bean A，从而形成了一个环形依赖。

一、Bean的生命周期

Spring Bean 的生命周期

具体看这篇文章–>Spring IOC AOP

Bean 的生成步骤

被 Spring 管理的对象叫做 Bean 。Bean的生成步骤如下：
1、Spring 扫描 class 得到 BeanDefinition；
2、根据得到的 BeanDefinition 去生成 bean对象；
3、首先根据 BeanClass 获取类构造方法；
4、根据获取出来的构造方法，反射，得到一个对象（暂时叫做原始对象）；
5、填充原始对象中的属性（依赖注入）；
6、如果原始对象中的某个方法被 AOP 了，那么则需要根据原始对象生成一个代理对象；
7、把最终生成的代理对象放入单例池中，下次 getBean 时就直接从单例池拿即可；

对于 Spring 中的 Bean 的生成过程，步骤还是很多的，并且不仅仅只有上面的7步，还有很多很多，这里不详细说了。

我们可以发现，在得到一个原始对象后，Spring 需要给对象中的属性进行依赖注入，那么这个注入过程是怎样的？

比如上文说的 A 类，A 类中存在一个 B 类的 b 属性，所以，当 A 类生成了一个原始对象之后，就会去给 b 属性去赋值，此时就会根据 b 属性的类型和属性名去 BeanFactory 中去获取 B 类所对应的单例bean。

1. 如果此时 BeanFactory 中存在 B 对应的 Bean，那么直接拿来赋值给 b 属性；
2. 如果此时 BeanFactory 中不存在 B 对应的 Bean，则需要生成一个 B 对应的 Bean，然后赋值给 b属性。

问题就出现在「第二种」情况，如果此时 B 类在 BeanFactory 中还没有生成对应的 Bean，那么就需要去生成，就会经过 B 的 Bean 的生命周期。

那么在创建 B 类的 Bean 的过程中，如果 B 类中存在一个 A 类的 a 属性，那么在创建 B 的 Bean 的过程中就需要 A 类对应的 Bean，但是，触发 B 类 Bean 的创建的条件是 A 类 Bean 在创建过程中的依赖注入，所以这里就出现了循环依赖：

A Bean创建–>依赖了 B 属性–>触发 B Bean创建—>B 依赖了 A 属性—>需要 A Bean（但A Bean还在创建过程中）

从而导致 A Bean 创建不出来，B Bean 也创建不出来。

这是循环依赖的场景，但是上文说了，在 Spring 中，通过某些机制帮开发者解决了部分循环依赖的问题，这个机制就是「三级缓存」

二、三级缓存

一级缓存为：singletonObjects；
二级缓存为：earlySingletonObjects；
三级缓存为：singletonFactories；

/** Cache of singleton objects: bean name –> bean instance */
private final Map singletonObjects = new ConcurrentHashMap(256);

/** Cache of singleton factories: bean name –> ObjectFactory */
private final Map> singletonFactories = new HashMap>(16);

/** Cache of early singleton objects: bean name –> bean instance */
private final Map earlySingletonObjects = new HashMap(16);

三个缓存分别有什么作用
「singletonObjects」中缓存的是已经经历了完整生命周期的bean对象。

「earlySingletonObjects」比 singletonObjects 多了一个 early ，表示缓存的是早期的 bean对象。早期指的是 Bean 的生命周期还没走完就把这个 Bean 放入了earlySingletonObjects。

「singletonFactories」中缓存的是 ObjectFactory，表示对象工厂，用来创建某个对象的。

三、解决办法

产生循环依赖的原因

解决这个循环，就需要引入三级缓存的概念

A 的 Bean 在创建过程中，在进行依赖注入之前，先把 A 的原始 Bean 放入缓存（提早暴露，只要放到缓存了，其他 Bean 需要时就可以从缓存中拿了），放入缓存后，再进行依赖注入，此时 A 的Bean 依赖了 B 的 Bean 。

如果 B 的 Bean 不存在，则需要创建 B 的 Bean，而创建 B 的 Bean 的过程和 A 一样，也是先创建一个 B 的原始对象，然后把 B 的原始对象提早暴露出来放入缓存中，然后在对 B 的原始对象进行依赖注入 A，此时能从缓存中拿到 A 的原始对象（虽然是 A 的原始对象，还不是最终的 Bean），B 的原始对象依赖注入完了之后，B 的生命周期结束，那么 A 的生命周期也能结束。

因为整个过程中，都只有一个 A 原始对象，所以对于 B 而言，就算在属性注入时，注入的是 A 原始对象，也没有关系，因为A 原始对象在后续的生命周期中在堆中没有发生变化。

为什么 Spring 中还需要 singletonFactories 呢？

从上面这个分析过程中可以得出，只需要一个缓存就能解决循环依赖了，那么为什么 Spring 中还需要 singletonFactories 呢？

基于上面的场景思考一个问题：

如果 A 的原始对象注入给 B 的属性之后，A 的原始对象进行了 AOP 产生了一个代理对象，此时就会出现，对于 A 而言，它的 Bean 对象其实应该是 AOP 之后的代理对象，而 B 的 a 属性对应的并不是 AOP 之后的代理对象，这就产生了冲突。

B 依赖的 A 和最终的 A 不是同一个对象。

那么如何解决这个问题？这个问题可以说没有办法解决。因为在一个 Bean 的生命周期最后，Spring提供了 BeanPostProcessor 可以去对 Bean 进行加工，这个加工不仅仅只是能修改 Bean 的属性值，也可以替换掉当前 Bean 。

在BeanPostProcessor 中可以完全替换掉某个 beanName 对应的 bean 对象。

而 BeanPostProcessor 的执行在 Bean 的生命周期中是处于属性注入之后的，循环依赖是发生在属性注入过程中的，所以很有可能导致，注入给 B 对象的 A 对象和经历过完整生命周期之后的 A 对象，不是一个对象。这就是有问题的。

所以在这种情况下的循环依赖，Spring 是解决不了的，因为在属性注入时，Spring 也不知道 A 对象后续会经过哪些 BeanPostProcessor 以及会对 A 对象做什么处理。