自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

爛了大街的 Spring 循環(huán)依賴問題，你以為自己就真會了嗎

作者：海星
開發(fā) 前端
初學 Spring 的時候，我們就知道 IOC，控制反轉(zhuǎn)么，它將原本在程序中手動創(chuàng)建對象的控制權(quán)，交由 Spring 框架來管理，不需要我們手動去各種 new XXX。

[[340562]]

本文轉(zhuǎn)載自微信公眾號「JavaKeeper」，作者海星 。轉(zhuǎn)載本文請聯(lián)系JavaKeeper公眾號。  

前言

循環(huán)依賴問題，算是一道爛大街的面試題了，解毒之前，我們先來回顧兩個知識點：

初學 Spring 的時候，我們就知道 IOC，控制反轉(zhuǎn)么，它將原本在程序中手動創(chuàng)建對象的控制權(quán)，交由 Spring 框架來管理，不需要我們手動去各種 new XXX。

盡管是 Spring 管理，不也得創(chuàng)建對象嗎， Java 對象的創(chuàng)建步驟很多，可以 new XXX、序列化、clone() 等等， 只是 Spring 是通過反射 + 工廠的方式創(chuàng)建對象并放在容器的，創(chuàng)建好的對象我們一般還會對對象屬性進行賦值，才去使用，可以理解是分了兩個步驟。

好了，對這兩個步驟有個印象就行，接著我們進入循環(huán)依賴，先說下循環(huán)依賴的概念

什么是循環(huán)依賴

所謂的循環(huán)依賴是指，A 依賴 B，B 又依賴 A，它們之間形成了循環(huán)依賴?；蛘呤?A 依賴 B，B 依賴 C，C 又依賴 A，形成了循環(huán)依賴。更或者是自己依賴自己。它們之間的依賴關(guān)系如下：

 

這里以兩個類直接相互依賴為例，他們的實現(xiàn)代碼可能如下：

  1. public class BeanB { 
  2.     private BeanA beanA; 
  3.     public void setBeanA(BeanA beanA) { 
  4.   this.beanA = beanA; 
  5.  } 
  6. } 
  7.  
  8. public class BeanA { 
  9.     private BeanB beanB; 
  10.     public void setBeanB(BeanB beanB) { 
  11.         this.beanB = beanB; 
  12.  } 
  13. } 

配置信息如下(用注解方式注入同理，只是為了方便理解，用了配置文件)：

  1. <bean id="beanA" class="priv.starfish.BeanA"> 
  2.   <property name="beanB" ref="beanB"/> 
  3. </bean> 
  4.  
  5. <bean id="beanB" class="priv.starfish.BeanB"> 
  6.   <property name="beanA" ref="beanA"/> 
  7. </bean> 

Spring 啟動后，讀取如上的配置文件，會按順序先實例化 A，但是創(chuàng)建的時候又發(fā)現(xiàn)它依賴了 B，接著就去實例化 B ，同樣又發(fā)現(xiàn)它依賴了 A ，這尼瑪咋整?無限循環(huán)呀

Spring “肯定”不會讓這種事情發(fā)生的，如前言我們說的 Spring 實例化對象分兩步，第一步會先創(chuàng)建一個原始對象，只是沒有設(shè)置屬性，可以理解為"半成品"—— 官方叫 A 對象的早期引用(EarlyBeanReference)，所以當實例化 B 的時候發(fā)現(xiàn)依賴了 A， B 就會把這個“半成品”設(shè)置進去先完成實例化，既然 B 完成了實例化，所以 A 就可以獲得 B 的引用，也完成實例化了，這其實就是 Spring 解決循環(huán)依賴的思想。

 

不理解沒關(guān)系，先有個大概的印象，然后我們從源碼來看下 Spring 具體是怎么解決的。

源碼解毒

代碼版本：5.0.16.RELEASE

