扯一把 Spring 的三種注入方式，到底哪種注入方式好呢？
循環依賴這個問題，按理說我們在日常的程序設計中應該避免，其實這個本來也是能夠避免的。不過由于總總原因，我們可能還是會遇到一些循環依賴的問題，特別是在面試的過程中，面試考察循環依賴，主要是想考察候選人對 Spring 源碼的熟悉程度，因為要把循環依賴這個問題解釋清楚，涉及到不少 Spring 源碼。
今天松哥抽空和大家簡單聊聊這個話題，問題比較龐大，我可能花幾篇文章來和大家分享下，今天先來聊聊實例的注入方式。
1. 實例的注入方式
首先來看看 Spring 中的實例該如何注入，總結起來，無非三種：
- 屬性注入
- set 方法注入
- 構造方法注入
我們分別來看下。
1.1 屬性注入
屬性注入是大家最為常見也是使用最多的一種注入方式了，代碼如下：
- @Service
- public class BService {
- @Autowired
- AService aService;
- //...
- }
這里是使用 @Autowired 注解注入。另外也有 @Resource 以及 @Inject 等注解，都可以實現注入。
不過不知道小伙伴們有沒有留意過，在 IDEA 里邊，使用屬性注入，會有一個警告??：
不推薦屬性注入!
原因我們后面討論。
1.2 set 方法注入
set 方法注入太過于臃腫，實際上很少使用：
- @Service
- public class BService {
- AService aService;
- @Autowired
- public void setaService(AService aService) {
- this.aService = aService;
- }
- }
這代碼看一眼都覺得難受，堅決不用。
1.3 構造方法注入
構造方法注入方式如下：
- @Service
- public class AService {
- BService bService;
- @Autowired
- public AService(BService bService) {
- this.bService = bService;
- }
- }
如果類只有一個構造方法，那么 @Autowired 注解可以省略;如果類中有多個構造方法，那么需要添加上 @Autowired 來明確指定到底使用哪個構造方法。
2. 實例注入方式大 PK
上面給大家列出來了三種注入方式，那么三種注入方式各自有何區別呢?
結合 Spring 官方文檔，我們來分析下。
松哥翻出了 12 年前的 Spring3.0 的文檔(https://docs.spring.io/spring-framework/docs/3.0.x/reference/beans.html)，里邊有如下一段話：
我來簡單翻譯下(意譯)：
使用構造方法注入還是使用 set 方法注入?由于構造方法注入和 set 方法注入可以混合使用，因此，如果需要強制注入，我們可以使用構造方法注入的方式;如果是可選注入，則我們可以使用 set 方法注入的方式。當然，我們在 setter 上使用 @Required 注解可以讓 set 方法注入也變為強制性注入。Spring 團隊通常提倡 setter 注入，因為當屬性特別多的時候，構造方法看起來會特別臃腫，特別是當屬性是可選的時(屬性可選意味著沒必要通過構造方法注入)。Setter 方法注入還有一個好處就是可以使該類的屬性可以在以后重新配置或重新注入。一些純粹主義者喜歡基于構造函數的注入，這樣意味著所有的屬性都被初始化了，缺點則是對象變得不太適合重新配置和重新注入。另外在一些特殊的場景下，如一個第三方類要注入到 Spring 容器，但是該類沒有提供 set 方法，那么此時你就只能使用構造方法注入了。
英文水平有限，大概翻譯了下。小伙伴們重點看加粗部分，也就是說在 Spring3.0 時代，官方還是提倡 set 方法注入的。
不過從 Spring4.x 開始，官方就不推薦這種注入方式了，轉而推薦構造器注入。
我們來看看 Spring4.x 的文檔怎么說(https://docs.spring.io/spring-framework/docs/4.0.x/spring-framework-reference/htmlsingle/#beans-setter-injection)：
這段內容我就不一一翻譯了，大家重點看第二段第一句：
The Spring team generally advocates constructor injection
這句話就是說 Spring 團隊倡導通過構造方法完成注入。才一個大版本更新，Spring 咋就變了呢?別急，人家也給出用構造方法注入的理由，第二段翻譯一下大概是這個意思：
通過構造方法注入的方式，能夠保證注入的組件不可變，并且能夠確保需要的依賴不為空。此外，構造方法注入的依賴總是能夠在返回客戶端(組件)代碼的時候保證完全初始化的狀態。
上面這段話主要說了三件事：
- 依賴不可變：這個好理解，通過構造方法注入依賴，在對象創建的時候就要注入依賴，一旦對象創建成功，以后就只能使用注入的依賴而無法修改了，這就是依賴不可變(通過 set 方法注入將來還能通過 set 方法修改)。
- 依賴不為空：通過構造方法注入的時候，會自動檢查注入的對象是否為空，如果為空，則注入失敗;如果不為空，才會注入成功。
- 完全初始化：由于獲取到了依賴對象(這個依賴對象是初始化之后的)，并且調用了要初始化組件的構造方法，因此最終拿到的就是完全初始化的對象了。
在 Spring3.0 文檔中，官方說如果構造方法注入的話，屬性太多可能會讓代碼變得非常臃腫，那么在 4.0 文檔中，官方對這個說法也做了一些訂正：如果用構造方法注入的時候，參數過多以至于代碼過于臃腫，那么此時你需要考慮這個類的設計是否合理，這個類是否參雜了太多的其他無關功能，這個類是否做到了單一職責。
好吧，你說的總是有理!
這是構造方法注入和 set 方法注入的問題，那么上面我們還提到不推薦屬性注入，這又是咋回事呢?
屬性注入其實有一個顯而易見的缺點，那就是對于 IOC 容器以外的環境，除了使用反射來提供它需要的依賴之外，無法復用該實現類。因為該類沒有提供該屬性的 set 方法或者相應的構造方法來完成該屬性的初始化。換言之，要是使用屬性注入，那么你這個類就只能在 IOC 容器中使用，要是想自己 new 一下這個類的對象，那么相關的依賴無法完成注入。
以上分析都是根據 Spring 官方文檔得來，日常開發應該還是屬性注入較多，這個咱們不必糾結，代碼該咋寫還咋寫，Spring 官方的態度了解一下即可，當然，如果項目允許，也不妨試試 Spring 推薦的代碼規范。
3. 小結
好啦，今天就和小伙伴們隨便扯扯 Spring 中的注入方式，因為我最近又要重新撿起 Spring 源碼分析了，所以先來個簡單的預熱一下哈哈～
