传送：

Spring大观园，我有过的困惑或许你也有！

依赖

Class A里有个ClassB类型的属性b
这种情况叫做A依赖B，

循环依赖

Class A里有个ClassB类型的属性b
Class B里有个ClassA类型的属性a
这种A依赖B,B依赖A的情况，叫循环依赖。

也可能是3（N）个元素构成的循环依赖

image.png

依赖注入

依赖注入，就是属性赋值

实例化与依赖注入（属性赋值）

实例化和依赖注入合为一步走：使用有参构造函数实例化（参数为依赖属性）
实例化和依赖注入分两步走：使用无参构造函数实例化后，再给属性赋值

再次思考依赖的本质

Class A里有个ClassB类型的属性b
这种情况叫做A依赖B

准确的说是A在初始化属性时候需要一个B的实例引用,只要把B实例化后，把引用给A的属性a就行了，B里的属性是否已经正确的初始化什么的，从依赖注入（引用赋值）的视角来看A并不关心。

解决循环依赖的关键

方案1：A依赖B，先把B实例化后的引用给A用，B自己内部的属性赋值的事情，等到A全部处理完事后再处理。
方案2：A依赖B，先实例化A,给属性b赋值前先实例化B，然后把A实例赋值给B内部的属性a，等到B全部处理完了，把实例B赋值给A的属性b,继续处理A的其他属性。spring中使用此方案
即至少有一个可以先用无参构造实例化，后续再做依赖注入。

Spring的循环引用

这边文章理解Spring循环引用（循环依赖）可以了解spring的属性注入的各种套路，这里展示下总结（若无经验可先跳过，最后再看）：

如果循环依赖的bean都是通过构造器注入依赖，那么不管它们是singleton还是prototype，都会失败。
如果循环依赖的bean都是prototype，那么不管它们是通过构造器注入依赖还是通过属性注入依赖，都会失败。
如果循环依赖的bean既有构造器注入也有属性注入，既有singleton也有prototype，在容器启动后，只有当获取的第一个bean是通过属性注入依赖的singleton时，才会成功，别的情况都会失败。

Spring循环引用的破解之法以及准则

打破依赖环，有一个bean可以在自身的依赖还没有得到满足前，就能够被创建出来，即解决循环依赖的关键中的方案2，而且需要遵循以下规则：

这种bean只能是通过属性注入依赖的类，因为它们可以先使用默认构造器创建出实例，然后再通过setter方法注入依赖。
通过构造器注入依赖的类，在它的依赖没有被满足前，无法被实例化。
这个bean，还必须是singleton，不能是prototype

原理分析

Spring容器启动后，如果我们去获取singletonA，那么容器的操作步骤大致如下：

尝试创建bean singletonA，发现singletonA是singleton，且不是通过构造器注入依赖，那么先使用默认构造器创建一个A的实例，并保存对它的引用（曝光到singletonFactories中），并且将singletonA标记为“正在创建中的singleton”（放入singletonsCurrentlyInCreation中）。然后发现singletonA依赖了singletonB，所以尝试创建singletonB。
尝试创建bean singletonB，发现singletonB是singleton，且不是通过构造器注入依赖，那么先使用默认构造器创建一个B的实例，并保存对它的引用，并且将singletonB标记为“正在创建中的singleton”（放入singletonsCurrentlyInCreation中）。然后发现singletonB依赖了singletonA，所以尝试创建singletonA。
尝试创建singletonA，注意，这时Spring容器发现singletonA“正在创建中”，那么就不会再去创建singletonA，而是返回容器之前保存了的对singletonA的引用（从singletonFactories中找到ObjectFactory调用其getObject拿到A对象）。
容器将singletonA通过setter方法注入到singletonB，从而singletonB完成创建（放入singletonObjects中）。
返回singletonA的装配过程，容器将singletonB通过setter方法注入到singletonA，从而singletonA完成创建（放入singletonObjects中。
上述步骤，最重要的是第1步和第3步。在第1步中，容器会保存对singletonA的引用，在第3步中，再返回对singletonA的引用，从而可以成功创建那些依赖了singletonA的bean（本例中是singletonB）。这样，循环依赖的环就在singletonA这个点这里被打破。

从源码分析

Spring单例对象的初始化三步走：

createBeanInstance，实例化，实际上就是调用对应的构造方法构造对象，此时只是调用了构造方法
populateBean，填充属性，这步property进行populate
initializeBean，调用init方法，或者AfterPropertiesSet方法

会发生循环依赖的步骤集中在第一步和第二步。

源码视角

...
//1.实例化bean对象
instanceWrapper = createBeanInstance(beanName, mbd, args);
...
//1.1为此bean，创建一个ObjectFactory对象添加到singletonFactories中。
//这里把Bean先缓存了起来

addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
...
//2.装配属性 
populateBean(beanName, mbd, instanceWrapper);
//3.初始化bean
exposedObject = initializeBean(beanName, exposedObject, mbd);

