作者：郭豔紅

以下舉例皆針對單例模式討論

圖解參考 https://www.processon.com/view/link/60e3b0ae0e3e74200e2478ce

1、Spring 如何建立Bean？

對於單例Bean來說，在Spring容器整個生命週期內，有且只有一個物件。

Spring 在建立 Bean 過程中，使用到了三級快取，即 DefaultSingletonBeanRegistry.java 中定義的：

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

以 com.gyh.general 包下的 OneBean 為例，debug springboot 啟動過程，分析spring是如何建立bean的。

參考圖中 spring建立bean 的過程。其中最關鍵的幾步有：

1.getSingleton(beanName, true) 依次從一二三級快取中查詢bean物件，如果快取中存在物件，則直接返回(early)；

2.createBeanInstance(beanName, mbd, args) 選一個合適的建構函式，new範例物件(instance)，此時的instance中依賴的屬性還都是null，屬於半成品；

3.singletonFactories.put(beanName, oneSingletonFactory) 利用上一步的instance，構建一個 singletonFactory，並將其放到三級快取中；

4.populateBean(beanName, mbd, instanceWrapper) 填充bean：為該bean定義的屬性建立物件或賦值；

5.initializeBean("one",oneInstance, mbd) 初始化bean：對bean進行初始化或其他加工，如生成代理物件(proxy)；

6.getSingleton(beanName, false) 依次在一二級快取中查詢，檢查是否有因迴圈依賴導致提前生成的物件，有的話與初始化後的物件是否一致；

2、Spring 如何解決迴圈依賴？

以 com.gyh.circular.threeCache 包下的 OneBean 和 TwoBean 為例 ，兩個 Bean 相互依賴（即形成閉環）。

參考圖中 spring解決迴圈依賴 的過程可知，spring利用三級緩中的 objectFactory 生成並返回一個 early 物件，提前暴露這個 early 地址，供其他物件依賴注入使用，以此解決迴圈依賴問題。

3、Spring 不能解決哪些迴圈依賴？

3.1 迴圈中使用了 @Async 註解

3.1.1 為什麼迴圈中使用了 @Async 會報錯？

以 com.gyh.circular.async 包下的 OneBean 和 TwoBean 為例，兩個bean相互依賴，且oneBean中的方法使用了 @Async 註解，此時啟動spring失敗，報錯資訊為：org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a.one': Bean with name 'a.one' has been injected into other beans [a.two] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

並通過debug程式碼，發現報錯位置在 AbstractAutowireCapableBeanFactory#doCreateBean 方法內，由於 earlySingletonReference != null 且 exposedObject != bean，導致報錯。

結合流程圖中 spring解決迴圈依賴 及上述圖片中可知：

1.行1中 bean 為 createBeanInstance 建立的範例(address1)

2.行2中 exposedObject 為 initializeBean 後生成的代理物件(address2)

3.行3中 earlySingletonReference 為 getEarlyBeanReference 時建立的物件【此處地址同bean(address1)】

深層原因為：先前 TwoBean 在 populateBean 時已經依賴了地址為 address1 的 earlySingletonReference 物件，而此時 OneBean 經過 initializeBean 之後，返回了地址為 address2 的新物件，導致spring不知道哪個才是最終版的bean，所以報錯。

earlySingletonReference 是如何生成的，參考getSingleton("one", true)過程。

3.1.2 迴圈中使用了 @Async 一定會報錯嗎？

依然以 com.gyh.circular.async 包下的 OneBean 和 TwoBean 為例，兩個bean相互依賴，使 TwoBean(非OneBean)中的方法使用了 @Async 註解，此時啟動spring成功，並未報錯。

debug程式碼可知：雖然TwoBean 使用了 @Async 註解，但其 earlySingletonReference = null; 故不會引起報錯。

深層原因為：OneBean 先被建立，TwoBean 後建立，再整條鏈路中，並未在三級快取中查詢過 TwoBean 的 objectFactory 。（OneBean在建立過程中，被找過兩次，即 one-> two ->one；TwoBean 的建立過程中，只找過它一次，即 two ->one。)

由此可得：@Async 造成迴圈依賴報錯的先約條件為：

1.迴圈依賴中的 Bean 使用了 @Async 註解

2.且這個 Bean，比迴圈內其他 Bean 先建立。

3.注：一個Bean可能會同時存在於多個迴圈內；只要存在它是某個迴圈內第一個被建立的Bean，那麼就會報錯。