在 Spring IOC 容器讀取 Bean 配置創(chuàng)建 Bean 實例之前, 必須對它進行實例化。只有在容器實例化后，才可以從 IOC 容器里獲取 Bean 實例并使用，循環(huán)依賴問題也就是發(fā)生在實例化 Bean 的過程中的，所以我們先回顧下獲取 Bean 的過程。

獲取 Bean 流程

Spring IOC 容器中獲取 bean 實例的簡化版流程如下(排除了各種包裝和檢查的過程)

 

大概的流程順序(可以結(jié)合著源碼看下，我就不貼了，貼太多的話，嘔~嘔嘔，想吐)：

流程從 getBean 方法開始，getBean 是個空殼方法，所有邏輯直接到 doGetBean 方法中

transformedBeanName 將 name 轉(zhuǎn)換為真正的 beanName(name 可能是 FactoryBean 以 & 字符開頭或者有別名的情況，所以需要轉(zhuǎn)化下)

然后通過 getSingleton(beanName) 方法嘗試從緩存中查找是不是有該實例 sharedInstance(單例在 Spring 的同一容器只會被創(chuàng)建一次，后續(xù)再獲取 bean，就直接從緩存獲取即可)

如果有的話，sharedInstance 可能是完全實例化好的 bean，也可能是一個原始的 bean，所以再經(jīng) getObjectForBeanInstance 處理即可返回

當然 sharedInstance 也可能是 null，這時候就會執(zhí)行創(chuàng)建 bean 的邏輯，將結(jié)果返回

第三步的時候我們提到了一個緩存的概念，這個就是 Spring 為了解決單例的循環(huán)依賴問題而設(shè)計的 三級緩存

  1. /** Cache of singleton objects: bean name --> bean instance */ 
  2. private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); 
  3.  
  4. /** Cache of singleton factories: bean name --> ObjectFactory */ 
  5. private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); 
  6.  
  7. /** Cache of early singleton objects: bean name --> bean instance */ 
  8. private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); 

這三級緩存的作用分別是：

  • singletonObjects：完成初始化的單例對象的 cache，這里的 bean 經(jīng)歷過 實例化->屬性填充->初始化 以及各種后置處理(一級緩存)
  • earlySingletonObjects：存放原始的 bean 對象(完成實例化但是尚未填充屬性和初始化)，僅僅能作為指針提前曝光，被其他 bean 所引用，用于解決循環(huán)依賴的 (二級緩存)
  • singletonFactories：在 bean 實例化完之后，屬性填充以及初始化之前，如果允許提前曝光，Spring 會將實例化后的 bean 提前曝光，也就是把該 bean 轉(zhuǎn)換成beanFactory 并加入到 singletonFactories(三級緩存)

我們首先從緩存中試著獲取 bean，就是從這三級緩存中查找

  1. protected Object getSingleton(String beanName, boolean allowEarlyReference) { 
  2.     // 從 singletonObjects 獲取實例，singletonObjects 中的實例都是準備好的 bean 實例，可以直接使用 
  3.     Object singletonObject = this.singletonObjects.get(beanName); 
  4.     //isSingletonCurrentlyInCreation() 判斷當前單例bean是否正在創(chuàng)建中 
  5.     if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { 
  6.         synchronized (this.singletonObjects) { 
  7.             // 一級緩存沒有，就去二級緩存找 
  8.             singletonObject = this.earlySingletonObjects.get(beanName); 
  9.             if (singletonObject == null && allowEarlyReference) { 
  10.                 // 二級緩存也沒有，就去三級緩存找 
  11.                 ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); 
  12.                 if (singletonFactory != null) { 
  13.                     // 三級緩存有的話，就把他移動到二級緩存,.getObject() 后續(xù)會講到 
  14.                     singletonObject = singletonFactory.getObject(); 
  15.                     this.earlySingletonObjects.put(beanName, singletonObject); 
  16.                     this.singletonFactories.remove(beanName); 
  17.                 } 
  18.             } 
  19.         } 
  20.     } 
  21.     return singletonObject; 
  22. } 

