Spring之循环依赖

转：http://my.oschina.net/tryUcatchUfinallyU/blog/287936

• 概述
• 如何检测循环依赖
• 循环依赖如何解决
• Spring如何解决循环依赖
• 主要的几个缓存
• 主要步骤
• Spring不能完全解决的循环依赖问题
• 面对Spring不能完全解决的现状，我们该如何处理

概述

入职的时候学习spring研究过循环依赖，现在再回顾下，发现啥都忘记了，还是得总结下来，故总结该文。

本文主要解决如下问题：

1、何为循环依赖

2、如何检测循环依赖

3、循环依赖可以如何解决

4、Spring解决循环依赖需要面对哪些困难

5、Spring是如何解决循环依赖的

6、Spring对于循环依赖的解决方案是否还有纰漏

7、既然不能完全解决循环依赖，我们该怎么办

何为循环依赖

可以参照这篇博文：http://jinnianshilongnian.iteye.com/blog/1415278

循环依赖就是循环引用，就是两个或多个Bean相互之间的持有对方，比如CircleA引用CircleB，CircleB引用CircleC，CircleC引用CircleA，则它们最终反映为一个环。此处不是循环调用，循环调用是方法之间的环调用，如下图：

循环调用是无法解决的，除非有终结条件，否则就是死循环，最终导致内存溢出错误。Spring容器循环依赖包括构造器循环依赖和setter循环依赖，那Spring容器如何检测和解决循环依赖呢？

如何检测循环依赖

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

?

1 2 3 4 5 6

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

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

?

1 2 3 4

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

循环依赖如何解决

循环调用是无法解决的，除非有终结条件，否则就是死循环，因此必须打破这个循环，具体做法如下：
假设场景如下，A->B->A
step1、实例化A，并将未注入属性的A暴露出去，假设暴露给容器Wrap
step2、开始为A注入属性，发现需要B，因此调用getBean(B)
step3、实例化B，并注入属性，当发现需要A的时候，从单例缓存中查找未果，继而从Wrap中查找，从而完成属性的注入
step4、递归完毕之后回到A的实例化过程，A将B注入成功，并注入A的其他属性值，自此即完成了循环依赖的注入。

Spring如何解决循环依赖

主要的几个缓存

• alreadyCreated：不管单例还是原型，均会被标记，主要用在循环依赖无法解决的时候擦屁股用的。

• singletonObjects：单例Bean的缓存池

• singletonFactories：单例Bean在创建之初过早的暴露出去的Factory，为什么采用工厂方式，是因为有些Bean是需要被代理的，总不能把代理前的暴露出去那就毫无意义了。

• earlySingletonObjects：执行了工厂方法生产出来的Bean，总不能每次判断是否解决了循环依赖都要执行下工厂方法吧，故而缓存起来。

• singletonsCurrentlyInCreation：这个很明白了，如果以上的缓存都是用来解决循环依赖的话，那么这个缓存就是用来检测是否存在循环依赖的。

主要步骤

1、判断该Bean是否已经在创建，是则抛异常

?

1 2 3

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

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

?

1 2 3

protected void markBeanAsCreated(String beanName) {         this.alreadyCreated.add(beanName);     }

3、初始化Bean之前提前把Factory暴露出去

?

1 2 3 4 5

addSingletonFactory(beanName, new ObjectFactory() {                 public Object getObject() throws BeansException {                     return getEarlyBeanReference(beanName, mbd, bean);                 }             });

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

?

1 2 3 4 5 6 7 8 9 10 11 12 13

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的实现：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

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);     }

现在有两个疑问了，就举个对Bean进行Wrap的操作吧，Spring是如何规避重复Wrap的呢？

1）从代码可以看到，执行完工厂方法会缓存到earlySingletonObjects中，因此再次调用该方法不会重复执行Wrap的

2）对于有些BeanPostProcessor提供对Bean的Wrap的操作，但是生命周期位于在set操作之后，如果提前暴露出去被其他Bean执行了工厂方法给Wrap起来，回过来自己再执行BeanPostProcessor的后处理操作的时候不会发生重复吗？

?

1 2 3 4 5 6

【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);     }

?

1 2 3 4 5 6 7 8

【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使用，而又防止了其他类直接使用到该类最原始的版本。这就是上述两个方法如此相似的原因。置于略微的差异，你应该看出来，是防止重复执行方法。

4、初始化Bean，执行一个个BeanPostProcessor

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

protected Object initializeBean(String beanName, Object bean, RootBeanDefinition mbd) {         if (bean instanceof BeanNameAware) {             ((BeanNameAware) bean).setBeanName(beanName);         }            if (bean instanceof BeanClassLoaderAware) {             ((BeanClassLoaderAware) bean).setBeanClassLoader(getBeanClassLoader());         }            if (bean instanceof BeanFactoryAware) {             ((BeanFactoryAware) bean).setBeanFactory(this);         }            Object wrappedBean = bean;         if (mbd == null || !mbd.isSynthetic()) {             wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);         }            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就没有做依赖解决了（都给你把代理类解决了你还想啥呢），只是做了检查，如下。

5、循环依赖解决不了的情况下的依赖检查

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Object earlySingletonReference = getSingleton(beanName, false);             if (earlySingletonReference != null) {                 if (exposedObject == bean) {                     exposedObject = earlySingletonReference;                 }                 else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {                     String[] dependentBeans = getDependentBeans(beanName);                     Set actualDependentBeans = new LinkedHashSet(dependentBeans.length);                     for (int i = 0; i < dependentBeans.length; i++) {                         String dependentBean = dependentBeans[i];                         if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {                             actualDependentBeans.add(dependentBean);                         }                     }                     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

面对Spring不能完全解决的现状，我们该如何处理

1、本来有循环依赖就是设计的不合理，变更Bean的依赖关系

2、实在不想改，可采取下面的方法：