Spring循环依赖

Spring-bean的循环依赖以及解决方式

Spring里面Bean的生命周期和循环依赖问题

什么是循环依赖？

循环依赖其实就是循环引用，也就是两个或者两个以上的bean互相持有对方，最终形成闭环。比如A依赖于B，B依赖于C，C又依赖于A。如下图：

注意，这里不是函数的循环调用，是对象的相互依赖关系。循环调用其实就是一个死循环，除非有终结条件。

Spring中循环依赖场景有：

（1）构造器的循环依赖

（2）field属性的循环依赖

其中，构造器的循环依赖问题无法解决，只能拋出BeanCurrentlyInCreationException异常，在解决属性循环依赖时，spring采用的是提前暴露对象的方法。

怎么检测是否存在循环依赖

检测循环依赖相对比较容易，Bean在创建的时候可以给该Bean打标，如果递归调用回来发现正在创建中的话，即说明了循环依赖了。

Spring怎么解决循环依赖

Spring的循环依赖的理论依据基于Java的引用传递，当获得对象的引用时，对象的属性是可以延后设置的。（但是构造器必须是在获取引用之前）。

完整实例bean，需要通过上面三个步骤：

1. createBeanInstance方法：得到一个实例bean，但是没有进行属性值的注入

2. populateBean方法：就是对bean进行属性值注入。

3. initializeBean方法：如果配置文件里面有init方法，需要执行init方法。

可以看出第一步和第二步比较重要，这里面就是解决bean依赖的关键。

我们可以看出进行createBeanInstance方法，得到了bean实例对象，但是没有属性注入。把没有完全实例化的bean，放到addSinletonFactory方法里面去，这样相当于就是提前暴露bean，接下来addSinletonFactory方法，这里面使用三个Map类型的，及三级缓存来解决循环依赖。接下我们看一下addSingletonFactory方法实现。

singleObjects--》单例对象的cache：一级缓存

earlySingletonObjects --》提前暴光的单例对象的Cache ：二级缓存

singletonFactories --》单例对象工厂的cache ：三级缓存

首先解释两个参数：

isSingletonCurrentlyInCreation 判断对应的单例对象是否在创建中，当单例对象没有被初始化完全(例如A定义的构造函数依赖了B对象，得先去创建B对象，或者在populatebean过程中依赖了B对象，得先去创建B对象，此时A处于创建中)
allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象

在创建bean的时候，首先想到的是从cache中获取这个单例的bean，这个缓存就是singletonObjects。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，如果获取到了则：从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。

Spring解决循环依赖的诀窍就在于singletonFactories这个cache，这个cache中存的是类型为ObjectFactory，其定义如下

public interface ObjectFactory<T> {

    T getObject() throws BeansException;}

在bean创建过程中，有两处比较重要的匿名内部类实现了该接口。一处是

new ObjectFactory<Object>() {

   @Override   public Object getObject() throws BeansException {

      try {

         return createBean(beanName, mbd, args);

      }      catch (BeansException ex) {

         destroySingleton(beanName);

         throw ex;

      }   }

另一处就是

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {

    Assert.notNull(singletonFactory, "Singleton factory must not be null");

    synchronized (this.singletonObjects) {

        if (!this.singletonObjects.containsKey(beanName)) {

            this.singletonFactories.put(beanName, singletonFactory);

            this.earlySingletonObjects.remove(beanName);

            this.registeredSingletons.add(beanName);

        }

    }

}

这里就是解决循环依赖的关键，这段代码发生在createBeanInstance之后，也就是说单例对象此时已经被创建出来(调用了构造器)。这个对象已经被生产出来了，虽然还不完美（还没有进行初始化的第二步和第三步），但是已经能被人认出来了（根据对象引用能定位到堆中的对象），所以Spring此时将这个对象提前曝光出来让大家认识，让大家使用。

这样做有什么好处呢？让我们来分析一下“A的某个field或者setter依赖了B的实例对象，同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步，并且将自己提前曝光到singletonFactories中，此时进行初始化的第二步，发现自己依赖对象B，此时就尝试去get(B)，发现B还没有被create，所以走create流程，B在初始化第一步的时候发现自己依赖了对象A，于是尝试get(A)，尝试一级缓存singletonObjects(肯定没有，因为A还没初始化完全)，尝试二级缓存earlySingletonObjects（也没有），尝试三级缓存singletonFactories，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全，但是总比没有好呀)，B拿到A对象后顺利完成了初始化阶段1、2、3，完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中，A此时能拿到B的对象顺利完成自己的初始化阶段2、3，最终A也完成了初始化，进去了一级缓存singletonObjects中，而且更加幸运的是，由于B拿到了A的对象引用，所以B现在hold住的A对象完成了初始化。

知道了这个原理时候，肯定就知道为啥Spring不能解决“A的构造方法中依赖了B的实例对象，同时B的构造方法中依赖了A的实例对象”这类问题了！因为加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决。

为啥要三级缓存

必须使用三级缓存吗两级不行吗提前暴露时直接放到二级缓存earlySingletonObjects里会有什么问题呢？

answer：如果不存在循环依赖，那么就没必要提早曝光放到earlySingletonObjects里。如果像你说的只有两级缓存，那简单的A依赖B，A在第一步初始化未注入field的时候就放到了earlySingletonObjects，显然不符合常理，只能说放到三级缓存中预防循环依赖的产生。singletonFactories 并没有提早曝光的意思，只是为了缓存，earlySingletonObjects才为了提早曝光，所以才要三级的。