如果緩存沒有的話，我們就要創(chuàng)建了，接著我們以單例對象為例，再看下創(chuàng)建 bean 的邏輯(大括號表示內(nèi)部類調(diào)用方法)：

 

 

1.創(chuàng)建 bean 從以下代碼開始，一個匿名內(nèi)部類方法參數(shù)(總覺得 Lambda 的方式可讀性不如內(nèi)部類好理解)

  1. if (mbd.isSingleton()) { 
  2.     sharedInstance = getSingleton(beanName, () -> { 
  3.         try { 
  4.             return createBean(beanName, mbd, args); 
  5.         } 
  6.         catch (BeansException ex) { 
  7.             destroySingleton(beanName); 
  8.             throw ex; 
  9.         } 
  10.     }); 
  11.     bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd); 
  12. } 

getSingleton() 方法內(nèi)部主要有兩個方法

  1. public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) { 
  2.     // 創(chuàng)建 singletonObject 
  3.  singletonObject = singletonFactory.getObject(); 
  4.     // 將 singletonObject 放入緩存 
  5.     addSingleton(beanName, singletonObject); 
  6. } 

2.getObject() 匿名內(nèi)部類的實現(xiàn)真正調(diào)用的又是 createBean(beanName, mbd, args)

3.往里走，主要的實現(xiàn)邏輯在 doCreateBean方法，先通過 createBeanInstance 創(chuàng)建一個原始 bean 對象

4.接著 addSingletonFactory 添加 bean 工廠對象到 singletonFactories 緩存(三級緩存)

5.通過 populateBean 方法向原始 bean 對象中填充屬性，并解析依賴，假設(shè)這時候創(chuàng)建 A 之后填充屬性時發(fā)現(xiàn)依賴 B，然后創(chuàng)建依賴對象 B 的時候又發(fā)現(xiàn)依賴 A，還是同樣的流程，又去 getBean(A)，這個時候三級緩存已經(jīng)有了 beanA 的“半成品”，這時就可以把 A 對象的原始引用注入 B 對象(并將其移動到二級緩存)來解決循環(huán)依賴問題。這時候 getObject() 方法就算執(zhí)行結(jié)束了，返回完全實例化的 bean

6.最后調(diào)用 addSingleton 把完全實例化好的 bean 對象放入 singletonObjects 緩存(一級緩存)中，打完收工

Spring 解決循環(huán)依賴

建議搭配著“源碼”看下邊的邏輯圖，更好下飯

 

流程其實上邊都已經(jīng)說過了，結(jié)合著上圖我們再看下具體細節(jié)，用大白話再捋一捋：

  1. Spring 創(chuàng)建 bean 主要分為兩個步驟，創(chuàng)建原始 bean 對象，接著去填充對象屬性和初始化
  2. 每次創(chuàng)建 bean 之前，我們都會從緩存中查下有沒有該 bean，因為是單例，只能有一個
  3. 當我們創(chuàng)建 beanA 的原始對象后，并把它放到三級緩存中，接下來就該填充對象屬性了，這時候發(fā)現(xiàn)依賴了 beanB，接著就又去創(chuàng)建 beanB，同樣的流程，創(chuàng)建完 beanB 填充屬性時又發(fā)現(xiàn)它依賴了 beanA，又是同樣的流程，不同的是，這時候可以在三級緩存中查到剛放進去的原始對象 beanA，所以不需要繼續(xù)創(chuàng)建，用它注入 beanB，完成 beanB 的創(chuàng)建
  4. 既然 beanB 創(chuàng)建好了，所以 beanA 就可以完成填充屬性的步驟了，接著執(zhí)行剩下的邏輯，閉環(huán)完成

這就是單例模式下 Spring 解決循環(huán)依賴的流程了。

但是這個地方，不管是誰看源碼都會有個小疑惑，為什么需要三級緩存呢，我趕腳二級他也夠了呀

革命尚未成功，同志仍需努力

