Spring源码(六)-Spring循环依赖的解决方案

前言

结束了两天的河北游，终于回到帝都，这周事情比较多，然而还得继续把上周欠下的债给补上，这一节咱们主要分析一下Spring-IOC中之前被忽略的那些细节以及一些常见的Spring-IOC的面试题。

• 1、Spring循环依赖
• 2、Spring-IOC中的设计模式
• 3、Spring-IOC中常用注解
• 4、Spring-IOC中bean的生命周期
• 5、Spring-IOC中

1、Spring循环依赖

• 1.1、什么是循环依赖？
  循环依赖就是循环引用，就是两个或多个Bean相互之间的持有对方，比如CircleA引用CircleB，CircleB引用CircleA，则它们最终反映为一个环。此处不太理解的可以参考此处
• 1.2、如何检测循环依赖？
  下面我们看下Spring是如何检测循环依赖的

Bean在创建的时候可以给该Bean做校验，如果递归调用回来发现正在创建中的话，即说明了循环依赖。其实这点和Spring初始化的时候读配置文件涉及到import关键字会导致循环导入时的处理手法是一致的。

【DefaultSingletonBeanRegistry】
protected void beforeSingletonCreation(String beanName) {
        if (!this.singletonsCurrentlyInCreation.add(beanName)) {
            throw new BeanCurrentlyInCreationException(beanName);
        }
    }

上图是个单例Bean创建的实例，在创建之前先打标，然后在实例化的时候如果发现已经在创建了，就抛出异常。

【AbstractBeanFactory】
if (isPrototypeCurrentlyInCreation(beanName)) {
                throw new BeanCurrentlyInCreationException(beanName);
    }

• 1.3、Spring如何解决循环依赖？
  假设场景如下，A->B->A
  
  • 1、实例化A，并将未注入属性的A暴露出去，即提前曝光给容器Wrap
  • 2、开始为A注入属性，发现需要B，调用getBean（B）
  • 3、实例化B，并注入属性，发现需要A的时候，从单例缓存中查找，没找到时继而从Wrap中查找，从而完成属性的注入
  • 4、递归完毕之后回到A的实例化过程，A将B注入成功，并注入A的其他属性值，自此即完成了循环依赖的注入

• 1.4、Spring解决循环依赖的几个缓存
  【DefaultSingletonBeanRegistry】中

  • singletonObjects：bean name和 bean实例的缓存map，缓存池
  • singletonFactories：用于保存beanName和创建bean的工厂之间的关系map，单例Bean在创建之初过早的暴露出去的Factory，为什么采用工厂方式，是因为有些Bean是需要被代理的，总不能把代理前的暴露出去那就毫无意义了
  • earlySingletonObjects：执行了工厂方法生产出来的Bean，bean被放进去之后，那么当bean在创建过程中，就可以通过getBean方法获取到，用于检测循环引用，也是个map。
  • singletonsCurrentlyInCreation：如果以上的缓存都是用来解决循环依赖的话，那么这个缓存就是用来检测是否存在循环依赖的

  【AbstractBeanFactory】中

  • alreadyCreated：不管单例还是原型，均会被标记，主要用在循环依赖无法解决的时候擦屁股用的
• 1.4.1、主要步骤如下：
  【AbstractBeanFactory】中doGetBean()方法
  
  • 1、判断该Bean是否已经在创建，是则抛异常

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

• 【AbstractBeanFactory】
  
  • 2、标记该Bean已经被创建，理由见下面

//如果不是做类型检查则是创建bean，这里要进行记录
if (!typeCheckOnly) {
    markBeanAsCreated(beanName);
}

• 【AbstractAutowareCapableBeanFactory】中doCreateBean()
  
  • 3、初始化Bean之前提前把Factory暴露出去

//是否需要提前曝光：单例&允许循环依赖&当bean正在创建中，检测循环依赖
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
        isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
    if (logger.isDebugEnabled()) {
        logger.debug("Eagerly caching bean '" + beanName +
                "' to allow for resolving potential circular references");
    }
    //为避免后期循环依赖，可以在bean初始化完成前将创建实例的ObjectFactory加入工厂
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

为什么不把Bean暴露出去，而是暴露个Factory呢？因为有些Bean是需要被代理的，看下getEarlyBeanReference的实现：
- 【AbstractAutowareCapableBeanFactory】
- 3、getEarlyBeanReference()

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
        Object exposedObject = bean;
        if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
            for (Iterator it = getBeanPostProcessors().iterator(); it.hasNext(); ) {
                BeanPostProcessor bp = (BeanPostProcessor) it.next();
                if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                    SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                    exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
                }
            }
        }
        return exposedObject;
    }

当你依赖到了该Bean而单例缓存里面有没有该Bean的时候就会调用该工厂方法生产Bean，看下getSingleton的实现：
- 【DefaultSingletonBeanRegistry】中
- getSingleton()

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    ObjectFactory singletonFactory = (ObjectFactory) 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);
    }

