Spring IOC 容器源码分析 - 循环依赖的解决办法

摘要：实例化时，发现又依赖于。一些缓存的介绍在进行源码分析前，我们先来看一组缓存的定义。可是看完源码后，我们似乎仍然不知道这些源码是如何解决循环依赖问题的。

本文，我们来看一下 Spring 是如何解决循环依赖问题的。在本篇文章中，我会首先向大家介绍一下什么是循环依赖。然后，进入源码分析阶段。为了更好的说明 Spring 解决循环依赖的办法，我将会从获取 bean 的方法getBean(String)开始，把整个调用过程梳理一遍。梳理完后，再来详细分析源码。通过这几步的讲解，希望让大家能够弄懂什么是循环依赖，以及如何解循环依赖。

循环依赖相关的源码本身不是很复杂，不过这里要先介绍大量的前置知识。不然这些源码看起来很简单，但读起来可能却也不知所云。那下面我们先来了解一下什么是循环依赖。

所谓的循环依赖是指，A 依赖 B，B 又依赖 A，它们之间形成了循环依赖。或者是 A 依赖 B，B 依赖 C，C 又依赖 A。它们之间的依赖关系如下：

这里以两个类直接相互依赖为例，他们的实现代码可能如下：

public class BeanB {
    private BeanA beanA;
    // 省略 getter/setter
}

public class BeanA {
    private BeanB beanB;
}

配置信息如下：

IOC 容器在读到上面的配置时，会按照顺序，先去实例化 beanA。然后发现 beanA 依赖于 beanB，接在又去实例化 beanB。实例化 beanB 时，发现 beanB 又依赖于 beanA。如果容器不处理循环依赖的话，容器会无限执行上面的流程，直到内存溢出，程序崩溃。当然，Spring 是不会让这种情况发生的。在容器再次发现 beanB 依赖于 beanA 时，容器会获取 beanA 对象的一个早期的引用（early reference），并把这个早期引用注入到 beanB 中，让 beanB 先完成实例化。beanB 完成实例化，beanA 就可以获取到 beanB 的引用，beanA 随之完成实例化。这里大家可能不知道“早期引用”是什么意思，这里先别着急，我会在下一章进行说明。

好了，本章先到这里，我们继续往下看。

在进行源码分析前，我们先来看一组缓存的定义。如下：

/** Cache of singleton objects: bean name --> bean instance */
private final Map singletonObjects = new ConcurrentHashMap(256);

/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map> singletonFactories = new HashMap>(16);

/** Cache of early singleton objects: bean name --> bean instance */
private final Map earlySingletonObjects = new HashMap(16);

根据缓存变量上面的注释，大家应该能大致了解他们的用途。我这里简单说明一下吧：

上一章提到了”早期引用“，所谓的”早期引用“是指向原始对象的引用。所谓的原始对象是指刚创建好的对象，但还未填充属性。这样讲大家不知道大家听明白了没，不过没听明白也不要紧。简单做个实验就知道了，这里我们先定义一个对象 Room：

/** Room 包含了一些电器 */
public class Room {
    private String television;
    private String airConditioner;
    private String refrigerator;
    private String washer;
    // 省略 getter/setter
}

配置如下：

我们先看一下完全实例化好后的 bean 长什么样的。如下：

从调试信息中可以看得出，Room 的每个成员变量都被赋上值了。然后我们再来看一下“原始的 bean 对象”长的是什么样的，如下：

结果比较明显了，所有字段都是 null。这里的 bean 和上面的 bean 指向的是同一个对象Room@1567，但现在这个对象所有字段都是 null，我们把这种对象成为原始的对象。形象点说，上面的 bean 对象是一个装修好的房子，可以拎包入住了。而这里的 bean 对象还是个毛坯房，还要装修一下（填充属性）才行。

本节，我们来了解从 Spring IOC 容器中获取 bean 实例的流程（简化版），这对我们后续的源码分析会有比较大的帮助。先看图：

先来简单介绍一下这张图，这张图是一个简化后的流程图。开始流程图中只有一条执行路径，在条件 sharedInstance != null 这里出现了岔路，形成了绿色和红色两条路径。在上图中，读取/添加缓存的方法我用蓝色的框和☆标注了出来。至于虚线的箭头，和虚线框里的路径，这个下面会说到。

我来按照上面的图，分析一下整个流程的执行顺序。这个流程从 getBean 方法开始，getBean 是个空壳方法，所有逻辑都在 doGetBean 方法中。doGetBean 首先会调用 getSingleton(beanName) 方法获取 sharedInstance，sharedInstance 可能是完全实例化好的 bean，也可能是一个原始的 bean，当然也有可能是 null。如果不为 null，则走绿色的那条路径。再经 getObjectForBeanInstance 这一步处理后，绿色的这条执行路径就结束了。

我们再来看一下红色的那条执行路径，也就是 sharedInstance = null 的情况。在第一次获取某个 bean 的时候，缓存中是没有记录的，所以这个时候要走创建逻辑。上图中的 getSingleton(beanName,
new ObjectFactory