跟源碼的時候，發(fā)現(xiàn)在創(chuàng)建 beanB 需要引用 beanA 這個“半成品”的時候，就會觸發(fā)"前期引用"，即如下代碼：

  1. ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); 
  2. if (singletonFactory != null) { 
  3.     // 三級緩存有的話，就把他移動到二級緩存 
  4.     singletonObject = singletonFactory.getObject(); 
  5.     this.earlySingletonObjects.put(beanName, singletonObject); 
  6.     this.singletonFactories.remove(beanName); 
  7. } 

singletonFactory.getObject() 是一個接口方法，這里具體的實現(xiàn)方法在

  1. protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) { 
  2.     Object exposedObject = bean; 
  3.     if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) { 
  4.         for (BeanPostProcessor bp : getBeanPostProcessors()) { 
  5.             if (bp instanceof SmartInstantiationAwareBeanPostProcessor) { 
  6.                 SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp; 
  7.                 // 這么一大段就這句話是核心，也就是當bean要進行提前曝光時， 
  8.                 // 給一個機會，通過重寫后置處理器的getEarlyBeanReference方法，來自定義操作bean 
  9.                 // 值得注意的是，如果提前曝光了，但是沒有被提前引用，則該后置處理器并不生效!!! 
  10.                 // 這也正式三級緩存存在的意義，否則二級緩存就可以解決循環(huán)依賴的問題 
  11.                 exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName); 
  12.             } 
  13.         } 
  14.     } 
  15.     return exposedObject; 
  16. } 

這個方法就是 Spring 為什么使用三級緩存，而不是二級緩存的原因，它的目的是為了后置處理，如果沒有 AOP 后置處理，就不會走進 if 語句，直接返回了 exposedObject ，相當于啥都沒干，二級緩存就夠用了。

所以又得出結(jié)論，這個三級緩存應該和 AOP 有關(guān)系，繼續(xù)。

在 Spring 的源碼中g(shù)etEarlyBeanReference 是 SmartInstantiationAwareBeanPostProcessor接口的默認方法，真正實現(xiàn)這個方法的只有**AbstractAutoProxyCreator** 這個類，用于提前曝光的 AOP 代理。

  1. @Override 
  2. public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { 
  3.    Object cacheKey = getCacheKey(bean.getClass(), beanName); 
  4.    this.earlyProxyReferences.put(cacheKey, bean); 
  5.    // 對bean進行提前Spring AOP代理 
  6.    return wrapIfNecessary(bean, beanName, cacheKey); 
  7. } 

這么說有點干，來個小 demo 吧，我們都知道 Spring AOP、事務等都是通過代理對象來實現(xiàn)的，而事務的代理對象是由自動代理創(chuàng)建器來自動完成的。也就是說 Spring 最終給我們放進容器里面的是一個代理對象，而非原始對象，假設(shè)我們有如下一段業(yè)務代碼：

  1. @Service 
  2. public class HelloServiceImpl implements HelloService { 
  3.    @Autowired 
  4.    private HelloService helloService; 
  5.  
  6.    @Override 
  7.    @Transactional 
  8.    public Object hello() { 
  9.       return "Hello JavaKeeper"; 
  10.    } 
  11. } 

此 Service 類使用到了事務，所以最終會生成一個 JDK 動態(tài)代理對象 Proxy。剛好它又存在自己引用自己的循環(huán)依賴，完美符合我們的場景需求。

我們再自定義一個后置處理，來看下效果：

  1. @Component 
  2. public class HelloProcessor implements SmartInstantiationAwareBeanPostProcessor { 
  3.  
  4.  @Override 
  5.  public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException { 
  6.   System.out.println("提前曝光了："+beanName); 
  7.   return bean; 
  8.  } 
  9. } 

可以看到，調(diào)用方法棧中有我們自己實現(xiàn)的 HelloProcessor，說明這個 bean 會通過 AOP 代理處理。

 

