Spring如何解决循环依赖以及三级缓存概念

转自https://blog.csdn.net/github_38687585/article/details/82317674一、循环依赖的产生和解决的前提循环依赖的产生可能有很多种情况，例如：A的构造方法中依赖了B的实例对象，同时B的构造方法中依赖了A的实例对象A的构造方法中依赖了B的实例对象，同时B的某个field或者setter需要A的实例对象，以及反之A的某个field或者...

givmchickenblood

7361人浏览 · 2019-01-23 21:28:13

givmchickenblood · 2019-01-23 21:28:13 发布

未看超级全面 https://cloud.tencent.com/developer/article/1497692
未看 https://www.cnblogs.com/zgq7/p/14031910.html

转自
https://blog.csdn.net/github_38687585/article/details/82317674

一、循环依赖的产生和解决的前提

循环依赖的产生可能有很多种情况，例如：

A的构造方法中依赖了B的实例对象，同时B的构造方法中依赖了A的实例对象
A的构造方法中依赖了B的实例对象，同时B的某个field或者setter需要A的实例对象，以及反之
A的某个field或者setter依赖了B的实例对象，同时B的某个field或者setter依赖了A的实例对象

Spring对于循环依赖的解决不是无条件的，Spring解决循环依赖的前提是：是针对scope单例并且显式指明需要解决循环依赖的对象，而且要求该对象没有被代理过。同时Spring解决循环依赖也不是万能，以上三种情况只能解决两种，第一种在构造方法中相互依赖的情况Spring也无力回天。

对于多例“prototype”作用域Bean，Spring容器无法完成依赖注入，因为“prototype”作用域的Bean，Spring容器不进行缓存，因此无法提前暴露一个创建中的Bean。

二、Spring循环依赖的理论依据

Spring循环依赖的理论依据其实是Java基于引用传递，当我们获取到对象的引用时，对象的field或者或属性是可以延后设置的。

Spring单例对象的初始化其实可以分为三步：（实例化、填充属性、初始化）
在这里插入图片描述

createBeanInstance， 实例化，实际上就是调用对应的构造方法构造对象，此时只是调用了构造方法，spring xml中指定的property并没有进行赋值
populate：populateBean，填充属性，这步对spring xml中指定的property进行填充
initializeBean，调用spring xml中指定的init方法，或者AfterPropertiesSet方法

循环依赖发生在：第一步和第二步。

三、三级缓存

对于单例对象来说，在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指单例对象的cache，singletonFactories指单例对象工厂的cache，earlySingletonObjects指提前曝光的单例对象的cache。以上三个cache构成了三级缓存，Spring就用这三级缓存巧妙的解决了循环依赖问题。

三级缓存的用法：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {

   Object singletonObject = this.singletonObjects.get(beanName);

   if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {

      synchronized (this.singletonObjects) {

         singletonObject = this.earlySingletonObjects.get(beanName);

         if (singletonObject == null && allowEarlyReference) {

            ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);

            if (singletonFactory != null) {

               singletonObject = singletonFactory.getObject();

               this.earlySingletonObjects.put(beanName, singletonObject);

               this.singletonFactories.remove(beanName);

            }

         }

      }

   }

   return (singletonObject != NULL_OBJECT ? singletonObject : null);}

首先解释两个参数：

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

分析getSingleton的整个过程，Spring首先从singletonObjects（一级缓存）中尝试获取，如果获取不到并且对象在创建中，则尝试从earlySingletonObjects(二级缓存)中获取，如果还是获取不到并且允许从singletonFactories通过getObject获取，则通过singletonFactory.getObject()(三级缓存)获取。如果获取到了，则从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。

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

public interface ObjectFactory<T> {

    T getObject() throws BeansException;
}

在bean创建过程中，有两处比较重要的匿名内部类实现了该接口。一处是Spring利用其创建bean的时候，另一处就是：

addSingletonFactory(beanName, new ObjectFactory() {

		@Override
		public Object getObject() throws BeansException {
		return getEarlyBeanReference(beanName, mbd, bean);
}});

此处就是解决循环依赖的关键，这段代码发生在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对象也蜕变完美了！一切都是这么神奇！！