3.1.3 為什麼迴圈中使用了 @Transactional 不會報錯？

已知使用了 @Transactional 註解的 Bean，Spring 也會為其生成代理物件，但為什麼這種 Bean 在迴圈裡時不會產生報錯呢？

以 com.gyh.circular.transactional 包下的 OneBean 和 TwoBean 為例，兩個 Bean 相互依賴，且 OneBean 中的方法使用了 @Transactional 註解，啟動Spring成功，並不會報錯。

debug 程式碼可知，生成 OneBean 過程中，雖然 earlySingletonReference != null，但 initializeBean 之後的 exposedObject 和 原始範例的地址相同（即 initializeBean 步驟中，並未對範例生成代理），所以不會產生報錯。

3.1.4 為什麼同樣是代理會產生兩種不同的現象？

同樣是生成代理物件，同樣是參與到迴圈依賴中，會產生不同現象的原因是：當他們處在迴圈依賴中時，生成代理的節點不同：

1.@Transactional 在 getEarlyBeanReference 時生成代理，提前暴露出代理之後的地址（即最終地址）；

2.@Async 在 initializeBean 時生成代理，導致提前暴露出去的地址不是最終地址，造成報錯。

為什麼 @Async 不能在 getEarlyBeanReference 時生成代理呢？對比下兩者執行的程式碼過程發現：

兩者都是在 AbstractAutoProxyCreator#getEarlyBeanReference 的方法對原始範例物件進行包裝，如下圖

使用 @Transactional 的Bean 在 create proxy 時，獲取到一個advice ，隨即生成了代理物件 proxy.

而使用 @Async 的Bean 在 create proxy 時，沒有獲取到 advice，不能被代理.

3.1.5 為什麼@Async 在 getEarlyBeanReference 時不能返回一個 advice？

在 AbstractAutoProxyCreator#getAdvicesAndAdvisorsForBean 方法內，其主要做的事情有：

1.找到當前 spring 容器中所有的 Advisor

2.返回適配當前 bean 的所有 Advisor

第一步返回的 Advisor 有 BeanFactoryCacheOperationSourceAdvisor 和 BeanFactoryTransactionAttributeSourceAdvisor，並無處理 Async 相關的 Advisor.

刨根問底，追查為什麼第一步不會返回處理 Async 相關的 Advisor？

已知使用 @Async @Transactional @Cacheable 需要提前進行開啟，即提前標註 @EnableAsync、@EnableTransactionManagement、@EnableCaching 。

以 @EnableTransactionManagement、@EnableCaching 為例，在其註解定義中，引入了Selector類，Selector中又引入了Configuration 類，在 Configuration 類中，建立了對應 Advisor 並放到了 spring容器中，所以第一步才能得到這兩個 Advisor.

而 @EnableAsync的定義中引入的 Configuration 類，建立的是 AsyncAnnotationBeanPostProcessor 並非一個 Advisor，所以第一步不會得到它，所以 @Async 的 bean 不會在這一步被代理。

3.2 建構函式引起的迴圈依賴

以 com.gyh.circular.constructor 包下的 OneBean 和 TwoBean 為例，兩個類別建構函式中各自依賴對方，啟動spring，報錯：org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'c.one': Requested bean is currently in creation: Is there an unresolvable circular reference?

debug 程式碼可知，兩個bean在根據建構函式 new instance 時，就已經陷入的死迴圈，無法提前暴露可用的地址，所以只能報錯。

4、如何解決以上回圈依賴報錯？

1.不用 @Async，將需要非同步操作的方法，放到執行緒池中執行。（推薦）

2.提出 @Async 標註的方法。（推薦）

3.將使用 @Async 的方法提出到單獨的類中，該類只做非同步處理，不做其他業務依賴，即避免形成迴圈依賴，從而解決報錯問題。參考 com.gyh.circular.async.extract 包。

4.儘量不使用建構函式依賴物件。（推薦）

5.破壞迴圈（不推薦）即不形成閉環，在開發之前，規劃好物件依賴，方法呼叫鏈，儘量做到不使用迴圈依賴。（較難，隨著迭代開發不斷變化，很可能產生迴圈）

6.破壞建立順序（不推薦）

7.由於使用 @Async 註解的所在類，比迴圈依賴內其他類先建立時才會報錯，那麼想辦法使該類不先於其他類先建立，也可解決該問題，如：@DependsOn、 @Lazy