• 【QA】
  现在有两个疑问了，就举个对Bean进行Wrap的操作吧，Spring是如何规避重复Wrap的呢？
  
  • 1) 从代码可以看到，执行完工厂方法会缓存到earlySingletonObjects中，因此再次调用该方法不会重复执行Wrap的
  • 2) 对于有些BeanPostProcessor提供对Bean的Wrap的操作，但是生命周期位于在set操作之后，如果提前暴露出去被其他Bean执行了工厂方法给Wrap起来，回过来自己再执行BeanPostProcessor的后处理操作的时候不会发生重复吗？

【AbstractAutoProxyCreator】
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        this.earlyProxyReferences.add(cacheKey);
        return wrapIfNecessary(bean, beanName, cacheKey);
    }

【AbstractAutoProxyCreator】
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        if (!this.earlyProxyReferences.contains(cacheKey)) {
            return wrapIfNecessary(bean, beanName, cacheKey);
        }
        return bean;
    }

这个BeanPostProcessor很典型了，用于创建代理类的。一般这种BeanPostProcessor总要提供一个getEarlyBeanReference的接口供其他Bean使用，而又防止了其他类直接使用到该类最原始的版本。这就是上述两个方法如此相似的原因。置于略微的差异，你应该看出来，是防止重复执行方法。

• 【AbstractAutowareCapableBeanFactory】
  
  • initializeBean()：初始化Bean，执行一个个BeanPostProcessor

protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
    if (System.getSecurityManager() != null) {
        AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
            invokeAwareMethods(beanName, bean);
            return null;
        }, getAccessControlContext());
    }
    else {
        invokeAwareMethods(beanName, bean);
    }

    Object wrappedBean = bean;
    if (mbd == null || !mbd.isSynthetic()) {
        wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
    }

    if (wrappedBean != null) {
        try {
            invokeInitMethods(beanName, wrappedBean, mbd);
        }
        catch (Throwable ex) {
            throw new BeanCreationException(
                    (mbd != null ? mbd.getResourceDescription() : null),
                    beanName, "Invocation of init method failed", ex);
        }
        if (mbd == null || !mbd.isSynthetic()) {
            wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
        }
    }

    return wrappedBean;
}

你不能保证这些乱七八糟的BeanPostProcessor会不会改变Bean的版本，当然，如果改变了，肯定要出错的，在这里，Spring就没有做依赖解决了,只是做了依赖检查
- 1.5、Spring解决不了的循环依赖
解决不了的，只能采用依赖检查
【AbstractAutowareCapableBeanFactory】

Object earlySingletonReference = getSingleton(beanName, false);
//只有在检测到有循环依赖的情况下才会不为空
if (earlySingletonReference != null) {
    //如果exposedObject没有在初始化方法中被改变，也就是没有被增强
    if (exposedObject == bean) {
        exposedObject = earlySingletonReference;
    }
    else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
        String[] dependentBeans = getDependentBeans(beanName);
        Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
        //检测依赖
        for (String dependentBean : dependentBeans) {
            if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
                actualDependentBeans.add(dependentBean);
            }
        }
        /**
         * 因为bean创建后其锁依赖的bean一定是已经创建的
         * actualDependentBeans不为空则表示当前bean创建后其依赖的bean却没有全部创建完，也就是说存在循环依赖
         */
        if (!actualDependentBeans.isEmpty()) {
            throw new BeanCurrentlyInCreationException(beanName,
                    "Bean with name '" + beanName + "' has been injected into other beans [" +
                    StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
                    "] in its raw version as part of a circular reference, but has eventually been " +
                    "wrapped. This means that said other beans do not use the final version of the " +
                    "bean. This is often the result of over-eager type matching - consider using " +
                    "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
        }
    }
}

• 1、当发现最初的Bean和ExposedObject不一致的时候（这里其实值得推敲的，只有BeanPostProcessor会导致Bean的版本更新，但是负责处理代理的BeanPostProcessor也会导致版本更新，最后岂不是和普通的BeanPostProcessor一样走到else里面去抛异常了，诡异了！仔细想想负责处理代理的BeanPostProcessor是不会导致Bean的版本更新的，所以最后要把getSingleton取出来的最新版本的Bean赋给它，好好理解吧，真不知道怎么解释了）就会走到else里面，看看else里面的逻辑：

• 2、检查所以依赖到该Bean的哪些Bean们，如果他们已经创建了，那么抛异常！这就是为什么用alreadyCreated的原因，因为原型Bean C如果依赖到了该Bean A的话，原型Bean C还能用么？当然作废了，而且还无法解决，框架只能抛异常告诉程序员。

写在最后

• Spring不能完全解决的循环依赖问题？

  • 1、构造方法注入的bean

  • 2、BeanPostProcessor改变了Bean的版本，AbstractAutoProxyCreator等除外

  • 3、原型Bean

• 面对这样的问题我们该如何解决？

  • 1、就像文章开头所说，根本解决办法是重构代码，从设计角度解决？
  • 2、有的很多很长时间遗留下来的问题，重构几乎不可能，那就只能采用如下方法？

  参考 事例