前言

在實際工作中，經常由於設計不佳或者各種因素，導致類之間相互依賴。這些類可能單獨使用時不會出問題，但是在使用Spring進行管理的時候可能就會丟擲BeanCurrentlyInCreationException等異常 。當丟擲這種異常時表示Spring解決不了該迴圈依賴，本文將簡要說明Spring對於迴圈依賴的解決方法。

迴圈依賴的產生和解決的前提

迴圈依賴的產生可能有很多種情況，例如：

• A的構造方法中依賴了B的例項物件，同時B的構造方法中依賴了A的例項物件
• A的構造方法中依賴了B的例項物件，同時B的某個field或者setter需要A的例項物件，以及反之
• A的某個field或者setter依賴了B的例項物件，同時B的某個field或者setter依賴了A的例項物件，以及反之

當然，Spring對於迴圈依賴的解決不是無條件的，首先前提條件是針對scope單例並且沒有顯式指明不需要解決迴圈依賴的物件，而且要求該物件沒有被代理過。同時Spring解決迴圈依賴也不是萬能，以上三種情況只能解決兩種，第一種在構造方法中相互依賴的情況Spring也無力迴天。結論先給在這，下面來看看Spring的解決方法，知道了解決方案就能明白為啥第一種情況無法解決了。

Spring對於迴圈依賴的解決

Spring迴圈依賴的理論依據其實是Java基於引用傳遞，當我們獲取到物件的引用時，物件的field或者或屬性是可以延後設定的。
Spring單例物件的初始化其實可以分為三步：

• createBeanInstance， 例項化，實際上就是呼叫對應的構造方法構造物件，此時只是呼叫了構造方法，spring xml中指定的property並沒有進行populate
• populateBean，填充屬性，這步對spring xml中指定的property進行populate
• initializeBean，呼叫spring xml中指定的init方法，或者AfterPropertiesSet方法
  會發生迴圈依賴的步驟集中在第一步和第二步。

三級快取

對於單例物件來說，在Spring的整個容器的生命週期內，有且只存在一個物件，很容易想到這個物件應該存在Cache中，Spring大量運用了Cache的手段，在迴圈依賴問題的解決過程中甚至使用了“三級快取”。

“三級快取”主要是指

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);
/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
/** Cache of early singleton objects: bean name --> bean instance */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
 

從字面意思來說：singletonObjects指單例物件的cache，singletonFactories指單例物件工廠的cache，earlySingletonObjects指提前曝光的單例物件的cache。以上三個cache構成了三級快取，Spring就用這三級快取巧妙的解決了迴圈依賴問題。

解決方法

回想上篇文章中關於Bean建立的過程，首先Spring會嘗試從快取中獲取，這個快取就是指singletonObjects，主要呼叫的方法是：

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

首先解釋兩個引數：

• isSingletonCurrentlyInCreation 判斷對應的單例物件是否在建立中，當單例物件沒有被初始化完全(例如A定義的建構函式依賴了B物件，得先去建立B物件，或者在populatebean過程中依賴了B物件，得先去建立B物件，此時A處於建立中)
• allowEarlyReference 是否允許從singletonFactories中通過getObject拿到物件

分析getSingleton的整個過程，Spring首先從singletonObjects（一級快取）中嘗試獲取，如果獲取不到並且物件在建立中，則嘗試從earlySingletonObjects(二級快取)中獲取，如果還是獲取不到並且允許從singletonFactories通過getObject獲取，則通過singletonFactory.getObject()(三級快取)獲取。如果獲取到了則

this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);

則移除對應的singletonFactory,將singletonObject放入到earlySingletonObjects，其實就是將三級快取提升到二級快取中！

Spring解決迴圈依賴的訣竅就在於singletonFactories這個cache，這個cache中存的是型別為ObjectFactory，其定義如下：

public interface ObjectFactory<T> {
    T getObject() throws BeansException;}

在bean建立過程中，有兩處比較重要的匿名內部類實現了該介面。一處是

new ObjectFactory<Object>() {
   @Override   public Object getObject() throws BeansException {
      try {
         return createBean(beanName, mbd, args);
      }      catch (BeansException ex) {
         destroySingleton(beanName);
         throw ex;
      }   }

在上文已經提到，Spring利用其建立bean（這樣做真的很不明確呀...）

另一處就是:

addSingletonFactory(beanName, new ObjectFactory<Object>() {
   @Override   public Object getObject() throws BeansException {
      return getEarlyBeanReference(beanName, mbd, bean);
   }});

此處就是解決迴圈依賴的關鍵，這段程式碼發生在createBeanInstance之後，也就是說單例物件此時已經被創建出來的。這個物件已經被生產出來了，雖然還不完美（還沒有進行初始化的第二步和第三步），但是已經能被人認出來了（根據物件引用能定位到堆中的物件），所以Spring此時將這個物件提前曝光出來讓大家認識，讓大家使用。

這樣做有什麼好處呢？讓我們來分析一下“A的某個field或者setter依賴了B的例項物件，同時B的某個field或者setter依賴了A的例項物件”這種迴圈依賴的情況。A首先完成了初始化的第一步，並且將自己提前曝光到singletonFactories中，此時進行初始化的第二步，發現自己依賴物件B，此時就嘗試去get(B)，發現B還沒有被create，所以走create流程，B在初始化第一步的時候發現自己依賴了物件A，於是嘗試get(A)，嘗試一級快取singletonObjects(肯定沒有，因為A還沒初始化完全)，嘗試二級快取earlySingletonObjects（也沒有），嘗試三級快取singletonFactories，由於A通過ObjectFactory將自己提前曝光了，所以B能夠通過ObjectFactory.getObject拿到A物件(雖然A還沒有初始化完全，但是總比沒有好呀)，B拿到A物件後順利完成了初始化階段1、2、3，完全初始化之後將自己放入到一級快取singletonObjects中。此時返回A中，A此時能拿到B的物件順利完成自己的初始化階段2、3，最終A也完成了初始化，長大成人，進去了一級快取singletonObjects中，而且更加幸運的是，由於B拿到了A的物件引用，所以B現在hold住的A物件也蛻變完美了！一切都是這麼神奇！！

知道了這個原理時候，肯定就知道為啥Spring不能解決“A的構造方法中依賴了B的例項物件，同時B的構造方法中依賴了A的例項物件”這類問題了！

總結

Spring通過三級快取加上“提前曝光”機制，配合Java的物件引用原理，比較完美地解決了某些情況下的迴圈依賴問題！

作者：LNAmp
連結：https://www.jianshu.com/p/6c359768b1dc
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。