在關於Spring的面試中，我們經常會被問到一個問題：Spring是如何解決循環依賴的問題的。 這個問題算是關於Spring的一個高頻面試題，因為如果不刻意研讀，相信即使讀過源碼，面試者也不一定能夠一下子思考出個中奧秘。本文主要針對這個問題，對其實現原理進行深入分析！
什么是循環依賴？
舉個例子
/**
* A 類，引入 B 類的屬性 b
*/
public class A {
private B b;
}
/**
* B 類，引入 A 類的屬性 a
*/
public class B {
private A a;
}
再看個簡單的圖：
像這樣，創建 a 的時候需要依賴 b，那就創建 b，結果創建 b 的時候又需要依賴 a，那就創建 a，創建 a 的時候需要依賴 b，那就創建 b，結果創建 b 的時候又需要依賴 a ……
互相依賴何時了，死循環了吧？ 諾，這就是循環依賴！
循環依賴其實不算個問題或者錯誤，我們實際在開發的時候，也可能會用到。 再拿最開始的 A 和 B 來說，我們手動使用的時候會用以下方式：
A a = new A();
B b = new B();
b.setA(a);
a.setB(b);
其實這樣就解決了循環依賴，功能上是沒有問題的，但是為什么 Spring 要解決循環依賴？
為什么 Spring 要解決循環依賴？
首先簡單了解下，我們用 Spring 框架，它幫我們做了什么事情？總結上來說，六字真言：IoC 和 AOP。
由於 Spring 解決循環依賴是考慮到 IoC 和 AOP 相關知識了，所以這里我先提一下。
由於本文主要的核心是 Spring 的循環依賴處理，所以不會對 IoC 和 AOP 做詳細的說明，想了解以后有機會再說
IoC，主要是將對象的創建、管理都交給了 Spring 來管理，能夠解決對象之間的耦合問題，對開發人員來說也是省時省力的。
AOP，主要是在不改變原有業務邏輯情況下，增強橫切邏輯代碼，也是解耦合，避免橫切邏輯代碼重復；也是對 OOP 的延續、補充。
既然類的實例化都交給了 Spring 來管理了，那么循環依賴 Spring 肯定也要考慮到怎么去處理（怎么總覺得有點像是廢話 ）。
解決循環依賴的方式
參考我們能想到的肯定是手動處理的方式，先將對象都 new 出來，然后進行 set 屬性值，而 Spring 也是通過這樣的形式來處理的（你說巧不巧？其實一點都不巧 ，后面再說為什么），其實 Spring 管理 Bean 的實例化底層其實是由反射實現的。
而我們實例化的方式也有好多種，比如通過構造函數，一次性將屬性賦值，像下面這樣
// 假設有這個類
public class Shop {
private int id;
private String name;
public Shop(int id, String name) {
this.id = id;
this.name = name;
}
}
// 通過構造器方式實例化並賦值
new Shop(1, "Suremotoo");
但是使用構造器這樣的方式，是無法解決循環依賴的！為什么不能呢？
我們還是以文中開頭的 A 和 B 互相依賴來說, 要通過構造器的方式實現 A 的實例化，如下
new A(b);
Wow，是不是發現問題了？要通過構造器的方式，首先要將屬性值實例化出來啊！A 要依賴屬性 b，就需要先將 B 實例化，可是 B 的實例化是不是還是需要依賴 A！這不就是文中開頭描述的樣子嘛，所以通過構造器的方式，Spring 也沒有辦法解決循環依賴。
我們使用 set 可以解決，那么 Spring 也使用 set 方式呢？答案是可以的。
既然底層是通過反射實現的，我們自己也用反射實現的話，大概思路是這樣的（還是以 A 和 B 為例）
- 先實例化 A 類
- 再實例化 B 類
- set B 類中的 a 屬性
- set A 類中的 b 屬性
其實就是通過反射，實現以下代碼
A a = new A();
B b = new B();
b.setA(a);
a.setB(b);
這里可以稍微說明一下，為什么這樣可以？
A a = new A()，說明 A 只是實例化，還未初始化
同理，B b = new B() 也只是實例化，並未初始化
a.setB(b);, 對 a 的屬性賦值，完成 a 的初始化
b.setA(a);, 對 b 的屬性賦值，完成 b 的初始化
現在是不是有點感覺了，先把狗騙進來，再殺
Spring 如何解決循環依賴問題
先上個通俗的答案解釋，三級緩存。
/**
* 單例對象的緩存：bean 名稱——bean 實例，即：所謂的單例池。
* 表示已經經歷了完整生命周期的 Bean 對象
* <b>第一級緩存</b>
*/
Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/**
* 早期的單例對象的高速緩存：bean 名稱——bean 實例。
* 表示 Bean 的生命周期還沒走完（Bean 的屬性還未填充）就把這個 Bean 存入該緩存中
* 也就是實例化但未初始化的 bean 放入該緩存里
* <b>第二級緩存</b>
*/
Map<String, Object> earlySingletonObjects = new HashMap<>(16);
/**
* 單例工廠的高速緩存：bean 名稱——ObjectFactory。
* 表示存放生成 bean 的工廠
* <b>第三級緩存</b>
*/
Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
代碼中注釋可能不清晰，我再給貼一下三級緩存：
第一級緩存（也叫單例池）：Map<String, Object> singletonObjects，存放已經經歷了完整生命周期的 Bean 對象
第二級緩存：Map<String, Object> earlySingletonObjects，存放早期暴露出來的 Bean 對象，Bean 的生命周期未結束（屬性還未填充完）
第三級緩存：Map<String, ObjectFactory<?>> singletonFactories，存放可以生成 Bean 的工廠
Spring 管理的 Bean 其實默認都是單例的，也就是說 Spring 將最終可以使用的 Bean 統一放入第一級緩存中，也就是 singletonObjects（單例池）里，以后凡是用到某個 Bean 了都從這里獲取就行了。
可以僅使用一級緩存？
既然都從 singletonObjects 里獲取，那么僅僅使用這一個 singletonObjects，可以嗎？肯定不可以的。 首先 singletonObjects 存入的是完全初始化好的 Bean，可以拿來直接用的。 如果我們直接將未初始化完的 Bean 放在 singletonObjects 里面，注意，這個未初始化完的 Bean 極有可能會被其他的類拿去用，它都沒完事呢，就被拿去造了，肯定要出事啊！
我們以 A 、 B、C 舉例子
- 先實例化 A 類，叫 a
- 將 a 放入 singletonObjects 中（此時 a 中的 b 屬性還是空的呢）
- C 類需要使用 A 類，去 singletonObjects 獲取，且獲取到了 a
- C 類使用 a，拿出 a 類的 b 屬性，然后 NPE了.
諾，出事了吧，這下就不是解決循環依賴的問題了，反而設計就不對了。
NPE 就是 NullPointerException
可以使用二級緩存？
再來回顧下循環依賴的問題：A→B→A→B……
說到底就是怎么打破這個循環，一級緩存不行，我們就再加一級，可以嗎？ 我們看個圖
圖中的緩存就是二級緩存
看完圖，可能還會有疑惑，A 沒初始化完成放入了緩存，那么 B 用的豈不是就是未完成的 A，是這樣的沒錯！ 在整個過程當中，A 是只有 1 個，而 B 那里的 A 只是 A 的引用，所以后面 A 完成了初始化，B 中的 A 自然也就完成了。這里就是文中前面提到的手動 setA，setB 那里，我再貼一下代碼：
A a = new A();
B b = new B();
b.setA(a); // 這里設置 b 的屬性 a，其實就是 a 的引用
a.setB(b); // 這里設置 a 的屬性 b，此時的 b 已經完成了初始化，設置完 a 的屬性, a 也就完成了初始化，那么對應的 b 也就完成了初始化
分析到這里呢，我們就會發現二級緩存就解決了循環依賴的問題了，可是為什么還要三級緩存呢？ 這里就要說說 Spring 中 Bean 的生命周期。
Spring 中 Bean 的管理
要明白 Spring 中的循環依賴，首先得了解下 Spring 中 Bean 的生命周期。
被 Spring 管理的對象叫 Bean 這里不會對 Bean 的生命周期進行詳細的描述，只是描述一下大概的過程，方便大家去理解循環依賴。
Spring 中 Bean 的生命周期，指的就是 Bean 從創建到銷毀的一系列生命活動。
那么由 Spring 來管理 Bean，要經過的主要步驟有：
- Spring 根據開發人員的配置，掃描哪些類由 Spring 來管理，並為每個類生成一個 BeanDefintion，里面封裝了類的一些信息，如全限定類名、哪些屬性、是否單例等等
- 根據 BeanDefintion 的信息，通過反射，去實例化 Bean（此時就是實例化但未初始化 的 Bean）
- 填充上述未初始化對象中的屬性（依賴注入）
- 如果上述未初始化對象中的方法被 AOP 了，那么就需要生成代理類（也叫包裝類）
- 最后將完成初始化的對象存入緩存中（此處緩存 Spring 里叫： singletonObjects），下次用從緩存獲取 ok 了
如果沒有涉及到 AOP，那么第四步就沒有生成代理類，將第三步完成屬性填充的對象存入緩存中。
二級緩存會有什么問題？
如果 Bean 沒有 AOP，那么用二級緩存其實沒有什么問題的，一旦有上述生命周期中第四步，就會導致的一個問題。因為 AOP 處理后，往往是需要生成代理對象的，代理對象和原來的對象根本就不是 1 個對象。
以二級緩存的場景來說，假設 A 類的某個方法會被 AOP，過程就是這樣的：
- 生成 a 的實例，然后放入緩存，a 需要 b
- 再生成 b ，填充 b 的時候，需要 a，從緩存中取到了 a，完成 b 的初始化；
- 緊接着 a 把初始化好的 b 拿過來用，完成 a 的屬性填充和初始化
- 由於 A 類涉及到了 AOP，再然后 a 要生成一個代理類，這里就叫：代理 a 吧
結果就是：a 最終的產物是代理 a，那 b 中其實也應該用代理 a，而現在 b 中用的卻是原始的 a 代理 a 和原始的 a 不是一個對象，現在這就有問題了。
使用三級緩存如何解決？
二級緩存還是有問題，那就再加一層緩存，也就是第三級緩存：Map<String, ObjectFactory<?>> singletonFactories，在 bean 的生命周期中，創建完對象之后，就會構造一個這個對象對應的 ObjectFactory 存入 singletonFactories 中。
singletonFactories 中存的是某個 beanName 及對應的 ObjectFactory，這個 ObjectFactory 其實就是生成這個 Bean 的工廠。實際中，這個 ObjectFactory 是個 Lambda 表達式：() -> getEarlyBeanReference(beanName, mbd, bean)，而且，這個表達式並沒有執行。
getEarlyBeanReference 具體做了什么事情？
核心就是兩步：
第一步：根據 beanName 將它對應的實例化后且未初始化完的 Bean，存入 Map<Object, Object> earlyProxyReferences = new ConcurrentHashMap<>(16);
第二步：生成該 Bean 對應的代理類返回
這個 earlyProxyReferences其實就是用於記錄哪些 Bean 執行過 AOP，防止后期再次對 Bean 進行 AOP
那么 getEarlyBeanReference 什么時候被觸發，什么時候執行？
在二級緩存示例中，填充 B 的屬性時候，需要 A，然后去緩存中拿 A，此時先去第三級緩存中去取 A，如果存在，此時就執行 getEarlyBeanReference 函數，然后該函數就會返回 A 對應的代理對象。
后續再將該代理對象放入第二級緩存中，也就是 Map<String, Object> earlySingletonObjects里。
為什么不放入第一級緩存？
此時就拿到的代理對象，也是未填充屬性的，也就是仍然是未初始化完的對象。
如果直接放入第一級緩存，此時被其他類拿去使用，肯定有問題了。
那么什么時候放入第一級緩存？
這里需要再簡單說下第二級緩存的作用，假如 A 經過第三級緩存，獲得代理對象，這個代理對象仍然是未初始化完的！那么就暫時把這個代理對象放入第二級緩存，然后刪除該代理對象原本在第三級緩存中的數據（確保后期不會每次都生成新的代理對象），后面其他類要用了 A，就去第二級緩存中找，就獲取到了 A 的代理對象，而且都用的是同一個 A 的代理對象，這樣后面只需要對這一個代理對象進行完善，其他引入該代理對象的類就都完善了。
再往后面，繼續完成 A 的初始化，那么先判斷 A 是否存在於 earlyProxyReferences 中， 存在就說明 A 已經經歷過 AOP 了，就無須再次 AOP。那 A 的操作就轉換從二級緩存中獲取，把 A 的代理類拿出來，填充代理類的屬性。
完成后再將 A 的代理對象加入到第一級緩存，再把它原本在第二級緩存中的數據刪掉，確保后面還用到 A 地類，直接從第一級緩存中獲取。
看個圖理解下
總結
說了這么多，總結下三級緩存：
第一級緩存（也叫單例池）：Map<String, Object> singletonObjects，存放已經經歷了完整生命周期的 Bean 對象
第二級緩存：Map<String, Object> earlySingletonObjects，存放早期暴露出來的 Bean 對象，Bean 的生命周期未結束（屬性還未填充完），可能是代理對象，也可能是原始對象
第三級緩存：Map<String, ObjectFactory<?>> singletonFactories，存放可以生成 Bean 的工廠，工廠主要用來生成 Bean 的代理對象
附: 一個完整的 Spring 循環依賴圖
最后
java高級開發系統進階筆記、最新面試復習筆記PDF，我的GitHub