再從源碼看下這個自己循環(huán)自己的 bean 的創(chuàng)建流程：

  1. protected Object doCreateBean( ... ){ 
  2.  ... 
  3.   
  4.  boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); 
  5.     // 需要提前暴露（支持循環(huán)依賴），就注冊一個ObjectFactory到三級緩存 
  6.  if (earlySingletonExposure) {  
  7.         // 添加 bean 工廠對象到 singletonFactories 緩存中，并獲取原始對象的早期引用 
  8.   //匿名內(nèi)部方法 getEarlyBeanReference 就是后置處理器  
  9.   // SmartInstantiationAwareBeanPostProcessor 的一個方法， 
  10.   // 它的功效為：保證自己被循環(huán)依賴的時候，即使被別的Bean @Autowire進去的也是代理對象 
  11.   addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); 
  12.  } 
  13.  
  14.  // 此處注意：如果此處自己被循環(huán)依賴了  那它會走上面的getEarlyBeanReference，從而創(chuàng)建一個代理對象從  三級緩存轉(zhuǎn)移到二級緩存里 
  15.  // 注意此時候?qū)ο筮€在二級緩存里，并沒有在一級緩存。并且此時后續(xù)的這兩步操作還是用的 exposedObject，它仍舊是原始對象~~~ 
  16.  populateBean(beanName, mbd, instanceWrapper); 
  17.  exposedObject = initializeBean(beanName, exposedObject, mbd); 
  18.  
  19.  // 因為事務的AOP自動代理創(chuàng)建器在getEarlyBeanReference 創(chuàng)建代理后，initializeBean 就不會再重復創(chuàng)建了，二選一的） 
  20.       
  21.  // 所以經(jīng)過這兩大步后，exposedObject 還是原始對象，通過 getEarlyBeanReference 創(chuàng)建的代理對象還在三級緩存呢 
  22.   
  23.  ... 
  24.   
  25.  // 循環(huán)依賴校驗 
  26.  if (earlySingletonExposure) { 
  27.         // 注意此處第二個參數(shù)傳的false，表示不去三級緩存里再去調(diào)用一次getObject()方法了~~~，此時代理對象還在二級緩存，所以這里拿出來的就是個 代理對象 
  28.   // 最后賦值給exposedObject  然后return出去，進而最終被addSingleton()添加進一級緩存里面去   
  29.   // 這樣就保證了我們?nèi)萜骼?nbsp;最終實際上是代理對象，而非原始對象~~~~~ 
  30.   Object earlySingletonReference = getSingleton(beanName, false); 
  31.   if (earlySingletonReference != null) { 
  32.    if (exposedObject == bean) {  
  33.     exposedObject = earlySingletonReference; 
  34.    } 
  35.   } 
  36.   ... 
  37.  } 
  38.   
  39. } 

自我解惑：

問：還是不太懂，為什么這么設(shè)計呢，即使有代理，在二級緩存代理也可以吧 | 為什么要使用三級緩存呢?

我們再來看下相關(guān)代碼，假設(shè)我們現(xiàn)在是二級緩存架構(gòu)，創(chuàng)建 A 的時候，我們不知道有沒有循環(huán)依賴，所以放入二級緩存提前暴露，接著創(chuàng)建 B，也是放入二級緩存，這時候發(fā)現(xiàn)又循環(huán)依賴了 A，就去二級緩存找，是有，但是如果此時還有 AOP 代理呢，我們要的是代理對象可不是原始對象，這怎么辦，只能改邏輯，在第一步的時候，不管3721，所有 Bean 統(tǒng)統(tǒng)去完成 AOP 代理，如果是這樣的話，就不需要三級緩存了，但是這樣不僅沒有必要，而且違背了 Spring 在結(jié)合 AOP 跟 Bean 的生命周期的設(shè)計。

