Spring 循环依赖（5.2.x）

目录

1.回顾getBean过程

2.回顾创建拥有简单依赖关系Bean的过程（类A里依赖类B）

3.Spring是如何解决循环依赖的

4.Spring Bean的代理对象是在什么时候创建的

5.AOP+循环依赖（为什么Spring要引入三级缓存来解决循环依赖）

---

1.回顾getBean过程

        Spring getBean过程如上时序图所示，AbstractBeanFactory第一次调用getSingleton方法入参为beanName：

        如果未查询到Bean信息那么就会二次调用getSingleton方法，入参为beanName和ObjectFactory：

        这里用了一个lambda表达式，这次会尝试创建Bean，内部会回调到上图红框里createBean方法开始创建Bean。

2.回顾创建拥有简单依赖关系Bean的过程（类A里依赖类B）

        代码执行栈： 

        代码Debug Son类：

         Father类：

        XML配置：

        Debug源码，在populateBean填充son对象内部teacher对象前，son对象内部的teacher属性默认填充为RuntimeBeanReference类实例：

        在具体注入属性的方法AbstractAutowireCapableBeanFactory#applyPropertyValues方法 resolveValueIfNecessary方法中有这么一行判断：

        而在resolveReference的构造函数中，我们又见到熟悉的getBean了：

         然后还是按照原来的逻辑，尝试获取Father类实例，如果单例池中不存在则创建father实例，填充father实例属性，初始化father实例，最后将father实例添加到单例池中：

        最后上文中RuntimeBeanReference是在什么时候被设置到son实例中的呢，答案是在解析XML配置信息封装BeanDefinition时，SimplePropertyNamespaceHandler#decorate方法中设置的：

        总结一下：在解析Son类XML配置信息封装BeanDefinition时，会判断XML中是否配置了ref标签，如果配置了，那么就会new一个RuntimeBeanReference对象来标记Son类中存在依赖其他Bean的行为（teacher对象），在后期populateBean填充Son类属性的时候会判断该类中是否存在类行为RuntimeBeanReference的属性值（此时Son类中成员属性teacher的值为RuntimeBeanReference类实例），如果存在则递归进行所需依赖Bean的创建，最后将创建好的Bean添加到单例池中。

3.Spring是如何解决循环依赖的

        循环依赖：顾名思义，就是有两个对象，A对象内部依赖于B对象，而B对象内部同时又依赖了A对象。在单纯的JVM环境中两个对象循环依赖其实没什么问题，两个对象互相持有对方引用地址就好了。那为什么Spring的循坏依赖问题这么复杂呢？究其根本，是因为Spring为了让该框架有用更高的扩展性，维护了一套复杂的Bean生命周期。那么Spring是通过什么方法来解决循环依赖问题的呢？

        首先有A、B两个对象，当我们getBean("A")时，会先去Spring单例池（一级缓存）中判断一下是否存在该Bean，如果不存在则去执行A的创建流程，创建A实例（createBeanInstance）、填充A属性（populateBean），在填充A对象属性的过程中，首先会判断A对象是否允许提前暴露，如果允许提前暴露则将对象A放入半成品池（也就是我们常说的二级缓存），（注：这里说将A对象放入二级缓存是为了先简单理解下Spring解决循环依赖问题的大体思路，实际上Spring是利用三级缓存来解决该问题的）然后Spring发现A对象依赖于B对象，会尝试getBean("B")，发现此时并不存在B对象后，执行创建B实例（createBeanInstance）、填充B属性（populateBean），此时B对象会去单例池中查找是否存在A对象，此时并不会存在（因为A对象还没有被创建完成），单例池中不存在的话再去半成品池中找一下是否有被提前暴露的A对象，发现A对象半成品池中有，继而将A对象填充到B对象的属性中，再执行B对象的初始化方法（initializeBean），然后将完整创建好的B对象添加到单例池中，再把B对象设置到A对象的属性中，最后调用A对象的初始化方法（initializeBean），从而解决循环依赖问题。

        有这么一句名言：计算机行业中没有任何问题是通过加一层中间存储层解决不了的，如果有，就再加一层。说白了，Spring解决循环依赖就是采用新增额外的一层缓存来解决的。

