1、Spring 如何創(chuàng)建 Bean？

    /** 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 是如何創(chuàng)建 bean 的。

2、Spring 如何解決循環(huán)依賴？

3、Spring 不能解決哪些循環(huán)依賴？

3.1 循環(huán)中使用了@Async注解

3.1.1 為什么循環(huán)中使用了@Async 會報(bào)錯(cuò)？

3.1.2 循環(huán)中使用了@Async 一定會報(bào)錯(cuò)嗎？

深層原因?yàn)椋?/span>OneBean 先被創(chuàng)建，TwoBean 后創(chuàng)建，再整條鏈路中，并未在三級緩存中查找過 TwoBean 的 objectFactory 。（OneBean 在創(chuàng)建過程中，被找過兩次，即 one-> two ->one；TwoBean 的創(chuàng)建過程中，只找過它一次，即 two ->one。)由此可得：@Async 造成循環(huán)依賴報(bào)錯(cuò)的先約條件為：1.循環(huán)依賴中的 Bean 使用了 @Async 注解2.且這個(gè) Bean，比循環(huán)內(nèi)其他 Bean 先創(chuàng)建。3.注：一個(gè) Bean 可能會同時(shí)存在于多個(gè)循環(huán)內(nèi)；只要存在它是某個(gè)循環(huán)內(nèi)第一個(gè)被創(chuàng)建的 Bean，那么就會報(bào)錯(cuò)。

3.1.3 為什么循環(huán)中使用了 @Transactional 不會報(bào)錯(cuò)？

已知使用了 @Transactional 注解的 Bean，Spring 也會為其生成代理對象，但為什么這種 Bean 在循環(huán)里時(shí)不會產(chǎn)生報(bào)錯(cuò)呢？以 com.gyh.circular.transactional 包下的 OneBean 和 TwoBean 為例，兩個(gè) Bean 相互依賴，且 OneBean 中的方法使用了 @Transactional 注解，啟動 Spring 成功，并不會報(bào)錯(cuò)。debug 代碼可知，生成 OneBean 過程中，雖然 earlySingletonReference != null，但 initializeBean 之后的 exposedObject 和 原始實(shí)例的地址相同（即 initializeBean 步驟中，并未對實(shí)例生成代理），所以不會產(chǎn)生報(bào)錯(cuò)。3.1.4 為什么同樣是代理會產(chǎn)生兩種不同的現(xiàn)象？同樣是生成代理對象，同樣是參與到循環(huán)依賴中，會產(chǎn)生不同現(xiàn)象的原因是：當(dāng)他們處在循環(huán)依賴中時(shí)，生成代理的節(jié)點(diǎn)不同：1.@Transactional 在 getEarlyBeanReference 時(shí)生成代理，提前暴露出代理之后的地址（即最終地址）；2.@Async 在 initializeBean 時(shí)生成代理，導(dǎo)致提前暴露出去的地址不是最終地址，造成報(bào)錯(cuò)。為什么 @Async 不能在 getEarlyBeanReference 時(shí)生成代理呢？對比下兩者執(zhí)行的代碼過程發(fā)現(xiàn)：兩者都是在 AbstractAutoProxyCreator#getEarlyBeanReference 的方法對原始實(shí)例對象進(jìn)行包裝，如下圖使用 @Transactional 的 Bean 在 create proxy 時(shí)，獲取到一個(gè) advice ，隨即生成了代理對象 proxy.?而使用 @Async 的 Bean 在 create proxy 時(shí)，沒有獲取到 advice，不能被代理.

3.1.5 為什么 @Async 在 getEarlyBeanReference 時(shí)不能返回一個(gè) advice？

在 AbstractAutoProxyCreator#getAdvicesAndAdvisorsForBean 方法內(nèi)，其主要做的事情有：1.找到當(dāng)前 spring 容器中所有的 Advisor2.返回適配當(dāng)前 bean 的所有 Advisor第一步返回的 Advisor 有 BeanFactoryCacheOperationSourceAdvisor 和 BeanFactoryTransactionAttributeSourceAdvisor，并無處理 Async 相關(guān)的 Advisor.刨根問底，追查為什么第一步不會返回處理 Async 相關(guān)的 Advisor？已知使用 @Async @Transactional @Cacheable 需要提前進(jìn)行開啟，即提前標(biāo)注 @EnableAsync、@EnableTransactionManagement、@EnableCaching 。以 @EnableTransactionManagement、@EnableCaching 為例，在其注解定義中，引入了 Selector 類，Selector 中又引入了 Configuration 類，在 Configuration 類中，創(chuàng)建了對應(yīng) Advisor 并放到了 spring 容器中，所以第一步才能得到這兩個(gè) Advisor.而 @EnableAsync 的定義中引入的 Configuration 類，創(chuàng)建的是 AsyncAnnotationBeanPostProcessor 并非一個(gè) Advisor，所以第一步不會得到它，所以 @Async 的 bean 不會在這一步被代理。

3.2 構(gòu)造函數(shù)引起的循環(huán)依賴

以 com.gyh.circular.constructor 包下的 OneBean 和 TwoBean 為例，兩個(gè)類的構(gòu)造函數(shù)中各自依賴對方，啟動 spring，報(bào)錯(cuò)：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 代碼可知，兩個(gè) bean 在根據(jù)構(gòu)造函數(shù) new instance 時(shí)，就已經(jīng)陷入的死循環(huán)，無法提前暴露可用的地址，所以只能報(bào)錯(cuò)。

4、如何解決以上循環(huán)依賴報(bào)錯(cuò)？

1.不用 @Async，將需要異步操作的方法，放到線程池中執(zhí)行。（推薦）2.提出 @Async 標(biāo)注的方法。（推薦）3.將使用 @Async 的方法提出到單獨(dú)的類中，該類只做異步處理，不做其他業(yè)務(wù)依賴，即避免形成循環(huán)依賴，從而解決報(bào)錯(cuò)問題。參考 com.gyh.circular.async.extract 包。4.盡量不使用構(gòu)造函數(shù)依賴對象。（推薦）5.破壞循環(huán)（不推薦）即不形成閉環(huán)，在開發(fā)之前，規(guī)劃好對象依賴，方法調(diào)用鏈，盡量做到不使用循環(huán)依賴。（較難，隨著迭代開發(fā)不斷變化，很可能產(chǎn)生循環(huán)）6.破壞創(chuàng)建順序（不推薦）7.由于使用 @Async 注解的所在類，比循環(huán)依賴內(nèi)其他類先創(chuàng)建時(shí)才會報(bào)錯(cuò)，那么想辦法使該類不先于其他類先創(chuàng)建，也可解決該問題，如：@DependsOn、@Lazy

審核編輯 ：李倩