所以 Spring “多此一舉”的將實例先封裝到 ObjectFactory 中(三級緩存)，主要關(guān)鍵點在 getObject() 方法并非直接返回實例，而是對實例又使用 SmartInstantiationAwareBeanPostProcessor 的 getEarlyBeanReference 方法對 bean 進行處理，也就是說，當 Spring 中存在該后置處理器，所有的單例 bean 在實例化后都會被進行提前曝光到三級緩存中，但是并不是所有的 bean 都存在循環(huán)依賴，也就是三級緩存到二級緩存的步驟不一定都會被執(zhí)行，有可能曝光后直接創(chuàng)建完成，沒被提前引用過，就直接被加入到一級緩存中。因此可以確保只有提前曝光且被引用的 bean 才會進行該后置處理。

  1. protected Object getSingleton(String beanName, boolean allowEarlyReference) { 
  2.     Object singletonObject = this.singletonObjects.get(beanName); 
  3.     if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) { 
  4.         synchronized (this.singletonObjects) { 
  5.             singletonObject = this.earlySingletonObjects.get(beanName); 
  6.             if (singletonObject == null && allowEarlyReference) { 
  7.              // 三級緩存獲取，key=beanName value=objectFactory，objectFactory中存儲     //getObject()方法用于獲取提前曝光的實例 
  8.                 ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName); 
  9.                 if (singletonFactory != null) { 
  10.                     // 三級緩存有的話，就把他移動到二級緩存 
  11.                     singletonObject = singletonFactory.getObject(); 
  12.                     this.earlySingletonObjects.put(beanName, singletonObject); 
  13.                     this.singletonFactories.remove(beanName); 
  14.                 } 
  15.             } 
  16.         } 
  17.     } 
  18.     return singletonObject; 
  19. } 
  20.  
  21.  
  22. boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && 
  23.       isSingletonCurrentlyInCreation(beanName)); 
  24. if (earlySingletonExposure) { 
  25.    if (logger.isDebugEnabled()) { 
  26.       logger.debug("Eagerly caching bean '" + beanName + 
  27.             "' to allow for resolving potential circular references"); 
  28.    } 
  29.    // 添加 bean 工廠對象到 singletonFactories 緩存中，并獲取原始對象的早期引用 
  30.    //匿名內(nèi)部方法 getEarlyBeanReference 就是后置處理器 
  31.    // SmartInstantiationAwareBeanPostProcessor 的一個方法， 
  32.    // 它的功效為：保證自己被循環(huán)依賴的時候，即使被別的Bean @Autowire進去的也是代理對象~~~~  AOP自動代理創(chuàng)建器此方法里會創(chuàng)建的代理對象~~~ 
  33.    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean)); 
  34. } 

再問：AOP 代理對象提前放入了三級緩存，沒有經(jīng)過屬性填充和初始化，這個代理又是如何保證依賴屬性的注入的呢?

這個又涉及到了 Spring 中動態(tài)代理的實現(xiàn)，不管是cglib代理還是jdk動態(tài)代理生成的代理類，代理時，會將目標對象 target 保存在最后生成的代理 $proxy 中，當調(diào)用 $proxy 方法時會回調(diào) h.invoke，而 h.invoke 又會回調(diào)目標對象 target 的原始方法。所有，其實在 AOP 動態(tài)代理時，原始 bean 已經(jīng)被保存在 提前曝光代理中了，之后 原始 bean 繼續(xù)完成屬性填充和初始化操作。因為 AOP 代理$proxy中保存著 traget 也就是是 原始bean 的引用，因此后續(xù) 原始bean 的完善，也就相當于Spring AOP中的 target 的完善，這樣就保證了 AOP 的屬性填充與初始化了!

非單例循環(huán)依賴

看完了單例模式的循環(huán)依賴，我們再看下非單例的情況，假設(shè)我們的配置文件是這樣的：

  1. <bean id="beanA" class="priv.starfish.BeanA" scope="prototype"> 
  2.    <property name="beanB" ref="beanB"/> 
  3. </bean> 
  4.  
  5. <bean id="beanB" class="priv.starfish.BeanB" scope="prototype"> 
  6.    <property name="beanA" ref="beanA"/> 
  7. </bean> 

