Spring 对循环依赖的解决

最新推荐文章于 2022-03-29 23:00:22 发布

diaopu2286

最新推荐文章于 2022-03-29 23:00:22 发布

阅读量184

点赞数

文章标签： java

原文链接：http://www.cnblogs.com/jacklovejia/p/9597112.html

版权

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

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

　　当然，Spring对于循环依赖的解决不是无条件的，首先前提条件是针对scope单例并且没有显式指明不需要解决循环依赖的对象，而且要求该对象没有被代理过。同时Spring解决循环依赖也不是万能，以上三种情况只能解决两种，第一种在构造方法中相互依赖的情况Spring也无力回天。结论先给在这，下面来看看Spring的解决方法，知道了解决方案就能明白为啥第一种情况无法解决了。

Spring对于循环依赖的解决

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

createBeanInstance，实例化，实际上就是调用对应的构造方法构造对象，此时只是调用了构造方法，spring xml中指定的property并没有进行populate
populateBean，填充属性，这步对spring xml中指定的property进行populate
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);

这三级缓存分别指：
　　singletonFactories ：单例对象工厂的cache
　　earlySingletonObjects ：提前暴光的单例对象的Cache
　　singletonObjects：单例对象的cache

我们在创建bean的时候，首先想到的是从cache中获取这个单例的bean，这个缓存就是singletonObjects。主要调用方法就就是：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
　　// 检查缓存中是否存在实例
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
　　　　　　// 如果为空, 则锁定全局变量并进行处理
        synchronized (this.singletonObjects) {
　　　　　　　　// 如果此bean 正在加载则不处理
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
　　　　　　　　　　// 当某些方法需要体现初始化的时候则会调用 addSingletonFactory 方法将对应的ObjectFactory 初始化策略存储在singletonFactoies
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
　　　　　　　　　　　　// 调用预先设定的getObject方法
                    singletonObject = singletonFactory.getObject();
　　　　　　　　　　　　// 记录在缓存中, earlySringletionObjects he singletonFactories 互斥 一个加一个删除
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return (singletonObject != NULL_OBJECT ? singletonObject : null);
}

上面的代码需要解释两个参数：

isSingletonCurrentlyInCreation()判断当前单例bean是否正在创建中，也就是没有初始化完成(比如A的构造器依赖了B对象所以得先去创建B对象，或则在A的populateBean过程中依赖了B对象，得先去创建B对象，这时的A就是处于创建中的状态。)
allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象
该方法涉及到循环依赖的检测, 以及涉及很多变量的记录存取, 该方法首先尝试从singletionObjects 里面获取实例, 如果获取不到再从 earlySingletionObjects 里面获取, 如果获取不到, 再次尝试从 singletionFactories 里面获取beanName 对应的ObjectFactory, 然后低啊用这个ObjectFactory 的getObject 来创建bean, 并放到 earlySingletonObject里面去, 并且从 singletonFacotories里面移除这个ObjectFactory, 而对于后续的所有内存操作都只为了循环依赖检测时候使用, 也就是 allowEarlyReference 为true 的情况下会使用,

　　分析getSingleton()的整个过程，Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，如果获取到了则：

    this.earlySingletonObjects.put(beanName, singletonObject);
    this.singletonFactories.remove(beanName);

　　从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。

　　从上面三级缓存的分析，我们可以知道，Spring解决循环依赖的诀窍就在于singletonFactories这个三级cache。这个cache的类型是ObjectFactory，定义如下：

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

这个接口在下面被引用

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三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决。

简单说一下spring 是怎么检测存在循环依赖呢? 以案例一解释

　　Spring 容器将每一个正在创建的 bean 标识符放在一个 "当前创建 bean 池中", bean 标识符在创建过程中将一直保持在这个池中, 因此如果再创建 bean 过程中发现自己已经在 "当前创建 bean 池" 中时, 将抛出 BeanCurrentlyCreationException 异常表示循环依赖; 而对于创建完毕的 bean 将从 "当前创建 bean 池" 中清除掉.

　　Spring创建A, 首先去 "当前创建 bean 池" 查找是否当前 bean 正在创建, 如果没发现, 则继续准备其需要的构造器参数 B, 并将A 标识符放到"当前创建 bean 池"
　　Spring创建B, 首先去 "当前创建 bean 池" 查找是否当前 bean 正在创建, 如果没发现, 则继续准备其需要的构造器参数 A, 并将B 标识符放到"当前创建 bean 池"
　　到此Spring 去创建A 时发现 bean 标识符在 "当前创建 bean 池 " 中, 将抛出 BeanCurrentlyCreationException 异常表示循环依赖

内容参考 http://www.jianshu.com/p/6c359768b1dc & Spring源码解析

转载于:https://www.cnblogs.com/jacklovejia/p/9597112.html