Spring 是如何解决循环依赖的

前言

在实际工作中，经常由于设计不佳或者各种因素，导致类之间相互依赖。这些类可能单独使用时不会出问题，但是在使用Spring进行管理的时候可能就会抛出BeanCurrentlyInCreationException等异常 。当抛出这种异常时表示Spring解决不了该循环依赖，本文将简要说明Spring对于循环依赖的解决方法。

什么是循环依赖？

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

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

Spring中循环依赖场景有：

（1）构造器的循环依赖

（2）field属性的循环依赖。

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

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

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

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

Spring怎么解决循环依赖

Spring的循环依赖的理论依据其实是基于JAVA的引用传递，当我们获取到对象的引用时，对象的field或则属性是可以延后设置的(但是构造器必须是在获取引用之前)。

Spring的单例对象的初始化主要分为三步：

（1）createBeanInstance：实例化，其实也就是调用对象的构造方法实例化对象

（2）populateBean：填充属性，这一步主要是多bean的依赖属性进行填充

（3）initializeBean：调用spring xml中的init 方法。

从上面讲述的单例bean初始化步骤我们可以知道，循环依赖主要发生在第一、第二部。也就是构造器循环依赖和field循环依赖。

那么我们要解决循环引用也应该从初始化过程着手，对于单例来说，在Spring容器整个生命周期内，有且只有一个对象，所以很容易想到这个对象应该存在Cache中，Spring为了解决单例的循环依赖问题，使用了三级缓存。

主要的几个缓存

1. alreadyCreated：
2. 不管单例还是原型，均会被标记，主要用在循环依赖无法解决的时候擦屁股用的。
3. singletonObjects：
4. 单例Bean的缓存池
5. singletonFactories：
6. 单例Bean在创建之初过早的暴露出去的Factory，为什么采用工厂方式，是因为有些Bean是需要被代理的，总不能把代理前的暴露出去那就毫无意义了。
7. earlySingletonObjects：
8. 执行了工厂方法生产出来的Bean，总不能每次判断是否解决了循环依赖都要执行下工厂方法吧，故而缓存起来。
9. singletonsCurrentlyInCreation：
10. 这个很明白了，如果以上的缓存都是用来解决循环依赖的话，那么这个缓存就是用来检测是否存在循环依赖的。

主要步骤

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

if (isPrototypeCurrentlyInCreation(beanName)) {

throw new BeanCurrentlyInCreationException(beanName);

}

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

protected void markBeanAsCreated(String beanName) {

this.alreadyCreated.add(beanName);

}

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

addSingletonFactory(beanName, new ObjectFactory() {

public Object getObject() throws BeansException {

return getEarlyBeanReference(beanName, mbd, bean);

}

});

为什么不把Bean暴露出去，而是暴露个Factory呢？因为有些Bean是需要被代理的，看下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的实现：

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的后处理操作的时候不会发生重复吗？

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

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

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、循环依赖解决不了的情况下的依赖检查

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还能用么？当然作废了，而且还无法解决，框架只能抛异常告诉程序员。