啟動 Spring，結(jié)果如下：

  1. Error creating bean with name 'beanA' defined in class path resource [applicationContext.xml]: Cannot resolve reference to bean 'beanB' while setting bean property 'beanB'; 
  2.  
  3. Error creating bean with name 'beanB' defined in class path resource [applicationContext.xml]: Cannot resolve reference to bean 'beanA' while setting bean property 'beanA'; 
  4.  
  5. Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'beanA': Requested bean is currently in creation: Is there an unresolvable circular reference? 

對于 prototype 作用域的 bean，Spring 容器無法完成依賴注入，因為 Spring 容器不進行緩存 prototype 作用域的 bean ，因此無法提前暴露一個創(chuàng)建中的bean 。

原因也挺好理解的，原型模式每次請求都會創(chuàng)建一個實例對象，即使加了緩存，循環(huán)引用太多的話，就比較麻煩了就，所以 Spring 不支持這種方式，直接拋出異常：

  1. if (isPrototypeCurrentlyInCreation(beanName)) { 
  2.    throw new BeanCurrentlyInCreationException(beanName); 
  3. } 

構(gòu)造器循環(huán)依賴

上文我們講的是通過 Setter 方法注入的單例 bean 的循環(huán)依賴問題，用 Spring 的小伙伴也都知道，依賴注入的方式還有構(gòu)造器注入、工廠方法注入的方式(很少使用)，那如果構(gòu)造器注入方式也有循環(huán)依賴，可以搞不?

我們再改下代碼和配置文件

  1. public class BeanA { 
  2.    private BeanB beanB; 
  3.    public BeanA(BeanB beanB) { 
  4.       this.beanB = beanB; 
  5.    } 
  6. } 
  7.  
  8. public class BeanB { 
  9.  private BeanA beanA; 
  10.  public BeanB(BeanA beanA) { 
  11.   this.beanA = beanA; 
  12.  } 
  13. } 
  1. <bean id="beanA" class="priv.starfish.BeanA"> 
  2. <constructor-arg ref="beanB"/> 
  3. </bean> 
  4.  
  5. <bean id="beanB" class="priv.starfish.BeanB"> 
  6. <constructor-arg ref="beanA"/> 
  7. </bean> 

執(zhí)行結(jié)果，又是異常

 

看看官方給出的說法

Circular dependencies

If you use predominantly constructor injection, it is possible to create an unresolvable circular dependency scenario.

For example: Class A requires an instance of class B through constructor injection, and class B requires an instance of class A through constructor injection. If you configure beans for classes A and B to be injected into each other, the Spring IoC container detects this circular reference at runtime, and throws a BeanCurrentlyInCreationException.

One possible solution is to edit the source code of some classes to be configured by setters rather than constructors. Alternatively, avoid constructor injection and use setter injection only. In other words, although it is not recommended, you can configure circular dependencies with setter injection.

Unlike the typical case (with no circular dependencies), a circular dependency between bean A and bean B forces one of the beans to be injected into the other prior to being fully initialized itself (a classic chicken-and-egg scenario).

大概意思是：

如果您主要使用構(gòu)造器注入，循環(huán)依賴場景是無法解決的。建議你用 setter 注入方式代替構(gòu)造器注入

其實也不是說只要是構(gòu)造器注入就會有循環(huán)依賴問題，Spring 在創(chuàng)建 Bean 的時候默認是按照自然排序來進行創(chuàng)建的，我們暫且把先創(chuàng)建的 bean 叫主 bean，上文的 A 即主 bean，只要主 bean 注入依賴 bean 的方式是 setter 方式，依賴 bean 的注入方式無所謂，都可以解決，反之亦然

所以上文我們 AB 循環(huán)依賴問題，只要 A 的注入方式是 setter ，就不會有循環(huán)依賴問題。

面試官問：為什么呢?

Spring 解決循環(huán)依賴依靠的是 Bean 的“中間態(tài)”這個概念，而這個中間態(tài)指的是已經(jīng)實例化，但還沒初始化的狀態(tài)。實例化的過程又是通過構(gòu)造器創(chuàng)建的，如果 A 還沒創(chuàng)建好出來，怎么可能提前曝光，所以構(gòu)造器的循環(huán)依賴無法解決，我一直認為應該先有雞才能有蛋。

