Spring如何解决循环依赖

先了解几个概念：

singletonObjects：单例池，也称之为一级缓存。 earlySingletonObjects：未完成初始化的单例池，也称之为二级缓存 。 singletonFactories：三级缓存，实际上存放“创建对象的lambda表达式”（如果是普通对象直接返回，如果需要AOP则执行lambda表达式会创建一个代理对象）。 原始对象：未经过完整生命周期的bean 代理对象：如果Spring扫描时发现某个对象需要切面，Spring最终会经过AOP为其创建一个代理对象，并放入单例池中。

什么是循环依赖？

简单来说就是对象A依赖来对象B，而对象B又依赖来对象A，如下面代码：

// A -> B
class A{
    public B b;
}

// B -> A
class B{
    public A a;
}

循环依赖带来的影响

实际上，如果对象不是放在在Spring容器中管理，上面代码是没有所谓循环依赖问题，可以正常运行。而循环依赖之所以产生，是因为Spring中的bean创建要经过一定的生命周期。

A与B的bean创建流程：

• 假设A先被扫描到，于是先执行A的bean生命周期：

1、实例化A得到一个原始对象

2、给A中的B属性赋值，于是执行B的bean生命周期

...

初始化后，可能进行AOP

• 执行B的bean生命周期：

1、实例化B得到一个原始对象

2、给B中的A属性赋值，于是去执行A的bean生命周期

...

初始化后，可能进行AOP

按照常规逻辑，当上面A的生命周期执行到第2步时，会去执行B的生命周期，而B的生命周期执行到第2步又需要一个A对象，于是又会去走A的生命周期。。此时便出现循环依赖问题了，如下图所示。

image.png

三级缓存之 “第二级缓存“：earlySingletonObjects

顺着上面的思路，如果由我们来设计Spring，会如何设计解决上面这种循环依赖的问题？加一个中间缓存（二级缓存，Spring中对应名称为earlySingletonObjects）似乎就可以解决，思路如下：

在创建完A原始对象后，会将其放入earlySingletonObjects缓存中（提早暴露给其它的bean），然后注入依赖B，此时发现B在singletonObjects单例池中（图中省略）不存在且earlySingletonObjects也不存在，于是创建B的bean，创建B的bean过程也和创建A一样，会先创建B的原始对象并放入earlySingletonObjects中进行暴露，然后注入依赖A，此时发现A不存在于singletonObjects，但A的原始对象存在于singletonsCurrentlyInCreation（说明A的bean也正在创建中），于是从earlySingletonObjects找，可以找到一个原始对象，B完成依赖注入并实例化后，A也可以完成依赖注入。

image.png

那么上面这样处理方式，是否就能解决循环依赖问题了？咋一看似乎满足了，但实际上下面场景就会打破上面这种平衡。

场景：如果A的原始对象注入给B的属性之后，A的原始对象进行了AOP（按照bean的生命周期，AOP是在初始化后在后置处理器中处理的），此时会产生另外一个对象-代理对象，这个对象最终会被存放到单例池singletonObjects中，也就是说，对于A而言，它最终的bean对象实际上应该是AOP之后的代理对象而不是原来那个原始对象，但B拿的是原始对象，这就产生冲突：B依赖的A和最终的A不是同一个对象。（这也回答了面试题：解决Spring循环依赖问题只用一二级缓存行不行？）

三级缓存之 “第三级缓存“：singletonFactories

那么如何解决B依赖的A和最终的A不是同一个对象这种冲突？

方式1：不管有没有循环依赖问题，统一在初始化前AOP？这种做法明显破坏了Spring所设定的bean生命周期，如果为了解决循环依赖问题去破坏bean生命周期的设计原则，那么得不偿失。

方式2：判断是否依赖的对象也在创建，如果是才提前对该对象进行AOP，并将AOP代理对象存放起来，后续该对象在初始化后，判断如果对象已被代理过，是则不再进行AOP。

对比发现显然第二种方式更加合适，Spring也确实采用了第二种方式来解决冲突，于是三级缓存：singletonFactories派上用场。就像其名一样，singletonFactories是一个单例工厂。如果我们打开Spring源码，可以看到它的值存的是一个beanName → lambda表达式，这个lambda表达式可能用到也可能用不到。

• 何时存入lambda表达式？

存入步骤是在创建完原始对象之后执行的，Spring中是在AbstractAutowireCapableBeanFactory.doCreateBean() → getSingleTon() 中进行存储。

image.png

• 什么时候执行lambda表达式？

获取bean的逻辑，走的是DefaultSingletonBeanRegistry.getBean()，当getBean调用到getSingleton()时，会进入下面代码。从代码可以看出，只有当1级、2级缓存拿不到bean时，且存在循环依赖问题（通过代码isSingletonCurrentlyInCreation(beanName)判断）时，才会去执行lambda表达式，获取真正的bean（普通原始对象或代理对象），并将其放入二级缓存earlySingletonObjects中，同时删除三级缓存中的引用（注意：此处因为需要保证原子性，前面对singletonObjects加了独占锁）。

image.png

• lambda中的逻辑是啥？

同样是在AbstractAutowireCapableBeanFactory类中，可以从getEarlyBeanReference方法中看到，最终lambda表达式执行的逻辑，就是去遍历所有后置处理器，然后在SmartInstantiationAwareBeanPostProcessor的实现类中的getEarlyBeanReference方法中去创建bean，而创建的bean可能是普通原始对象 （在InstantiationAwareBeanPostProcessorAdapter中，直接返回当前bean），也可能是代理对象（也就是提前AOP，在 AbstractAutoProxyCreator中通过jdk动态代理或cglib创建），需要注意的是无论是普通对象还是代理对象，都不是经过完整生命周期的最终对象，因此在执行lambda表达式后不能将返回的bean直接放入一级缓存，即单例池singletonObjects中，而是要先放到二级缓存提前暴露给其他bean，只有经过所有后置处理器BeanPostProcesssor后才会真正放入singletonObjects中。

image.png

• 如果bean被提前AOP，初始化后的AOP逻辑中，要如何判断不需再进行AOP？

当bean初始化后，后置处理器AbstractAutoProxyCreator中的postProcessAfterInitialization方法会被调用，其中存在这么一段逻辑，即判断earlyProxyReferences（又是一个cache，但一般不会把它计入三级缓存中）中是否已有该cache，有则说明已经进行过AOP，那么就不会再次进行AOP。（wrapIfNecessary中还有更多细节的判断是否需要AOP，此处相当于提前截断，不需要再进行细节判断了）

image.png

什么时候下Spring解决不了循环依赖？

• 情况一：使用构造器注入

Spring在创建原始对象的原理也是调用构造器进行创建，如果使用构造器进行注入，那么Spring自身无法解决循环依赖问题，此时加入@Lazy注解即可，原理是对于Lazy修饰的对象，Spring会先创建一个代理对象给属性赋值，那么依赖方就可以正常进行实例化了。

class A {

    B b;

    @Autowired
    public void method(B b) {
        this.b = b;
    }
}

class B {
    A a;

    @Autowired
    public void method(A a) {
        this.a = a;
    }
}

• 情况二：循环依赖且用@Async注解修饰方法

Spring在扫描bean、发现某个类方法被@Async修饰时，会通过后置处理器AsyncAnnotationBeanPostProcessor生成代理对象，而该后置处理器的顺序比处理AOP的后置处理器还靠后，因此仍然会导致Spring处理不了循环依赖。同理，可以使用@Lazy注解解决该问题。

class A {

    @Autowired
    B b;

    @Async
    public void method() {
        b.xx();
    }
}

class B {
    A a;
}