造器、Setter與字段注入對(duì)比)
1. 項(xiàng)目概述為什么依賴注入是Spring的基石如果你剛開始接觸Spring框架可能會(huì)被各種注解和配置搞得暈頭轉(zhuǎn)向。但無論你學(xué)到哪個(gè)階段依賴注入這個(gè)概念絕對(duì)是繞不開的核心。它不是什么高深莫測(cè)的黑魔法而是一種讓代碼變得更清晰、更靈活、更容易測(cè)試的設(shè)計(jì)思想。簡(jiǎn)單來說它就是把對(duì)象之間的依賴關(guān)系從代碼內(nèi)部“硬編碼”的方式轉(zhuǎn)變?yōu)橛赏獠咳萜鱽砉芾砗汀白⑷搿钡倪^程。想象一下你是一個(gè)汽車設(shè)計(jì)師。傳統(tǒng)方式下你設(shè)計(jì)發(fā)動(dòng)機(jī)時(shí)必須同時(shí)設(shè)計(jì)好與之匹配的特定型號(hào)的輪胎和方向盤它們被牢牢焊死在一起。而采用依賴注入思想后你只需要設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)的發(fā)動(dòng)機(jī)接口至于裝什么牌子的輪胎、什么款式的方向盤可以在汽車總裝線上也就是Spring容器里靈活配置。這樣做的好處顯而易見發(fā)動(dòng)機(jī)模塊可以獨(dú)立測(cè)試和升級(jí)更換輪胎品牌也無需改動(dòng)發(fā)動(dòng)機(jī)的代碼。Spring框架的核心容器ApplicationContext就是這個(gè)“總裝線”。它負(fù)責(zé)創(chuàng)建對(duì)象Bean并管理它們之間的依賴關(guān)系。理解依賴注入的幾種實(shí)現(xiàn)方式就是理解Spring如何“裝配”你的應(yīng)用。今天我們就來徹底拆解Spring中實(shí)現(xiàn)依賴注入的三種主流方式構(gòu)造器注入、Setter方法注入和字段注入。我會(huì)結(jié)合實(shí)例詳細(xì)分析它們各自的寫法、適用場(chǎng)景、背后的設(shè)計(jì)考量以及在實(shí)際開發(fā)中我踩過的那些坑。2. 依賴注入的三種方式深度解析依賴注入的本質(zhì)是“將依賴傳遞給依賴者”而非由依賴者自己創(chuàng)建或查找依賴。Spring提供了多種途徑來實(shí)現(xiàn)這一過程每種方式都有其鮮明的特點(diǎn)和最佳實(shí)踐場(chǎng)景。理解它們的差異是寫出高質(zhì)量Spring代碼的關(guān)鍵一步。2.1 構(gòu)造器注入強(qiáng)依賴與不可變性的首選構(gòu)造器注入顧名思義就是通過類的構(gòu)造方法來注入依賴。這是Spring團(tuán)隊(duì)自Spring 4.x版本以來官方推薦的首選方式尤其是在Spring Boot應(yīng)用中幾乎成為默認(rèn)規(guī)范。它的核心思想是一個(gè)對(duì)象在創(chuàng)建時(shí)就必須具備其運(yùn)行所需的全部必要依賴。這保證了Bean在初始化完成后就處于一個(gè)完整、可用的狀態(tài)。2.1.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼假設(shè)我們有一個(gè)OrderService訂單服務(wù)它強(qiáng)依賴于PaymentService支付服務(wù)和InventoryService庫存服務(wù)。沒有這兩個(gè)服務(wù)訂單服務(wù)根本無法正常工作。使用構(gòu)造器注入的代碼如下// PaymentService 接口及其實(shí)現(xiàn) public interface PaymentService { boolean processPayment(Order order); } Service public class AlipayPaymentService implements PaymentService { Override public boolean processPayment(Order order) { // 支付寶支付邏輯 System.out.println(Processing payment via Alipay for order: order.getId()); return true; } } // InventoryService 接口及其實(shí)現(xiàn) public interface InventoryService { boolean checkStock(String productId, int quantity); } Service public class DefaultInventoryService implements InventoryService { Override public boolean checkStock(String productId, int quantity) { // 檢查庫存邏輯 System.out.println(Checking stock for product: productId); return quantity 100; // 模擬庫存充足 } } // 使用構(gòu)造器注入的 OrderService Service public class OrderService { // 聲明為 final確保依賴不可變 private final PaymentService paymentService; private final InventoryService inventoryService; // 構(gòu)造器Spring容器會(huì)在這里注入依賴 Autowired // 在Spring 4.3 及單個(gè)構(gòu)造器情況下此注解可省略 public OrderService(PaymentService paymentService, InventoryService inventoryService) { this.paymentService paymentService; this.inventoryService inventoryService; } public void placeOrder(Order order) { // 業(yè)務(wù)邏輯先檢查庫存再處理支付 if (inventoryService.checkStock(order.getProductId(), order.getQuantity())) { if (paymentService.processPayment(order)) { System.out.println(Order placed successfully!); } } } }在上面的代碼中OrderService的依賴paymentService,inventoryService通過構(gòu)造器參數(shù)傳入并被賦值給final字段。這意味著一旦OrderService實(shí)例被創(chuàng)建這些依賴就不能再被改變。2.1.2 設(shè)計(jì)優(yōu)勢(shì)與背后的考量不可變性Immutability將依賴字段聲明為final保證了Bean在生命周期內(nèi)依賴不變。這是函數(shù)式編程和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD中推崇的理念能有效避免因依賴在運(yùn)行時(shí)被意外替換而導(dǎo)致的詭異Bug。完全初始化的狀態(tài)對(duì)象在構(gòu)造完成后就立即可用不存在“半成品”狀態(tài)。這簡(jiǎn)化了對(duì)象狀態(tài)的管理也使得代碼邏輯更易于推理。便于測(cè)試在單元測(cè)試中你可以直接通過new關(guān)鍵字創(chuàng)建被測(cè)對(duì)象并傳入Mock依賴如使用Mockito無需借助Spring容器或特殊的測(cè)試框架設(shè)置測(cè)試代碼非常干凈。Test void testPlaceOrder_Success() { // 創(chuàng)建Mock對(duì)象 PaymentService mockPaymentService mock(PaymentService.class); InventoryService mockInventoryService mock(InventoryService.class); // 設(shè)置Mock行為 when(mockInventoryService.checkStock(anyString(), anyInt())).thenReturn(true); when(mockPaymentService.processPayment(any(Order.class))).thenReturn(true); // 直接通過構(gòu)造器注入依賴進(jìn)行測(cè)試 OrderService orderService new OrderService(mockPaymentService, mockInventoryService); Order testOrder new Order(123, product_1, 2); orderService.placeOrder(testOrder); // 驗(yàn)證交互 verify(mockPaymentService).processPayment(testOrder); }避免循環(huán)依賴Spring容器在解決構(gòu)造器注入的循環(huán)依賴時(shí)會(huì)直接拋出BeanCurrentlyInCreationException。這迫使開發(fā)者重新審視設(shè)計(jì)從根本上解決不良的循環(huán)依賴從而得到更清晰、更松耦合的架構(gòu)。相比之下Setter注入可以“掩蓋”循環(huán)依賴問題但會(huì)帶來潛在的運(yùn)行時(shí)風(fēng)險(xiǎn)。2.1.3 注意事項(xiàng)與實(shí)操心得當(dāng)依賴較多時(shí)如果一個(gè)類的構(gòu)造器參數(shù)超過7個(gè)這是一個(gè)常見的經(jīng)驗(yàn)閾值可能意味著這個(gè)類承擔(dān)了過多的職責(zé)違反了單一職責(zé)原則。這時(shí)應(yīng)該考慮是否可以通過拆分類、引入?yún)?shù)對(duì)象DTO或使用建造者模式來重構(gòu)。Autowired注解在Spring 4.3及以上版本如果一個(gè)類只定義了一個(gè)構(gòu)造器那么Spring會(huì)自動(dòng)將這個(gè)構(gòu)造器用于依賴注入Autowired注解可以省略。如果有多個(gè)構(gòu)造器則必須在你希望Spring使用的那個(gè)構(gòu)造器上標(biāo)注Autowired。與Bean配置結(jié)合在Java配置類Configuration中定義Bean時(shí)構(gòu)造器注入同樣適用且非常直觀。Configuration public class AppConfig { Bean public OrderService orderService(PaymentService paymentService, InventoryService inventoryService) { // 這里的方法參數(shù)就是由Spring自動(dòng)注入的 return new OrderService(paymentService, inventoryService); } }2.2 Setter方法注入可選依賴與動(dòng)態(tài)配置的利器Setter方法注入通過類的Setter方法來完成依賴的注入。這種方式在Spring早期版本和某些特定場(chǎng)景下非常流行。它的核心特點(diǎn)是注入發(fā)生在對(duì)象構(gòu)造之后依賴是可變的。2.2.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼考慮一個(gè)NotificationService通知服務(wù)它可以通過郵件、短信等多種渠道發(fā)送通知。這些渠道對(duì)于服務(wù)核心功能可能是可選的或可動(dòng)態(tài)切換的。public interface NotificationChannel { void send(String message, String target); } Service public class EmailChannel implements NotificationChannel { Override public void send(String message, String target) { System.out.println(Sending Email to target : message); } } Service public class SmsChannel implements NotificationChannel { Override public void send(String message, String target) { System.out.println(Sending SMS to target : message); } } // 使用Setter注入的 NotificationService Service public class NotificationService { // 依賴不是final的 private NotificationChannel primaryChannel; private ListNotificationChannel allChannels; // Setter方法Spring容器會(huì)調(diào)用它們進(jìn)行注入 Autowired Qualifier(emailChannel) // 使用Qualifier指定注入哪個(gè)Bean public void setPrimaryChannel(NotificationChannel channel) { this.primaryChannel channel; } Autowired // 可以注入集合 public void setAllChannels(ListNotificationChannel channels) { this.allChannels channels; } public void notifyUser(String message, String user) { if (primaryChannel ! null) { primaryChannel.send(message, user); } // 也可以廣播到所有渠道 // allChannels.forEach(channel - channel.send(message, user)); } }2.2.2 設(shè)計(jì)優(yōu)勢(shì)與適用場(chǎng)景可選依賴對(duì)于非強(qiáng)制性的依賴Setter注入非常合適。對(duì)象可以在沒有這些依賴的情況下被創(chuàng)建后續(xù)再按需注入。在上例中NotificationService即使沒有設(shè)置primaryChannel它本身也可能具備一些其他功能比如消息格式化只是通知功能不可用。動(dòng)態(tài)重新配置由于依賴不是final的理論上可以在運(yùn)行時(shí)通過調(diào)用Setter方法更換依賴的實(shí)現(xiàn)。這在需要熱更新或動(dòng)態(tài)策略切換的場(chǎng)景下有一定價(jià)值但實(shí)踐中需謹(jǐn)慎處理線程安全問題。解決特定循環(huán)依賴Spring容器處理Bean生命周期時(shí)對(duì)于Setter注入的循環(huán)依賴可以通過“提前暴露對(duì)象引用”的機(jī)制來解決三級(jí)緩存。但這應(yīng)被視為一種迫不得已的解決方案而非設(shè)計(jì)目標(biāo)。與傳統(tǒng)的JavaBean規(guī)范兼容許多老舊的庫或框架遵循JavaBean規(guī)范依賴Setter/Getter方法。在這些場(chǎng)景下Setter注入是自然的選擇。2.2.3 注意事項(xiàng)與常見陷阱對(duì)象狀態(tài)的不一致性這是Setter注入最大的風(fēng)險(xiǎn)。由于依賴可以在對(duì)象創(chuàng)建后的任何時(shí)刻被注入或更改對(duì)象可能在一段時(shí)間內(nèi)處于依賴不全的“部分初始化”狀態(tài)。如果其他線程或組件在此期間調(diào)用了該對(duì)象的方法可能導(dǎo)致NullPointerException或其他未定義行為。破壞了不變性依賴可變使得對(duì)象的線程安全性更難以保證也增加了狀態(tài)管理的復(fù)雜度。容易過度使用因?yàn)閷懛ê?jiǎn)單只需一個(gè)Autowired注解在Setter上開發(fā)者容易將所有依賴都通過Setter注入忽略了構(gòu)造器注入在保證完整性和不可變性上的優(yōu)勢(shì)。Autowired的必要性與構(gòu)造器注入不同Setter方法上的Autowired注解通常不能省略除非你在XML配置中顯式配置了property標(biāo)簽。注意在現(xiàn)代Spring應(yīng)用開發(fā)中特別是基于Spring Boot的項(xiàng)目構(gòu)造器注入已成為絕對(duì)的主流和最佳實(shí)踐。Setter注入應(yīng)被限制在“真正的可選依賴”或“必須與JavaBean規(guī)范兼容”的少數(shù)場(chǎng)景中。2.3 字段注入簡(jiǎn)潔背后的隱患與爭(zhēng)議字段注入是三種方式中語法最簡(jiǎn)潔的直接在字段上添加Autowired注解Spring容器會(huì)通過反射機(jī)制直接將依賴注入到字段中無需編寫構(gòu)造器或Setter方法。2.3.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼Service public class ReportService { // 字段注入簡(jiǎn)潔但問題也多 Autowired private DataProcessor dataProcessor; Autowired private Formatter formatter; public String generateReport() { Object data dataProcessor.process(); return formatter.format(data); } }從代碼行數(shù)上看這無疑是最省事的。它隱藏了依賴的注入細(xì)節(jié)讓業(yè)務(wù)類看起來非常“干凈”。2.3.2 為什么它備受爭(zhēng)議主要缺點(diǎn)分析破壞了封裝性依賴注入本應(yīng)是一個(gè)從外部管理依賴的“接口”構(gòu)造器或Setter方法。字段注入繞過了這個(gè)接口直接通過反射修改私有字段違反了面向?qū)ο蟮幕痉庋b原則。這使得類的依賴關(guān)系對(duì)外部完全不可見僅通過查看類的公共API無法知道它需要哪些依賴才能正常工作。導(dǎo)致對(duì)Spring容器的高度耦合因?yàn)橐蕾囎⑷胧峭ㄟ^Spring特有的Autowired注解完成的你的類無法脫離Spring容器或至少是它的依賴注入框架進(jìn)行實(shí)例化。這嚴(yán)重影響了代碼的可移植性和單元測(cè)試的純粹性。雖然可以通過Autowired的requiredfalse來模擬可選依賴但這使得測(cè)試設(shè)置更加晦澀。不變性無法保障字段不能被聲明為final因?yàn)镾pring需要在對(duì)象構(gòu)造后通過反射來設(shè)置值因此無法享受不可變性帶來的線程安全和狀態(tài)清晰的好處。依賴檢查滯后對(duì)于構(gòu)造器注入如果Spring容器找不到某個(gè)必需的依賴Bean在應(yīng)用啟動(dòng)時(shí)就會(huì)立即失敗快速發(fā)現(xiàn)問題。對(duì)于字段注入如果requiredtrue默認(rèn)值且依賴不存在啟動(dòng)也會(huì)失敗。但更隱蔽的問題是如果因?yàn)榕渲缅e(cuò)誤導(dǎo)致某些Bean在某些情況下未被創(chuàng)建而字段注入的required又被設(shè)為false那么直到運(yùn)行時(shí)調(diào)用該字段的方法時(shí)才會(huì)拋出NullPointerException增加了調(diào)試難度。不利于單一職責(zé)原則的遵循由于添加依賴的成本極低只需加一個(gè)字段和注解很容易誘使開發(fā)者在一個(gè)類中注入過多的依賴導(dǎo)致類變得臃腫職責(zé)模糊。2.3.3 遺留代碼與特定場(chǎng)景盡管有諸多缺點(diǎn)字段注入在現(xiàn)實(shí)中仍然大量存在主要原因是歷史遺留代碼和某些框架的集成。在一些古老的Spring XML配置遷移過來的項(xiàng)目中或者某些與特定框架如JPA的PersistenceContext深度集成的場(chǎng)景字段注入可能是最方便或唯一的選擇。然而對(duì)于新的項(xiàng)目或新的代碼強(qiáng)烈建議避免使用字段注入。Spring官方文檔和眾多社區(qū)專家包括Spring框架的聯(lián)合創(chuàng)始人Juergen Hoeller都已明確表示構(gòu)造器注入是更可取的方桉。3. 三種方式的對(duì)比與選型指南理解了每種方式的原理和特點(diǎn)后我們需要一個(gè)清晰的決策框架來指導(dǎo)實(shí)際開發(fā)中的選擇。下面的表格從多個(gè)維度對(duì)三者進(jìn)行了對(duì)比特性維度構(gòu)造器注入Setter方法注入字段注入不可變性支持可聲明final字段不支持不支持對(duì)象完全初始化是構(gòu)造后立即可用否存在中間狀態(tài)否存在中間狀態(tài)循環(huán)依賴處理Spring會(huì)直接拋出異常迫使改進(jìn)設(shè)計(jì)Spring可通過三級(jí)緩存機(jī)制解決同Setter注入與容器耦合度低。類可通過new創(chuàng)建便于獨(dú)立測(cè)試。中。需要Setter方法但測(cè)試時(shí)可調(diào)用。高。嚴(yán)重依賴Spring反射機(jī)制。代碼簡(jiǎn)潔性中。需顯式編寫構(gòu)造器。中。需編寫Setter方法。高。僅需一個(gè)注解。封裝性好。依賴通過公共API構(gòu)造器明確聲明。好。依賴通過公共APISetter聲明。差。依賴私有化破壞封裝。適用場(chǎng)景強(qiáng)依賴、必需依賴首選可選依賴、需動(dòng)態(tài)變更的依賴、遺留JavaBean不推薦用于新代碼僅限遺留兼容測(cè)試便利性極佳?？芍苯觧ew對(duì)象并傳入mock。佳。創(chuàng)建對(duì)象后可通過setter注入mock。差。需借助反射或Spring測(cè)試上下文。Spring官方推薦強(qiáng)烈推薦自Spring 4.3起特定場(chǎng)景下使用不推薦選型決策流程建議默認(rèn)選擇構(gòu)造器注入對(duì)于絕大多數(shù)情況尤其是那些構(gòu)成類核心功能的強(qiáng)依賴毫不猶豫地使用構(gòu)造器注入。這是保證代碼健壯性、可測(cè)試性和清晰度的最佳實(shí)踐。謹(jǐn)慎考慮Setter注入僅當(dāng)依賴是真正可選即對(duì)象在沒有該依賴時(shí)也能提供部分功能或者你需要遵循JavaBean規(guī)范與老舊代碼/框架集成時(shí)才使用Setter注入。使用時(shí)考慮在Setter方法中添加一些空值檢查或日志以應(yīng)對(duì)依賴未設(shè)置的情況。避免使用字段注入在新開發(fā)的代碼中徹底杜絕字段注入。在維護(hù)舊代碼時(shí)如果看到字段注入可以將其視為一個(gè)潛在的重構(gòu)點(diǎn)在時(shí)間允許時(shí)逐步將其改為構(gòu)造器注入。4. 高級(jí)話題與混合使用場(chǎng)景在實(shí)際的大型項(xiàng)目中依賴關(guān)系往往不是非黑即白的。一個(gè)類可能同時(shí)包含強(qiáng)依賴和可選依賴或者需要處理更復(fù)雜的注入邏輯。4.1 混合注入模式一個(gè)類完全可以混合使用構(gòu)造器注入和Setter注入。通常的模式是用構(gòu)造器注入所有強(qiáng)制的、不變的依賴用Setter注入可選的、可變的依賴。Service public class ComplexService { // 強(qiáng)依賴通過構(gòu)造器注入聲明為final private final MandatoryRepository repository; private final EssentialConfig config; // 可選依賴通過Setter注入 private OptionalCache cache; private MetricsPublisher metricsPublisher; // 構(gòu)造器注入強(qiáng)依賴 Autowired public ComplexService(MandatoryRepository repository, EssentialConfig config) { this.repository repository; this.config config; } // Setter注入可選依賴 Autowired(required false) // requiredfalse 表示這是可選的 public void setCache(OptionalCache cache) { this.cache cache; } Autowired(required false) public void setMetricsPublisher(MetricsPublisher metricsPublisher) { this.metricsPublisher metricsPublisher; } public void businessMethod() { // 使用強(qiáng)依賴 repository.findAll(); // 使用可選依賴前進(jìn)行檢查 if (cache ! null) { cache.get(key); } if (metricsPublisher ! null) { metricsPublisher.publish(event); } } }這種模式結(jié)合了兩種方式的優(yōu)點(diǎn)既保證了核心依賴的穩(wěn)定性和不可變性又為功能擴(kuò)展留下了靈活的鉤子。4.2Autowired注解的變體與替代Inject(JSR-330)這是Java依賴注入標(biāo)準(zhǔn)JSR-330中的注解功能與Autowired類似。如果你希望代碼不依賴于Spring特定的注解可以使用Inject。它需要額外的依賴如javax.inject并且功能稍弱例如沒有required屬性。Resource(JSR-250)這也是Java標(biāo)準(zhǔn)注解但行為與Autowired不同。Autowired默認(rèn)按類型byType注入配合Qualifier可按名稱byName。而Resource默認(rèn)按名稱byName匹配如果找不到再按類型byType匹配。它在處理某些特定名稱的依賴時(shí)可能更方便但語義上不如Autowired清晰。Qualifier當(dāng)同一個(gè)接口有多個(gè)實(shí)現(xiàn)時(shí)僅靠類型無法確定注入哪個(gè)Bean。此時(shí)可以使用Qualifier注解指定Bean的名稱。Service public class MyService { // 指定注入名為“primaryDataSource”的DataSource Bean Autowired Qualifier(primaryDataSource) private DataSource dataSource; }Lombok的RequiredArgsConstructor這是減少構(gòu)造器注入樣板代碼的利器。Lombok會(huì)在編譯時(shí)為你生成一個(gè)包含所有final字段的構(gòu)造器。Service RequiredArgsConstructor // Lombok注解生成構(gòu)造器 public class OrderService { // final字段會(huì)被包含在生成的構(gòu)造器中 private final PaymentService paymentService; private final InventoryService inventoryService; // 非final字段不會(huì)被包含 private String someNonFinalField; // ... 業(yè)務(wù)方法 }這讓你既享受了構(gòu)造器注入的所有好處又保持了代碼的簡(jiǎn)潔。這是目前Spring Boot項(xiàng)目中最流行的組合之一。4.3 處理多實(shí)現(xiàn)與集合注入Spring可以非常靈活地處理一個(gè)接口有多個(gè)實(shí)現(xiàn)Bean的情況。按名稱注入使用Qualifier如前所述這是最精確的方式。注入所有實(shí)現(xiàn)注入集合或MapSpring會(huì)自動(dòng)將某種類型的所有Bean注入到一個(gè)List或Map中。Service public class NotificationDispatcher { // 注入NotificationChannel的所有實(shí)現(xiàn)Bean到一個(gè)List Autowired private ListNotificationChannel channels; // 或者注入到一個(gè)Mapkey是Bean的名稱 Autowired private MapString, NotificationChannel channelMap; public void broadcast(String message) { for (NotificationChannel channel : channels) { channel.send(message, all); } // 或者通過名稱使用特定的渠道 // channelMap.get(smsChannel).send(message, user123); } }這種模式在實(shí)現(xiàn)策略模式或插件架構(gòu)時(shí)非常有用新的渠道實(shí)現(xiàn)只需標(biāo)注Service就會(huì)被自動(dòng)收集到集合中。5. 常見問題排查與實(shí)戰(zhàn)技巧即使理解了原理在實(shí)際編碼和調(diào)試中你依然會(huì)遇到各種問題。下面是我在多年Spring開發(fā)中積累的一些常見問題排查經(jīng)驗(yàn)和技巧。5.1 啟動(dòng)時(shí)報(bào)“No qualifying bean of type”錯(cuò)誤這是最常見的錯(cuò)誤之一意思是Spring容器找不到指定類型的Bean來注入。排查步驟檢查Bean是否被Spring管理確認(rèn)依賴的類是否被Component,Service,Repository,Controller等注解標(biāo)記或者是否在Java配置類Configuration中通過Bean方法定義亦或在XML文件中定義了bean。檢查包掃描路徑如果使用組件掃描ComponentScan確保被依賴的類所在的包在掃描路徑之內(nèi)。在Spring Boot中默認(rèn)掃描主應(yīng)用類所在包及其子包。檢查依賴類型確認(rèn)注入點(diǎn)的類型例如PaymentService與Bean實(shí)現(xiàn)的類型是否匹配。如果Bean實(shí)現(xiàn)類實(shí)現(xiàn)了多個(gè)接口你需要明確指定注入哪個(gè)接口。處理多實(shí)現(xiàn)如果有多個(gè)同類型的Bean必須使用Qualifier指定名稱或者將其中一個(gè)Bean標(biāo)記為Primary表示優(yōu)先選擇。5.2 循環(huán)依賴問題Spring報(bào)錯(cuò)BeanCurrentlyInCreationException。原因與解決構(gòu)造器注入導(dǎo)致的循環(huán)依賴這是無法解決的Spring會(huì)直接拋出異常。你必須重構(gòu)代碼來打破循環(huán)。常用方法包括提取公共邏輯到第三個(gè)類將A和B共同依賴的部分提取到C中讓A和B都依賴C。使用Setter/字段注入不推薦作為首選方案將循環(huán)鏈中的某一環(huán)改為Setter注入但這只是掩蓋了設(shè)計(jì)問題。應(yīng)用事件或消息中間件將同步調(diào)用改為異步事件驅(qū)動(dòng)解耦直接依賴。重新思考職責(zé)劃分循環(huán)依賴往往意味著職責(zé)邊界不清需要重新設(shè)計(jì)類的職責(zé)。Setter/字段注入導(dǎo)致的循環(huán)依賴Spring通過三級(jí)緩存機(jī)制可以解決但這會(huì)帶來潛在的運(yùn)行時(shí)問題如AOP代理未完全初始化。最好的辦法依然是優(yōu)化設(shè)計(jì)避免循環(huán)依賴。5.3 單元測(cè)試中的依賴注入對(duì)于構(gòu)造器注入的類單元測(cè)試非常簡(jiǎn)單直接如前面示例所示使用new和Mock框架即可。對(duì)于Setter/字段注入的類測(cè)試會(huì)稍顯麻煩。你需要使用ReflectionTestUtils.setField(...)來手動(dòng)設(shè)置私有字段不推薦侵入性強(qiáng)?；蛘吒鼉?yōu)雅的方式是在測(cè)試中直接調(diào)用Setter方法如果有的話。這給了你一個(gè)將Setter注入改為構(gòu)造器注入的強(qiáng)烈理由為了可測(cè)試性。集成測(cè)試對(duì)于需要啟動(dòng)Spring容器的集成測(cè)試使用SpringBootTest注解。Spring會(huì)為你創(chuàng)建完整的應(yīng)用上下文并自動(dòng)注入所有依賴。這時(shí)你測(cè)試的是整個(gè)組件的集成行為。5.4 性能與設(shè)計(jì)考量小貼士Autowiredon Constructors在Spring 4.3中單構(gòu)造器的Autowired可以省略。保持代碼簡(jiǎn)潔。避免過度注入如果一個(gè)類有太多依賴比如超過7個(gè)這是一個(gè)強(qiáng)烈的“代碼異味”Code Smell表明這個(gè)類可能承擔(dān)了太多職責(zé)?？紤]使用門面模式Facade或命令模式Command進(jìn)行重構(gòu)將部分職責(zé)委托給更細(xì)粒度的服務(wù)。依賴注入與接口編程始終針對(duì)接口而非實(shí)現(xiàn)類進(jìn)行注入。這符合依賴倒置原則使得代碼更靈活更容易替換實(shí)現(xiàn)例如將生產(chǎn)環(huán)境的支付服務(wù)替換為測(cè)試環(huán)境的模擬服務(wù)。小心PostConstruct在依賴注入完成后Spring會(huì)調(diào)用PostConstruct標(biāo)注的方法。確保這個(gè)方法里使用的依賴都已經(jīng)被正確注入。對(duì)于構(gòu)造器注入由于依賴在構(gòu)造時(shí)已就緒所以PostConstruct方法是安全的。但對(duì)于Setter注入如果PostConstruct方法調(diào)用了通過Setter注入的依賴而這個(gè)Setter還未被調(diào)用就會(huì)導(dǎo)致NPE。 Spring依賴注入三種方式詳解：構(gòu)造器、Setter與字段注入對(duì)比
1. 項(xiàng)目概述為什么依賴注入是Spring的基石如果你剛開始接觸Spring框架可能會(huì)被各種注解和配置搞得暈頭轉(zhuǎn)向。但無論你學(xué)到哪個(gè)階段依賴注入這個(gè)概念絕對(duì)是繞不開的核心。它不是什么高深莫測(cè)的黑魔法而是一種讓代碼變得更清晰、更靈活、更容易測(cè)試的設(shè)計(jì)思想。簡(jiǎn)單來說它就是把對(duì)象之間的依賴關(guān)系從代碼內(nèi)部“硬編碼”的方式轉(zhuǎn)變?yōu)橛赏獠咳萜鱽砉芾砗汀白⑷搿钡倪^程。想象一下你是一個(gè)汽車設(shè)計(jì)師。傳統(tǒng)方式下你設(shè)計(jì)發(fā)動(dòng)機(jī)時(shí)必須同時(shí)設(shè)計(jì)好與之匹配的特定型號(hào)的輪胎和方向盤它們被牢牢焊死在一起。而采用依賴注入思想后你只需要設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)的發(fā)動(dòng)機(jī)接口至于裝什么牌子的輪胎、什么款式的方向盤可以在汽車總裝線上也就是Spring容器里靈活配置。這樣做的好處顯而易見發(fā)動(dòng)機(jī)模塊可以獨(dú)立測(cè)試和升級(jí)更換輪胎品牌也無需改動(dòng)發(fā)動(dòng)機(jī)的代碼。Spring框架的核心容器ApplicationContext就是這個(gè)“總裝線”。它負(fù)責(zé)創(chuàng)建對(duì)象Bean并管理它們之間的依賴關(guān)系。理解依賴注入的幾種實(shí)現(xiàn)方式就是理解Spring如何“裝配”你的應(yīng)用。今天我們就來徹底拆解Spring中實(shí)現(xiàn)依賴注入的三種主流方式構(gòu)造器注入、Setter方法注入和字段注入。我會(huì)結(jié)合實(shí)例詳細(xì)分析它們各自的寫法、適用場(chǎng)景、背后的設(shè)計(jì)考量以及在實(shí)際開發(fā)中我踩過的那些坑。2. 依賴注入的三種方式深度解析依賴注入的本質(zhì)是“將依賴傳遞給依賴者”而非由依賴者自己創(chuàng)建或查找依賴。Spring提供了多種途徑來實(shí)現(xiàn)這一過程每種方式都有其鮮明的特點(diǎn)和最佳實(shí)踐場(chǎng)景。理解它們的差異是寫出高質(zhì)量Spring代碼的關(guān)鍵一步。2.1 構(gòu)造器注入強(qiáng)依賴與不可變性的首選構(gòu)造器注入顧名思義就是通過類的構(gòu)造方法來注入依賴。這是Spring團(tuán)隊(duì)自Spring 4.x版本以來官方推薦的首選方式尤其是在Spring Boot應(yīng)用中幾乎成為默認(rèn)規(guī)范。它的核心思想是一個(gè)對(duì)象在創(chuàng)建時(shí)就必須具備其運(yùn)行所需的全部必要依賴。這保證了Bean在初始化完成后就處于一個(gè)完整、可用的狀態(tài)。2.1.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼假設(shè)我們有一個(gè)OrderService訂單服務(wù)它強(qiáng)依賴于PaymentService支付服務(wù)和InventoryService庫存服務(wù)。沒有這兩個(gè)服務(wù)訂單服務(wù)根本無法正常工作。使用構(gòu)造器注入的代碼如下// PaymentService 接口及其實(shí)現(xiàn) public interface PaymentService { boolean processPayment(Order order); } Service public class AlipayPaymentService implements PaymentService { Override public boolean processPayment(Order order) { // 支付寶支付邏輯 System.out.println(Processing payment via Alipay for order: order.getId()); return true; } } // InventoryService 接口及其實(shí)現(xiàn) public interface InventoryService { boolean checkStock(String productId, int quantity); } Service public class DefaultInventoryService implements InventoryService { Override public boolean checkStock(String productId, int quantity) { // 檢查庫存邏輯 System.out.println(Checking stock for product: productId); return quantity 100; // 模擬庫存充足 } } // 使用構(gòu)造器注入的 OrderService Service public class OrderService { // 聲明為 final確保依賴不可變 private final PaymentService paymentService; private final InventoryService inventoryService; // 構(gòu)造器Spring容器會(huì)在這里注入依賴 Autowired // 在Spring 4.3 及單個(gè)構(gòu)造器情況下此注解可省略 public OrderService(PaymentService paymentService, InventoryService inventoryService) { this.paymentService paymentService; this.inventoryService inventoryService; } public void placeOrder(Order order) { // 業(yè)務(wù)邏輯先檢查庫存再處理支付 if (inventoryService.checkStock(order.getProductId(), order.getQuantity())) { if (paymentService.processPayment(order)) { System.out.println(Order placed successfully!); } } } }在上面的代碼中OrderService的依賴paymentService,inventoryService通過構(gòu)造器參數(shù)傳入并被賦值給final字段。這意味著一旦OrderService實(shí)例被創(chuàng)建這些依賴就不能再被改變。2.1.2 設(shè)計(jì)優(yōu)勢(shì)與背后的考量不可變性Immutability將依賴字段聲明為final保證了Bean在生命周期內(nèi)依賴不變。這是函數(shù)式編程和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD中推崇的理念能有效避免因依賴在運(yùn)行時(shí)被意外替換而導(dǎo)致的詭異Bug。完全初始化的狀態(tài)對(duì)象在構(gòu)造完成后就立即可用不存在“半成品”狀態(tài)。這簡(jiǎn)化了對(duì)象狀態(tài)的管理也使得代碼邏輯更易于推理。便于測(cè)試在單元測(cè)試中你可以直接通過new關(guān)鍵字創(chuàng)建被測(cè)對(duì)象并傳入Mock依賴如使用Mockito無需借助Spring容器或特殊的測(cè)試框架設(shè)置測(cè)試代碼非常干凈。Test void testPlaceOrder_Success() { // 創(chuàng)建Mock對(duì)象 PaymentService mockPaymentService mock(PaymentService.class); InventoryService mockInventoryService mock(InventoryService.class); // 設(shè)置Mock行為 when(mockInventoryService.checkStock(anyString(), anyInt())).thenReturn(true); when(mockPaymentService.processPayment(any(Order.class))).thenReturn(true); // 直接通過構(gòu)造器注入依賴進(jìn)行測(cè)試 OrderService orderService new OrderService(mockPaymentService, mockInventoryService); Order testOrder new Order(123, product_1, 2); orderService.placeOrder(testOrder); // 驗(yàn)證交互 verify(mockPaymentService).processPayment(testOrder); }避免循環(huán)依賴Spring容器在解決構(gòu)造器注入的循環(huán)依賴時(shí)會(huì)直接拋出BeanCurrentlyInCreationException。這迫使開發(fā)者重新審視設(shè)計(jì)從根本上解決不良的循環(huán)依賴從而得到更清晰、更松耦合的架構(gòu)。相比之下Setter注入可以“掩蓋”循環(huán)依賴問題但會(huì)帶來潛在的運(yùn)行時(shí)風(fēng)險(xiǎn)。2.1.3 注意事項(xiàng)與實(shí)操心得當(dāng)依賴較多時(shí)如果一個(gè)類的構(gòu)造器參數(shù)超過7個(gè)這是一個(gè)常見的經(jīng)驗(yàn)閾值可能意味著這個(gè)類承擔(dān)了過多的職責(zé)違反了單一職責(zé)原則。這時(shí)應(yīng)該考慮是否可以通過拆分類、引入?yún)?shù)對(duì)象DTO或使用建造者模式來重構(gòu)。Autowired注解在Spring 4.3及以上版本如果一個(gè)類只定義了一個(gè)構(gòu)造器那么Spring會(huì)自動(dòng)將這個(gè)構(gòu)造器用于依賴注入Autowired注解可以省略。如果有多個(gè)構(gòu)造器則必須在你希望Spring使用的那個(gè)構(gòu)造器上標(biāo)注Autowired。與Bean配置結(jié)合在Java配置類Configuration中定義Bean時(shí)構(gòu)造器注入同樣適用且非常直觀。Configuration public class AppConfig { Bean public OrderService orderService(PaymentService paymentService, InventoryService inventoryService) { // 這里的方法參數(shù)就是由Spring自動(dòng)注入的 return new OrderService(paymentService, inventoryService); } }2.2 Setter方法注入可選依賴與動(dòng)態(tài)配置的利器Setter方法注入通過類的Setter方法來完成依賴的注入。這種方式在Spring早期版本和某些特定場(chǎng)景下非常流行。它的核心特點(diǎn)是注入發(fā)生在對(duì)象構(gòu)造之后依賴是可變的。2.2.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼考慮一個(gè)NotificationService通知服務(wù)它可以通過郵件、短信等多種渠道發(fā)送通知。這些渠道對(duì)于服務(wù)核心功能可能是可選的或可動(dòng)態(tài)切換的。public interface NotificationChannel { void send(String message, String target); } Service public class EmailChannel implements NotificationChannel { Override public void send(String message, String target) { System.out.println(Sending Email to target : message); } } Service public class SmsChannel implements NotificationChannel { Override public void send(String message, String target) { System.out.println(Sending SMS to target : message); } } // 使用Setter注入的 NotificationService Service public class NotificationService { // 依賴不是final的 private NotificationChannel primaryChannel; private ListNotificationChannel allChannels; // Setter方法Spring容器會(huì)調(diào)用它們進(jìn)行注入 Autowired Qualifier(emailChannel) // 使用Qualifier指定注入哪個(gè)Bean public void setPrimaryChannel(NotificationChannel channel) { this.primaryChannel channel; } Autowired // 可以注入集合 public void setAllChannels(ListNotificationChannel channels) { this.allChannels channels; } public void notifyUser(String message, String user) { if (primaryChannel ! null) { primaryChannel.send(message, user); } // 也可以廣播到所有渠道 // allChannels.forEach(channel - channel.send(message, user)); } }2.2.2 設(shè)計(jì)優(yōu)勢(shì)與適用場(chǎng)景可選依賴對(duì)于非強(qiáng)制性的依賴Setter注入非常合適。對(duì)象可以在沒有這些依賴的情況下被創(chuàng)建后續(xù)再按需注入。在上例中NotificationService即使沒有設(shè)置primaryChannel它本身也可能具備一些其他功能比如消息格式化只是通知功能不可用。動(dòng)態(tài)重新配置由于依賴不是final的理論上可以在運(yùn)行時(shí)通過調(diào)用Setter方法更換依賴的實(shí)現(xiàn)。這在需要熱更新或動(dòng)態(tài)策略切換的場(chǎng)景下有一定價(jià)值但實(shí)踐中需謹(jǐn)慎處理線程安全問題。解決特定循環(huán)依賴Spring容器處理Bean生命周期時(shí)對(duì)于Setter注入的循環(huán)依賴可以通過“提前暴露對(duì)象引用”的機(jī)制來解決三級(jí)緩存。但這應(yīng)被視為一種迫不得已的解決方案而非設(shè)計(jì)目標(biāo)。與傳統(tǒng)的JavaBean規(guī)范兼容許多老舊的庫或框架遵循JavaBean規(guī)范依賴Setter/Getter方法。在這些場(chǎng)景下Setter注入是自然的選擇。2.2.3 注意事項(xiàng)與常見陷阱對(duì)象狀態(tài)的不一致性這是Setter注入最大的風(fēng)險(xiǎn)。由于依賴可以在對(duì)象創(chuàng)建后的任何時(shí)刻被注入或更改對(duì)象可能在一段時(shí)間內(nèi)處于依賴不全的“部分初始化”狀態(tài)。如果其他線程或組件在此期間調(diào)用了該對(duì)象的方法可能導(dǎo)致NullPointerException或其他未定義行為。破壞了不變性依賴可變使得對(duì)象的線程安全性更難以保證也增加了狀態(tài)管理的復(fù)雜度。容易過度使用因?yàn)閷懛ê?jiǎn)單只需一個(gè)Autowired注解在Setter上開發(fā)者容易將所有依賴都通過Setter注入忽略了構(gòu)造器注入在保證完整性和不可變性上的優(yōu)勢(shì)。Autowired的必要性與構(gòu)造器注入不同Setter方法上的Autowired注解通常不能省略除非你在XML配置中顯式配置了property標(biāo)簽。注意在現(xiàn)代Spring應(yīng)用開發(fā)中特別是基于Spring Boot的項(xiàng)目構(gòu)造器注入已成為絕對(duì)的主流和最佳實(shí)踐。Setter注入應(yīng)被限制在“真正的可選依賴”或“必須與JavaBean規(guī)范兼容”的少數(shù)場(chǎng)景中。2.3 字段注入簡(jiǎn)潔背后的隱患與爭(zhēng)議字段注入是三種方式中語法最簡(jiǎn)潔的直接在字段上添加Autowired注解Spring容器會(huì)通過反射機(jī)制直接將依賴注入到字段中無需編寫構(gòu)造器或Setter方法。2.3.1 基礎(chǔ)實(shí)現(xiàn)與實(shí)例代碼Service public class ReportService { // 字段注入簡(jiǎn)潔但問題也多 Autowired private DataProcessor dataProcessor; Autowired private Formatter formatter; public String generateReport() { Object data dataProcessor.process(); return formatter.format(data); } }從代碼行數(shù)上看這無疑是最省事的。它隱藏了依賴的注入細(xì)節(jié)讓業(yè)務(wù)類看起來非常“干凈”。2.3.2 為什么它備受爭(zhēng)議主要缺點(diǎn)分析破壞了封裝性依賴注入本應(yīng)是一個(gè)從外部管理依賴的“接口”構(gòu)造器或Setter方法。字段注入繞過了這個(gè)接口直接通過反射修改私有字段違反了面向?qū)ο蟮幕痉庋b原則。這使得類的依賴關(guān)系對(duì)外部完全不可見僅通過查看類的公共API無法知道它需要哪些依賴才能正常工作。導(dǎo)致對(duì)Spring容器的高度耦合因?yàn)橐蕾囎⑷胧峭ㄟ^Spring特有的Autowired注解完成的你的類無法脫離Spring容器或至少是它的依賴注入框架進(jìn)行實(shí)例化。這嚴(yán)重影響了代碼的可移植性和單元測(cè)試的純粹性。雖然可以通過Autowired的requiredfalse來模擬可選依賴但這使得測(cè)試設(shè)置更加晦澀。不變性無法保障字段不能被聲明為final因?yàn)镾pring需要在對(duì)象構(gòu)造后通過反射來設(shè)置值因此無法享受不可變性帶來的線程安全和狀態(tài)清晰的好處。依賴檢查滯后對(duì)于構(gòu)造器注入如果Spring容器找不到某個(gè)必需的依賴Bean在應(yīng)用啟動(dòng)時(shí)就會(huì)立即失敗快速發(fā)現(xiàn)問題。對(duì)于字段注入如果requiredtrue默認(rèn)值且依賴不存在啟動(dòng)也會(huì)失敗。但更隱蔽的問題是如果因?yàn)榕渲缅e(cuò)誤導(dǎo)致某些Bean在某些情況下未被創(chuàng)建而字段注入的required又被設(shè)為false那么直到運(yùn)行時(shí)調(diào)用該字段的方法時(shí)才會(huì)拋出NullPointerException增加了調(diào)試難度。不利于單一職責(zé)原則的遵循由于添加依賴的成本極低只需加一個(gè)字段和注解很容易誘使開發(fā)者在一個(gè)類中注入過多的依賴導(dǎo)致類變得臃腫職責(zé)模糊。2.3.3 遺留代碼與特定場(chǎng)景盡管有諸多缺點(diǎn)字段注入在現(xiàn)實(shí)中仍然大量存在主要原因是歷史遺留代碼和某些框架的集成。在一些古老的Spring XML配置遷移過來的項(xiàng)目中或者某些與特定框架如JPA的PersistenceContext深度集成的場(chǎng)景字段注入可能是最方便或唯一的選擇。然而對(duì)于新的項(xiàng)目或新的代碼強(qiáng)烈建議避免使用字段注入。Spring官方文檔和眾多社區(qū)專家包括Spring框架的聯(lián)合創(chuàng)始人Juergen Hoeller都已明確表示構(gòu)造器注入是更可取的方桉。3. 三種方式的對(duì)比與選型指南理解了每種方式的原理和特點(diǎn)后我們需要一個(gè)清晰的決策框架來指導(dǎo)實(shí)際開發(fā)中的選擇。下面的表格從多個(gè)維度對(duì)三者進(jìn)行了對(duì)比特性維度構(gòu)造器注入Setter方法注入字段注入不可變性支持可聲明final字段不支持不支持對(duì)象完全初始化是構(gòu)造后立即可用否存在中間狀態(tài)否存在中間狀態(tài)循環(huán)依賴處理Spring會(huì)直接拋出異常迫使改進(jìn)設(shè)計(jì)Spring可通過三級(jí)緩存機(jī)制解決同Setter注入與容器耦合度低。類可通過new創(chuàng)建便于獨(dú)立測(cè)試。中。需要Setter方法但測(cè)試時(shí)可調(diào)用。高。嚴(yán)重依賴Spring反射機(jī)制。代碼簡(jiǎn)潔性中。需顯式編寫構(gòu)造器。中。需編寫Setter方法。高。僅需一個(gè)注解。封裝性好。依賴通過公共API構(gòu)造器明確聲明。好。依賴通過公共APISetter聲明。差。依賴私有化破壞封裝。適用場(chǎng)景強(qiáng)依賴、必需依賴首選可選依賴、需動(dòng)態(tài)變更的依賴、遺留JavaBean不推薦用于新代碼僅限遺留兼容測(cè)試便利性極佳?？芍苯觧ew對(duì)象并傳入mock。佳。創(chuàng)建對(duì)象后可通過setter注入mock。差。需借助反射或Spring測(cè)試上下文。Spring官方推薦強(qiáng)烈推薦自Spring 4.3起特定場(chǎng)景下使用不推薦選型決策流程建議默認(rèn)選擇構(gòu)造器注入對(duì)于絕大多數(shù)情況尤其是那些構(gòu)成類核心功能的強(qiáng)依賴毫不猶豫地使用構(gòu)造器注入。這是保證代碼健壯性、可測(cè)試性和清晰度的最佳實(shí)踐。謹(jǐn)慎考慮Setter注入僅當(dāng)依賴是真正可選即對(duì)象在沒有該依賴時(shí)也能提供部分功能或者你需要遵循JavaBean規(guī)范與老舊代碼/框架集成時(shí)才使用Setter注入。使用時(shí)考慮在Setter方法中添加一些空值檢查或日志以應(yīng)對(duì)依賴未設(shè)置的情況。避免使用字段注入在新開發(fā)的代碼中徹底杜絕字段注入。在維護(hù)舊代碼時(shí)如果看到字段注入可以將其視為一個(gè)潛在的重構(gòu)點(diǎn)在時(shí)間允許時(shí)逐步將其改為構(gòu)造器注入。4. 高級(jí)話題與混合使用場(chǎng)景在實(shí)際的大型項(xiàng)目中依賴關(guān)系往往不是非黑即白的。一個(gè)類可能同時(shí)包含強(qiáng)依賴和可選依賴或者需要處理更復(fù)雜的注入邏輯。4.1 混合注入模式一個(gè)類完全可以混合使用構(gòu)造器注入和Setter注入。通常的模式是用構(gòu)造器注入所有強(qiáng)制的、不變的依賴用Setter注入可選的、可變的依賴。Service public class ComplexService { // 強(qiáng)依賴通過構(gòu)造器注入聲明為final private final MandatoryRepository repository; private final EssentialConfig config; // 可選依賴通過Setter注入 private OptionalCache cache; private MetricsPublisher metricsPublisher; // 構(gòu)造器注入強(qiáng)依賴 Autowired public ComplexService(MandatoryRepository repository, EssentialConfig config) { this.repository repository; this.config config; } // Setter注入可選依賴 Autowired(required false) // requiredfalse 表示這是可選的 public void setCache(OptionalCache cache) { this.cache cache; } Autowired(required false) public void setMetricsPublisher(MetricsPublisher metricsPublisher) { this.metricsPublisher metricsPublisher; } public void businessMethod() { // 使用強(qiáng)依賴 repository.findAll(); // 使用可選依賴前進(jìn)行檢查 if (cache ! null) { cache.get(key); } if (metricsPublisher ! null) { metricsPublisher.publish(event); } } }這種模式結(jié)合了兩種方式的優(yōu)點(diǎn)既保證了核心依賴的穩(wěn)定性和不可變性又為功能擴(kuò)展留下了靈活的鉤子。4.2Autowired注解的變體與替代Inject(JSR-330)這是Java依賴注入標(biāo)準(zhǔn)JSR-330中的注解功能與Autowired類似。如果你希望代碼不依賴于Spring特定的注解可以使用Inject。它需要額外的依賴如javax.inject并且功能稍弱例如沒有required屬性。Resource(JSR-250)這也是Java標(biāo)準(zhǔn)注解但行為與Autowired不同。Autowired默認(rèn)按類型byType注入配合Qualifier可按名稱byName。而Resource默認(rèn)按名稱byName匹配如果找不到再按類型byType匹配。它在處理某些特定名稱的依賴時(shí)可能更方便但語義上不如Autowired清晰。Qualifier當(dāng)同一個(gè)接口有多個(gè)實(shí)現(xiàn)時(shí)僅靠類型無法確定注入哪個(gè)Bean。此時(shí)可以使用Qualifier注解指定Bean的名稱。Service public class MyService { // 指定注入名為“primaryDataSource”的DataSource Bean Autowired Qualifier(primaryDataSource) private DataSource dataSource; }Lombok的RequiredArgsConstructor這是減少構(gòu)造器注入樣板代碼的利器。Lombok會(huì)在編譯時(shí)為你生成一個(gè)包含所有final字段的構(gòu)造器。Service RequiredArgsConstructor // Lombok注解生成構(gòu)造器 public class OrderService { // final字段會(huì)被包含在生成的構(gòu)造器中 private final PaymentService paymentService; private final InventoryService inventoryService; // 非final字段不會(huì)被包含 private String someNonFinalField; // ... 業(yè)務(wù)方法 }這讓你既享受了構(gòu)造器注入的所有好處又保持了代碼的簡(jiǎn)潔。這是目前Spring Boot項(xiàng)目中最流行的組合之一。4.3 處理多實(shí)現(xiàn)與集合注入Spring可以非常靈活地處理一個(gè)接口有多個(gè)實(shí)現(xiàn)Bean的情況。按名稱注入使用Qualifier如前所述這是最精確的方式。注入所有實(shí)現(xiàn)注入集合或MapSpring會(huì)自動(dòng)將某種類型的所有Bean注入到一個(gè)List或Map中。Service public class NotificationDispatcher { // 注入NotificationChannel的所有實(shí)現(xiàn)Bean到一個(gè)List Autowired private ListNotificationChannel channels; // 或者注入到一個(gè)Mapkey是Bean的名稱 Autowired private MapString, NotificationChannel channelMap; public void broadcast(String message) { for (NotificationChannel channel : channels) { channel.send(message, all); } // 或者通過名稱使用特定的渠道 // channelMap.get(smsChannel).send(message, user123); } }這種模式在實(shí)現(xiàn)策略模式或插件架構(gòu)時(shí)非常有用新的渠道實(shí)現(xiàn)只需標(biāo)注Service就會(huì)被自動(dòng)收集到集合中。5. 常見問題排查與實(shí)戰(zhàn)技巧即使理解了原理在實(shí)際編碼和調(diào)試中你依然會(huì)遇到各種問題。下面是我在多年Spring開發(fā)中積累的一些常見問題排查經(jīng)驗(yàn)和技巧。5.1 啟動(dòng)時(shí)報(bào)“No qualifying bean of type”錯(cuò)誤這是最常見的錯(cuò)誤之一意思是Spring容器找不到指定類型的Bean來注入。排查步驟檢查Bean是否被Spring管理確認(rèn)依賴的類是否被Component,Service,Repository,Controller等注解標(biāo)記或者是否在Java配置類Configuration中通過Bean方法定義亦或在XML文件中定義了bean。檢查包掃描路徑如果使用組件掃描ComponentScan確保被依賴的類所在的包在掃描路徑之內(nèi)。在Spring Boot中默認(rèn)掃描主應(yīng)用類所在包及其子包。檢查依賴類型確認(rèn)注入點(diǎn)的類型例如PaymentService與Bean實(shí)現(xiàn)的類型是否匹配。如果Bean實(shí)現(xiàn)類實(shí)現(xiàn)了多個(gè)接口你需要明確指定注入哪個(gè)接口。處理多實(shí)現(xiàn)如果有多個(gè)同類型的Bean必須使用Qualifier指定名稱或者將其中一個(gè)Bean標(biāo)記為Primary表示優(yōu)先選擇。5.2 循環(huán)依賴問題Spring報(bào)錯(cuò)BeanCurrentlyInCreationException。原因與解決構(gòu)造器注入導(dǎo)致的循環(huán)依賴這是無法解決的Spring會(huì)直接拋出異常。你必須重構(gòu)代碼來打破循環(huán)。常用方法包括提取公共邏輯到第三個(gè)類將A和B共同依賴的部分提取到C中讓A和B都依賴C。使用Setter/字段注入不推薦作為首選方案將循環(huán)鏈中的某一環(huán)改為Setter注入但這只是掩蓋了設(shè)計(jì)問題。應(yīng)用事件或消息中間件將同步調(diào)用改為異步事件驅(qū)動(dòng)解耦直接依賴。重新思考職責(zé)劃分循環(huán)依賴往往意味著職責(zé)邊界不清需要重新設(shè)計(jì)類的職責(zé)。Setter/字段注入導(dǎo)致的循環(huán)依賴Spring通過三級(jí)緩存機(jī)制可以解決但這會(huì)帶來潛在的運(yùn)行時(shí)問題如AOP代理未完全初始化。最好的辦法依然是優(yōu)化設(shè)計(jì)避免循環(huán)依賴。5.3 單元測(cè)試中的依賴注入對(duì)于構(gòu)造器注入的類單元測(cè)試非常簡(jiǎn)單直接如前面示例所示使用new和Mock框架即可。對(duì)于Setter/字段注入的類測(cè)試會(huì)稍顯麻煩。你需要使用ReflectionTestUtils.setField(...)來手動(dòng)設(shè)置私有字段不推薦侵入性強(qiáng)?；蛘吒鼉?yōu)雅的方式是在測(cè)試中直接調(diào)用Setter方法如果有的話。這給了你一個(gè)將Setter注入改為構(gòu)造器注入的強(qiáng)烈理由為了可測(cè)試性。集成測(cè)試對(duì)于需要啟動(dòng)Spring容器的集成測(cè)試使用SpringBootTest注解。Spring會(huì)為你創(chuàng)建完整的應(yīng)用上下文并自動(dòng)注入所有依賴。這時(shí)你測(cè)試的是整個(gè)組件的集成行為。5.4 性能與設(shè)計(jì)考量小貼士Autowiredon Constructors在Spring 4.3中單構(gòu)造器的Autowired可以省略。保持代碼簡(jiǎn)潔。避免過度注入如果一個(gè)類有太多依賴比如超過7個(gè)這是一個(gè)強(qiáng)烈的“代碼異味”Code Smell表明這個(gè)類可能承擔(dān)了太多職責(zé)?？紤]使用門面模式Facade或命令模式Command進(jìn)行重構(gòu)將部分職責(zé)委托給更細(xì)粒度的服務(wù)。依賴注入與接口編程始終針對(duì)接口而非實(shí)現(xiàn)類進(jìn)行注入。這符合依賴倒置原則使得代碼更靈活更容易替換實(shí)現(xiàn)例如將生產(chǎn)環(huán)境的支付服務(wù)替換為測(cè)試環(huán)境的模擬服務(wù)。小心PostConstruct在依賴注入完成后Spring會(huì)調(diào)用PostConstruct標(biāo)注的方法。確保這個(gè)方法里使用的依賴都已經(jīng)被正確注入。對(duì)于構(gòu)造器注入由于依賴在構(gòu)造時(shí)已就緒所以PostConstruct方法是安全的。但對(duì)于Setter注入如果PostConstruct方法調(diào)用了通過Setter注入的依賴而這個(gè)Setter還未被調(diào)用就會(huì)導(dǎo)致NPE。