在關于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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/287972.html

標籤：Java

上一篇：java語言中“==”和“equals”方法的區別

下一篇：性能分析之CPU分析-從CPU呼叫高到具體代碼行（JAVA）

爛大街的 Spring 回圈依賴問題，你覺得自己會了嗎