小總結(jié) | 面試這么答B(yǎng) 中提前注入了一個沒有經(jīng)過初始化的 A 類型對象不會有問題嗎?

雖然在創(chuàng)建 B 時會提前給 B 注入了一個還未初始化的 A 對象，但是在創(chuàng)建 A 的流程中一直使用的是注入到 B 中的 A 對象的引用，之后會根據(jù)這個引用對 A 進行初始化，所以這是沒有問題的。

Spring 是如何解決的循環(huán)依賴?

Spring 為了解決單例的循環(huán)依賴問題，使用了三級緩存。其中一級緩存為單例池(singletonObjects)，二級緩存為提前曝光對象(earlySingletonObjects)，三級緩存為提前曝光對象工廠(singletonFactories)。

假設(shè)A、B循環(huán)引用，實例化 A 的時候就將其放入三級緩存中，接著填充屬性的時候，發(fā)現(xiàn)依賴了 B，同樣的流程也是實例化后放入三級緩存，接著去填充屬性時又發(fā)現(xiàn)自己依賴 A，這時候從緩存中查找到早期暴露的 A，沒有 AOP 代理的話，直接將 A 的原始對象注入 B，完成 B 的初始化后，進行屬性填充和初始化，這時候 B 完成后，就去完成剩下的 A 的步驟，如果有 AOP 代理，就進行 AOP 處理獲取代理后的對象 A，注入 B，走剩下的流程。

為什么要使用三級緩存呢?二級緩存能解決循環(huán)依賴嗎?

如果沒有 AOP 代理，二級緩存可以解決問題，但是有 AOP 代理的情況下，只用二級緩存就意味著所有 Bean 在實例化后就要完成 AOP 代理，這樣違背了 Spring 設(shè)計的原則，Spring 在設(shè)計之初就是通過 AnnotationAwareAspectJAutoProxyCreator 這個后置處理器來在 Bean 生命周期的最后一步來完成 AOP 代理，而不是在實例化后就立馬進行 AOP 代理。

參考與感謝：

《Spring 源碼深度解析》- 郝佳著

https://developer.aliyun.com/article/766880

http://www.tianxiaobo.com/2018/06/08/Spring-IOC-容器源碼分析-循環(huán)依賴的解決辦法

https://cloud.tencent.com/developer/article/1497692

 

https://blog.csdn.net/chaitoudaren/article/details/105060882

 

責任編輯：武曉燕 來源： JavaKeeper
Spring 循環(huán)依賴
相關(guān)推薦

2021-02-08 11:20:27

Java類型數(shù)組

2022-03-11 14:59:21

JavaScript數(shù)組字符串

2024-11-29 08:53:46

2023-12-12 08:02:10

2023-05-04 08:06:27

Spring循環(huán)依賴

2022-04-26 08:41:54

JDK動態(tài)代理方法

2022-11-09 07:20:43

調(diào)用日志502報錯nginx

2024-03-04 07:41:18

SpringAOPOOP?

2024-08-27 11:00:56

單例池緩存bean

2024-03-18 08:06:59

JavaGo開發(fā)

2023-06-05 08:36:04

SQL函數(shù)RANK()

2023-05-05 08:29:15

Spring后臺服務器

2022-07-11 09:00:37

依賴配置文件Mybati

2022-03-03 07:34:31

注解容器作用域

2023-06-27 07:21:51

前端開發(fā)坑點

2024-09-30 09:05:46

Linux網(wǎng)絡(luò)延遲

2019-11-26 14:30:20

Spring循環(huán)依賴Java

2022-07-08 09:27:48

CSSIFC模型

2024-01-02 07:04:23

2024-02-02 11:03:11

React數(shù)據(jù)Ref
點贊
收藏

51CTO技術(shù)棧公眾號