關于 Spring Boot 中建立對象的疑慮 → @Bean 與 @Component 同時作用同一個類，會怎麼樣？

開心一刻

　　今天放學回家，氣憤憤地找到我媽

　　我：媽，我們班同學都說我五官長得特别平

　　媽：你小時候愛趴着睡覺

　　我：你怎麼不把我翻過來呢

　　媽：那你不是淩晨2點時候出生的嗎

　　我：嗯，淩晨2點出生就愛趴着睡覺呗

　　爸：淩晨 2 點是醜時，醜！

　　媽：我把你翻過來，我看着你，我害怕呀

　　我内心一咯噔：敢情我不是天生的五官平呀，哎，雖不是天生，但勝似天生了

關于 Spring Boot 中建立對象的疑慮 → @Bean 與 @Component 同時作用同一個類，會怎麼樣？

疑慮背景

　　疑慮描述

　　最近，在進行開發的過程中，發現之前的一個寫法，類似如下

　　以我的了解，@Configuration 加 @Bean 會建立一個 userName 不為 null 的 UserManager 對象，而 @Component 也會建立一個 userName 為 null 的 UserManager 對象

　　那麼我們在其他對象中注入 UserManager 對象時，到底注入的是哪個對象？

　　因為項目已經上線了很長一段時間了，是以這種寫法沒有編譯報錯，運作也沒有出問題

　　後面去找同僚了解下，實際是想讓

　　生效，而實際也确實是它生效了

　　那麼問題來了： Spring 容器中到底有幾個 UserManager 類型的對象？

　　Spring Boot 版本

　　項目中用的 Spring Boot 版本是： 2.0.3.RELEASE

　　對象的 scope 是預設值，也就是 singleton

結果驗證

　　驗證方式有很多，可以 debug 跟源碼，看看 Spring 容器中到底有幾個 UserManager 對象，也可以直接從 UserManager 構造方法下手，看看哪幾個構造方法被調用，等等

　　我們從構造方法下手，看看 UserManager 到底執行個體化了幾次

　　隻有有參構造方法被調用了，無參構造方法巋然不動（根本沒被調用）

　　如果想了解的更深一點，可以讀讀鄙人的：Spring 的循環依賴，源碼詳細分析 → 真的非要三級緩存嗎

　　既然 UserManager 構造方法隻被調用了一次，那麼前面的問題：到底注入的是哪個對象

　　答案也就清晰了，沒得選了呀，隻能是 @Configuration 加 @Bean 建立的 userName 不為 null 的 UserManager 對象

　　問題又來了：為什麼不是 @Component 建立的 userName 為 null 的 UserManager 對象？

源碼解析

　　 @Configuration 與 @Component 關系很緊密

　　是以 @Configuration 能夠被 component scan

　　在spring-boot-2.0.3源碼篇 - @Configuration、Condition與@Conditional中講到了 @Configuration 的實作原理

　　其中 ConfigurationClassPostProcessor 與 @Configuration 息息相關，其類繼承結構圖如下：

　　它實作了 BeanFactoryPostProcessor 接口和 PriorityOrdered 接口，關于 BeanFactoryPostProcessor ，可以看看鄙人的Spring拓展接口之BeanFactoryPostProcessor，占位符與敏感資訊解密原理

　　那麼我們從 AbstractApplicationContext 的 refresh 方法調用的 invokeBeanFactoryPostProcessors(beanFactory) 開始，來跟下源碼

　　此時完成了 com.lee.qsl 包下的 component scan ， com.lee.qsl 包及子包下的 UserConfig 、 UserController 和 UserManager 都被掃描出來

　　注意，此刻 @Bean 的處理還未開始， UserManager 是通過 @Component 而被掃描出來的；此時 Spring 容器中 beanDefinitionMap 中的 UserManager 是這樣的

　　接下來一步很重要，與我們想要的答案息息相關

　　循環遞歸處理 UserConfig 、 UserController 和 UserManager ，把它們都封裝成 ConfigurationClass ，遞歸掃描 BeanDefinition

　　循環完之後，我們來看看 configClasses

　　 UserConfig bean 定義資訊中 beanMethods 中有一個元素 [BeanMethod:name=userManager,declaringClass=com.lee.qsl.config.UserConfig]

　　然後我們接着往下走，來仔細看看答案出現的環節

　　是不是有什麼發現？ @Component 修飾的 UserManager 定義直接被覆寫成了 @Configuration + @Bean 修飾的 UserManager 定義

　　Bean 定義類型也由 ScannedGenericBeanDefinition 替換成了 ConfigurationClassBeanDefinition

　　後續通過 BeanDefinition 建立執行個體的時候，建立的自然就是 @Configuration + @Bean 修飾的 UserManager ，也就是會反射調用 UserManager 的有參構造方法