看一下addSingletonFactory的源码，1.1到底缓存了什么

    protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
        Assert.notNull(singletonFactory, "Singleton factory must not be null");
        synchronized (this.singletonObjects) {
            if (!this.singletonObjects.containsKey(beanName)) {
                //关键点classA在1.1 缓存一些东西到了singletonFactories这里
                //ClassB就是通过singletonFactories 拿到的ClassA
                this.singletonFactories.put(beanName, singletonFactory);
                this.earlySingletonObjects.remove(beanName);
                this.registeredSingletons.add(beanName);
            }
        }
    }

ObjectFactory<?> singletonFactory 是接口

@FunctionalInterface
public interface ObjectFactory<T> {
    T getObject() throws BeansException;
}

1.1 addSingletonFactory时，创建了一个匿名类实现ObjectFactory，getObject方法的实现是EarlyBeanReference(beanName, mbd, bean))，这个实现暂不细究。宏观流程的重点是这里缓存了ClassA这个Bean相关的信息。

模拟一下ClassA和ClassB这两个单例Bean的创建过程

对ClassA 执行完1(实例化）和1.1（缓存一些内容），在第2步，因为依赖B，所以spring开始创建ClassB的bean;
ClassB执行完1和1.1，在第2步，因为依赖A，所以调用了getSingleton方法来获取ClassA的bean，因为ClassA在1.1有个缓存，所以getSingleton拿到了ClassA顺利执行完2和3.
继续ClassA的第2步，注入ClassB，完成2和3步骤结束。

如何通过缓存获取bean

对于单例对象来说，在Spring的整个容器的生命周期内，有且只存在一个对象，使用时就能想到这个对象应该存在Cache中，Spring大量运用了Cache的手段

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);
/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
/** Cache of early singleton objects: bean name --> bean instance */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

singletonObjects缓存创建完成的单例对象，
singletonFactories 缓存用于创建早期单例bean的ObjectFactory，
earlySingletonObjects缓存提前曝光的单例对象（从singletonFactories中拿到ObjectFactory，创建早期bean放入此缓存中，早期bean是已开始创建，但未创建完成的bean）。
先知晓三者大致的关系：

ClassA在1.1环节构建了一个ObjectFactory以"classA"为key添加到singletonFactories Map中
ClassB在2环节，要装配属性a，通过getSingleton方法获取ClassA的bean，参数beanName值为“classA"。
getSingleton中，在singletonFactories找key为“classA”的ObjectFactory，调用其getObject方法拿到了ClassA的bean后，singletonFactories中移除ClassA，然后把ClassA这个bean放到了earlySingletonObjects中，
4.等到ClassB的Bean执行完3之后，ClassB这个Bean就被spring转移到singletonObjects（单例池）中。
总结其流转过程为：
singletonFactories -> earlySingletonObjects -> singletonObjects
所以判断是否存在的流程就是反过来的
singletonObjects -> earlySingletonObjects -> singletonFactories

从源码证实以上逻辑：

首先Spring会尝试从缓存中获取

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
   //单例池中获取
   Object singletonObject = this.singletonObjects.get(beanName);
   // isSingletonCurrentlyInCreation没走完3步的bean有这个标记，意思为还没创建完成。
   if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
      synchronized (this.singletonObjects) {
         // 先判断earlySingletonObjects有没有
         singletonObject = this.earlySingletonObjects.get(beanName);
         if (singletonObject == null && allowEarlyReference) {
            ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
            if (singletonFactory != null) {
               //singletonFactories如果有，就条用其getObject方法来获取
               singletonObject = singletonFactory.getObject();
              //转移缓存，从singletonFactories转移到singletonObject中
               this.earlySingletonObjects.put(beanName, singletonObject);
               this.singletonFactories.remove(beanName);
            }
         }
      }
   }
   return (singletonObject != NULL_OBJECT ? singletonObject : null);}

为什么prototype不能打破循环引用

原因就在于Spring容器只会对singleton保存引用，而对于prototype，并不会对其保存引用，这就导致并不能获得之前创建的bean（因为引用不到它）。

至于为什么容器不对prototype保存引用，那就涉及到singleton和portotpye的概念，如果也对prototype保存引用，那么其实它就变成了singleton。

按道理，在循环依赖的环里，只要有一个bean，是通过属性注入依赖，并且是singleton，那么这个环就可以被打破，无论获取他们的顺序是怎样。“只有当获取的第一个bean是通过属性注入依赖的singleton时，才会成功”，为什么会这样呢？这就和Spring的实现有关了，当Spring容器遍历那些循环依赖的bean时，只要遍历到那种已经遍历过一次的bean，并且它们不是通过属性注入依赖的singleton时，就会直接抛出BeanCurrentlyInCreationException异常。
org.springframework.beans.factory.support.AbstractBeanFactory#doGetBean

...
if (isPrototypeCurrentlyInCreation(beanName)) {
                throw new BeanCurrentlyInCreationException(beanName);
            }
...

总结

为方便理解和以及以流程为主，涉及到的方法细节会在其他源码章节中补充。

感谢你们：

spring 如何解决循环依赖，为什么要创建三个缓存？
Spring源码初探-IOC(4)-Bean的初始化-循环依赖的解决
 源码分析：doCreateBean
硬怼Spring-getBean()(五)

吃透Spring的循环依赖