4.Spring Bean的代理对象是在什么时候创建的

        为啥循环依赖的问题中要扯到AOP呢，因为光靠二级缓存是没办法完全解决Spring循环依赖问题的。要完全弄清楚循环依赖，那么就先得了解Spring Bean的代理对象是在什么时候创建的？

        在没开启AOP之前，我们发现getBean获取的是类实例。

        在开启AOP后，发现getBean获取的就不再是普通的类实例，而是类的代理对象。具体代理对象是在AbstractAutowireCapableBeanFactory#applyBeanPostProcessorsAfterInitialization中产生的。

        可以看到执行完processor.postProcessAfterInitialization方法后，userDao就被替换成了代理对象。

        详细堆栈在这里，感兴趣的小伙伴可以自行debug一下。回到开头，为啥循环依赖的问题中要扯到AOP呢？因为二级缓存解决不了代理对象间的循环依赖问题。

5.AOP+循环依赖（为什么Spring要引入三级缓存来解决循环依赖）

        相信即使没看过Spring源码也都了解过Spring是靠三级缓存来解决循环依赖问题的，这三级缓存分别是：

        singletonObjects：一级缓存，存放初始化结束后的单例Bean（可能为普通对象也可能为代理对象）

        earlySingletonObjects：二级缓存，存放只实例化但未初始化结束的bean（可能为普通对象也可能为代理对象）

        singletonFactories：三级缓存，存放只实例化但未初始化结束bean的ObjectFactory

        其实解决循环依赖还用到了singletonsCurrentlyInCreation和earlyProxyReferences：

        singletonsCurrentlyInCreation：用于判断是否出现了循环依赖

        earlyProxyReferences：用于标识是否提前进行过AOP

        首先我们先回顾一下循环依赖问题产生的步骤：

        可以看到从2.2开始产生了死循环问题，那么怎么解决呢？

        我们可以创建一个generalMap（普通对象的Map）来提前存储son对象的引用，这样在2.2步father对象填充son属性的时先尝试从单例池中获取，如果不存在就从generalMap中获取，这样就不会出现循环依赖的问题。但是现在思考一个问题：如果son对象被AOP代理了，那么在第3步初始化son对象的后置增强进行AOP代理后，将会产生一个代理对象，但是在father创建过程中我们已经从generalMap中将son的普通对象填充到了father对象中，这样就产生一个问题：如何能在father对象填充属性的过程中将son的代理对象进行填充？

        现在我们改成在实例化son对象之后就进行AOP代理，然后将代理之后的对象放入generalMap这样确实解决了AOP下father对象需要注入son代理对象的问题，但是又产生了一个新问题：并不是所有的bean都要进行AOP，在实际项目中被AOP代理的类是很少的，比较合适的方法是当我们检测到son出现了循环依赖的时再进行提前引用（提前进行AOP），可是我们在son实例化的时候是没办法知道son类是否会出现循环依赖的（因为可以获取的条件太少了，这才刚创建son对象呢），所以在son实例化的时就去创建AOP是很困难的。

针对上述问题，我们对流程再次进行修改：

        新增了creatingSet用于标识该Bean是否处于创建中阶段，同时将AOP的阶段放在了father尝试获取son的时候，这样就可以解决上面的问题了，但是又引入了一个新问题：假设son类不光依赖了father还依赖了grandFather，那么再给father和grandFather填充的两个son对象不是一个对象：

        这时就引入了Spring二级缓存的概念，先把2.2和2.6中产生的son类的代理对象放入一个map中，在填充son对象的时候先判断一级缓存内有没有，如果没有且此时还出现了循环依赖的话，那么就创建son类的代理对象，并将该对象放入二级缓存：earlySingletonObjects。

        上面的creatingSet在Spring中其实是singletonsCurrentlyInCreation整体替换下：

        此时还有一个问题，在2.2步进行提前AOP时，需要一个传入一个原对象，但按照我们现在的这个逻辑，我们是没办法在提前生成AOP的时拿到原对象的，所以这时候就需要三级缓存singletonFactories：

        整体流程新增了在实例化son对象后，将son对象的factory放入singletonFactories和"如果earlySingletonObjects内不存在则从singletonFactories中获取factory"，获取到bean的factory就可以进行代理对象的创建了。