摘要：實例化時，發現又依賴于。一些緩存的介紹在進行源碼分析前，我們先來看一組緩存的定義。可是看完源碼后，我們似乎仍然不知道這些源碼是如何解決循環依賴問題的。

本文，我們來看一下 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