Spring IOC容器是如何解决循环依赖的问题？

• 什么是循环依赖？
  先看代码：

 

public class A {
    private B b;
    // 省略set/get方法
}

public class B {
    private A a;
    // 省略set/get方法
}

可以看到A类里有一个属性是B类对象，而B类里也有一个属性是A类对象，则我们可以称A类对象与B类对象之间互相循环依赖。然后我们对把这俩个类纳入到IOC容器中进行管理，现在进行xml配置：

 

<bean id="a" class="com.A">
    <property name="b" ref="b"/>
</bean>

<bean id="b" class="com.B">
    <property name="a" ref="a"/>
</bean>

当配置好xml以后，我们创建容器，并且调用getBean方法来获取某个对象，那么会发生什么事情呢？正常逻辑应该是发生了死循环，a对象的创建需要依赖b对象，而b对象的创建同时也需要a对象。这简直就是没办法解决嘛！但是SpringIOC却解决了这个问题，并且你可以正常的获取到相应的对象而不会发生错误。
那么SpringIOC是如何解决循环依赖的问题呢？

原理
SpringIOC解决循环依赖的思路就是依靠缓存，同时还得引出个概念即早期暴露引用。我们知道在IOC容器里bean的初始化的过程分为三个步骤：创建实例、属性注入实例、回调实例实现的接口方法。解决思路就在这：当我们创建实例与属性注入实例这俩个步骤之间的时候，我们引入缓存，将这些已经创建好但是并没有注入属性的实例放到缓存里，而这些放在缓存里但是没有被注入属性的实例对象，就是解决循环依赖的方法，打个比方：A对象的创建需要引用到B对象，而B对象的创建也需要A对象，而此时当B对象创建的时候直接从缓存里引用A对象（虽然不是完全体A对象，毕竟没有赋值处理），当B对象完成创建以后再被A对象引用进去，则A对象也完成了创建。
这就是SpringIOC解决bean直接循环依赖的思路当然有一个小问题，IOC能够解决的只能是属性之间的循环依赖，如果有bean之间的构造器相互依赖则就解决不了只能报错了。

• 我们现在来看看Spring IOC的源码

先看一下下面介绍源码里的缓存的表：

源码	级别	描述
singletonObjects	一级缓存	用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用
earlySingletonObjects	二级缓存	存放原始的 bean 对象（尚未填充属性），用于解决循环依赖
singletonFactories	三级缓存	存放 bean 工厂对象，用于解决循环依赖

省略不必要的代码

 

protected <T> T doGetBean( final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
            throws BeansException {

    
    Object bean;

    // 从缓存中取得bean的实例
    Object sharedInstance = getSingleton(beanName);
    if (sharedInstance != null && args == null) {
        //进行后续处理，如果是正常的普通bean则返回普通的bean，如果是实现了FactoryBean接口的bean则返回的是getObject里的内容
        bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
    }
    else {
        if (!typeCheckOnly) {
            markBeanAsCreated(beanName);
        }

        try {
            final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
            checkMergedBeanDefinition(mbd, beanName, args);

            // 解决依赖的问题，这个跟我们说的依赖是不一样的.可以忽略
            // ......
            

            // 创建单例 bean
            if (mbd.isSingleton()) {
                sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
                    @Override
                    public Object getObject() throws BeansException {
                        try {
                            return createBean(beanName, mbd, args);
                        }
                        catch (BeansException ex) {
                            // 发生异常，销毁bean
                            destroySingleton(beanName);
                            throw ex;
                        }
                    }
                });
                bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
            }
        }
        catch (BeansException ex) {
            cleanupAfterBeanCreationFailure(beanName);
            throw ex;
        }
    }

    // Check if required type matches the type of the actual bean instance.
    // ......
    return (T) bean;
}

以上是doGetBean方法里的代码，当然我省略了跟本章无关的代码。
一步步来吧，先进行初始化a对象的操作，然后发现调用的是createBean(String beanName, RootBeanDefinition mbd, Object[] args)方法，而真正起作用的是doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)方法。而在这个方法里面包含了三个重要的方法createBeanInstance、populateBean、initializeBean，看过之前系列文章的人都知道这三个方法分别代表：创建实例、属性注入、方法回调，这是bean初始化的核心方法。当然下面这段代码是在createBeanInstance和populateBean中间的一段doCreateBean的代码。

 

boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
    // ......
    addSingletonFactory(beanName, new ObjectFactory<Object>() {
        @Override
        public Object getObject() throws BeansException {
            return getEarlyBeanReference(beanName, mbd, bean);
        }
    });
}

这段代码在spring源码注释里描述是用来解决循环依赖的问题的。包含了一个匿名内部类ObjectFactory<T>（普通的工厂类返回的是getObject方法返回的对象），用getEarlyBeanReference实现了getObject方法。同时还调用了addSingletonFactory方法。分别来看一下各自方法的实现：

 

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

 

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

可以看到在addSingletonFactory方法中，会将beanName与singletonFactory形成kv关系put进singletonFactories里面。并且将earlySingletonObjects里面的key值为beanName的kv进行移除。
此时a对象的早期暴露引用已经存在了singletonFactories三级缓存里面。此时a对象进行populateBean方法进行属性注入，发现需要依赖b对象，紧接着就是去初始化b对象。继续重复上面的步骤到b对象进行属性注入这一步的时候（此时singletonFactories三级缓存里已经有了a对象的提前暴露引用和b对象的提前暴露引用的工厂对象），发现需要依赖a对象，此时去获取a对象，看代码：

 

// Eagerly check singleton cache for manually registered singletons.
Object sharedInstance = getSingleton(beanName);

//继续看这个方法
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);
}

先从singletonObjects一级缓存里取，如果没有取到，则从earlySingletonObjects二级缓存里取，如果还是没取到，则从singletonFactories三级缓存里取，取到以后进行getObject方法返回早期暴露对象引用，同时放进earlySingletonObjects二级缓存里，并且三级缓存里进行删除该kv。
那么到此，a对象的早期暴露引用已经被b对象获取到了，并且在singletonFactories三级缓存里已经没有a对象的早期暴露引用的工厂对象了，a对象的早期暴露引用存在了二级缓存earlySingletonObjects里面，当然singletonFactories三级缓存依然有b对象的早期暴露引用的工厂对象。

继续：b对象拿到了a对象的早期暴露引用，进行完属性注入以后，则返回一个b对象了同时调用方法getSingleton(String beanName, ObjectFactory<?> singletonFactory)，看源码：

 

//我已经删除了很多无关的代码
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
    // ......
    synchronized (this.singletonObjects) {
        Object singletonObject = this.singletonObjects.get(beanName);
            if (singletonObject == null) {
                // ......              
                beforeSingletonCreation(beanName);
                boolean newSingleton = false;
               // ... ...
               //... ...
                try {
                    singletonObject = singletonFactory.getObject();
                    newSingleton = true;
                }
                finally {
                    // ... ...
                }
                if (newSingleton) {
                    addSingleton(beanName, singletonObject);
                }
            }
            return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }
}

其实就是俩个方法:singletonObject = singletonFactory.getObject();和addSingleton(beanName, singletonObject);至此我们不需要说明第一个了，着重来看一下addSingleton方法。

 

protected void addSingleton(String beanName, Object singletonObject) {
    synchronized (this.singletonObjects) {
        this.singletonObjects.put(beanName, (singletonObject != null ? singletonObject : NULL_OBJECT));
        this.singletonFactories.remove(beanName);
        this.earlySingletonObjects.remove(beanName);
        this.registeredSingletons.add(beanName);
    }
}

ok，上面源码已经说明了此时singletonObjects一级缓存将要存入b对象，而二级缓存earlySingletonObjects和三级缓存singletonFactories则把相关缓存的对象移除。至此b对象则只存在一级缓存singletonObjects里面了。
当b对象完成了初始化以后，a对象则进行相关属性的注入引入b的对象。完成实例化的同时a对象也会调用一次addSingleton方法，那么a对象完成以后，也就只有一级缓存singletonObjects里面才有a对象。

至此，属性的循环依赖问题则完美的得到解决。

• 文末
  感谢 【减肥是生命的主旋律】 的提问和回答
  有一个小问题，为什么在解决循环依赖问题的时候，我们会用到三级缓存singletonFactories呢？感觉二级缓存earlySingletonObjects就可以解决问题了呢？
  那么答案就在这里：

 

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

在将三级缓存放入二级缓存的时候，会判断是否有SmartInstantiationAwareBeanPostProcessor这样的后置处理器，换句话说这里是给用户提供接口扩展的，所以采用了三级缓存。

链接：https://www.jianshu.com/p/a77e64250a9e