先講個(gè)我前兩天真實(shí)遇到的事。團(tuán)隊(duì)里來了個(gè)新人我讓他接一個(gè)模塊改動(dòng)他很快把代碼擼完了類上貼了一堆Service、Autowired。我隨口問他“你這段依賴是Spring怎么給你送進(jìn)去的如果我有兩個(gè)實(shí)現(xiàn)你想注入哪一個(gè)A依賴BB又依賴ASpring為什么還能正常啟動(dòng)”他愣了一下說“框架不是都處理好了嗎”。這就是典型的Spring IoCDI只停留在“會(huì)用”層面的表現(xiàn)。說實(shí)話面試也好做Java EE企業(yè)級(jí)應(yīng)用也好Spring IoC和DI都是躲不掉的硬骨頭。它不像某個(gè)工具類記住了API就能用它是一整套設(shè)計(jì)思想決定了你的項(xiàng)目結(jié)構(gòu)、代碼耦合度、測(cè)試方式甚至是排查問題時(shí)的思路方向。這篇文章我打算結(jié)合自己多年的項(xiàng)目實(shí)踐把 IocDI 的核心概念、實(shí)戰(zhàn)用法、底層原理和各類面試考點(diǎn)揉碎了講一遍盡量用大白話和能直接上手的示例讓看完的你能從“會(huì)用注解”升級(jí)到“真懂容器”。1. 先把IoCDI的概念掰開揉碎很多人在IoC上栽跟頭不是智商不夠而是教科書寫得太繞。什么“反轉(zhuǎn)控制”“讓容器管理對(duì)象”聽著跟玄學(xué)似的。我用最直白的方式給你講清楚。1.1 控制反轉(zhuǎn)到底反了什么在沒有Spring的年代我們寫Java Web大多是下面這種玩法public class OrderService { private OrderDao orderDao new OrderDaoImpl(); public void createOrder(Order order) { orderDao.insert(order); } }看起來沒啥問題但OrderService和OrderDaoImpl死死綁在一起。今天你想換一個(gè)OrderDao的Redis緩存實(shí)現(xiàn)得改OrderService的代碼明天你想給OrderService寫單元測(cè)試還得跟著new一個(gè)真實(shí)Dao出來Dao又依賴數(shù)據(jù)源測(cè)試成本直接翻倍?？刂品崔D(zhuǎn)干的事就是把這段代碼里的“new”權(quán)力收走。對(duì)象不是由使用方自己創(chuàng)建而是交給一個(gè)容器統(tǒng)一創(chuàng)建和裝配使用方只需要聲明“我需要一個(gè)OrderDao”容器就把合適的實(shí)例送過來。主動(dòng)權(quán)從調(diào)用者手里反轉(zhuǎn)給了容器這就是“控制反轉(zhuǎn)”。我用生活里的事打個(gè)比方。以前你招待朋友從買菜、洗菜、炒菜、端盤全是你自己干這是傳統(tǒng)開發(fā)?，F(xiàn)在你打電話給餐廳訂餐只說“我要一個(gè)宮保雞丁”后廚怎么選食材、怎么調(diào)味、用什么盤子端上來你完全不關(guān)心這是IoC。餐廳就是Spring容器菜單就是你的依賴聲明。1.2 依賴注入的三種姿勢(shì)依賴注入是IoC落地的手段沒有DIIoC就是空中樓閣。Spring里常用的注入方式有三種構(gòu)造器注入Service public class OrderService { private final OrderDao orderDao; public OrderService(OrderDao orderDao) { this.orderDao orderDao; } }我個(gè)人非常推薦這種方式。好處是依賴在對(duì)象創(chuàng)建那一刻就固定下來字段能用final修飾整個(gè)對(duì)象要么完整創(chuàng)建成功要么創(chuàng)建失敗不存在“注入一半”的中間狀態(tài)。測(cè)試的時(shí)候直接new一個(gè)真實(shí)或Mock的OrderDao傳進(jìn)去就行不用借助Spring容器。Setter注入Service public class OrderService { private OrderDao orderDao; Autowired public void setOrderDao(OrderDao orderDao) { this.orderDao orderDao; } }這種方式適合可選依賴或者依賴需要運(yùn)行時(shí)替換的場(chǎng)景。缺點(diǎn)是你無法確保對(duì)象在使用前一定被賦值如果忘了調(diào)用setter運(yùn)行時(shí)容易空指針。字段注入Service public class OrderService { Autowired private OrderDao orderDao; }寫起來最省事我見過大量項(xiàng)目整片整片都是這種寫法。但它是把雙刃劍依賴關(guān)系被隱藏了你看到的只有字段單元測(cè)試時(shí)不能只new一個(gè)對(duì)象完成注入必須配合Spring Test或者反射工具非常麻煩。而且字段被private包住IDE檢查不友好容易出現(xiàn)“類能跑起來但依賴混亂”的壞味道。1.3 為什么Spring要這么設(shè)計(jì)理解IoC的意義不能只看“不需要new”這種表面好處。真正的原因有三個(gè)。第一是解耦。上層依賴抽象接口不依賴具體實(shí)現(xiàn)。接口不變底層實(shí)現(xiàn)隨便換這就是后面Spring能衍生出AOP、事務(wù)管理、緩存抽象這些東西的地基。你想想一個(gè)多商戶商城項(xiàng)目訂單、支付、庫(kù)存、物流、用戶各個(gè)模塊互相牽扯如果沒有IoC做解耦整個(gè)系統(tǒng)改一處牽一發(fā)動(dòng)全身。第二是可測(cè)試性。依賴由外部注入測(cè)試時(shí)往構(gòu)造器里塞一個(gè)Mock對(duì)象不需要啟動(dòng)數(shù)據(jù)庫(kù)、不需要走網(wǎng)絡(luò)單測(cè)速度飛快。我接手老項(xiàng)目時(shí)最痛苦的就是大量類內(nèi)部new出了各種依賴連個(gè)最簡(jiǎn)單的邏輯都沒法單測(cè)。第三是生命周期管理。容器統(tǒng)一負(fù)責(zé)創(chuàng)建對(duì)象、做初始化、掛代理、執(zhí)行銷毀單例池、線程安全、事務(wù)攔截全部可以在對(duì)象創(chuàng)建過程中無縫織入。沒有IoC容器這些橫切邏輯根本無處安放。2. 從零到一IoCDI的實(shí)戰(zhàn)用法概念講再多不落地都是空談。這一節(jié)我?guī)阕咭槐檎鎸?shí)項(xiàng)目里的裝配方式從最基礎(chǔ)的注解掃描到Java Config再到外部化配置環(huán)環(huán)相扣。2.1 工程準(zhǔn)備與第一行裝配代碼實(shí)踐時(shí)我通常用Spring Boot搭骨架因?yàn)锽oot的自動(dòng)配置把最繁瑣的那部分容器配置藏了起來你只需要聚焦業(yè)務(wù)。用IDEA新建一個(gè)Spring Boot項(xiàng)目引入Web依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency然后寫一個(gè)最簡(jiǎn)單的接口和實(shí)現(xiàn)public interface UserDao { String findUserNameById(Long id); } Repository public class UserDaoImpl implements UserDao { Override public String findUserNameById(Long id) { return 用戶 id; } } Service public class UserService { private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } public String getUserName(Long id) { return userDao.findUserNameById(id); } } RestController public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } GetMapping(/user/{id}) public String getUser(PathVariable Long id) { return userService.getUserName(id); } }啟動(dòng)應(yīng)用訪問/user/1你能看到容器把UserDaoImpl裝配進(jìn)UserService再把UserService裝配進(jìn)Controller。注意Controller里的構(gòu)造器不是自己手動(dòng)調(diào)的是Spring在啟動(dòng)階段掃描到RestController發(fā)現(xiàn)構(gòu)造器需要UserService就從容器里找到UserService的實(shí)例傳進(jìn)去。順嘴提一個(gè)新手典型的坑IDEA創(chuàng)建Spring Boot項(xiàng)目失敗或啟動(dòng)類找不到八成是JDK版本和Maven配置不匹配。建議JDK 8對(duì)應(yīng)Spring Boot 2.xJDK 17對(duì)應(yīng)Spring Boot 3.xMaven鏡像源換成國(guó)內(nèi)源啟動(dòng)速度會(huì)穩(wěn)定很多。2.2 注解裝配最常見也最容易用錯(cuò)Spring的IoC注解體系分兩塊注冊(cè)Bean的注解和注入依賴的注解。注冊(cè)Bean的注解有Component、Service、Repository、Controller。它們?cè)诠δ苌蠜]有任何區(qū)別Spring掃描到它們都會(huì)把對(duì)應(yīng)類注冊(cè)為Bean。把它們分成四個(gè)名字純粹是為了語義化Service告訴閱讀者這是業(yè)務(wù)層Repository是數(shù)據(jù)層Controller是Web層。你去翻Spring源碼會(huì)發(fā)現(xiàn)這四個(gè)注解本身都標(biāo)注了Component。注入依賴的注解則是Autowired和Resource的重災(zāi)區(qū)很多人分不清。Autowired是Spring自己的注解默認(rèn)按類型注入。如果同類型有多個(gè)Bean就結(jié)合Qualifier指定名字。Service public class OrderService { private final PaymentService paymentService; public OrderService(Qualifier(wechatPayService) PaymentService paymentService) { this.paymentService paymentService; } }Resource是Java EE時(shí)代留下的標(biāo)準(zhǔn)注解默認(rèn)按名稱注入名稱找不到再按類型。如果你的項(xiàng)目從Java EE遷移到Spring或者有跨框架的訴求可以考慮它。但從純Spring項(xiàng)目角度我一般建議統(tǒng)用Autowired語義更貼合Spring體系。再來看Value它用于注入外部配置Service public class AliPayService implements PaymentService { Value(${pay.alipay.app-id}) private String appId; }這里的${pay.alipay.app-id}會(huì)在容器啟動(dòng)時(shí)從application.properties或application.yml里讀取。配置文件里寫pay.alipay.app-idwx123456這個(gè)Bean的屬性就會(huì)被自動(dòng)賦值。順便說一句很多初學(xué)者改端口號(hào)都去代碼里找其實(shí)只要在配置里加server.port8081重啟即可。2.3 Java Config把選擇權(quán)握在自己手里注解注入雖然方便但也有力所不及的時(shí)候。比如引入第三方Jar包里的類你沒法給它加Component。這時(shí)就需要Java Config登場(chǎng)。Configuration public class OssConfig { Bean public OssClient ossClient() { return new OssClient(endpoint, accessKey, secretKey); } }Configuration標(biāo)記這是一個(gè)配置類Bean標(biāo)注的方法會(huì)返回一個(gè)對(duì)象Spring會(huì)把方法返回值注冊(cè)為容器中的Bean方法名就是Bean的名字也可以通過Bean(name)指定。后面任何地方需要OssClient直接注入即可。相比早期Spring的XML配置Java Config最大的優(yōu)勢(shì)是編譯期檢查。XML里的class屬性寫錯(cuò)只有啟動(dòng)時(shí)才報(bào)錯(cuò)Java Config里方法返回類型、參數(shù)類型都是強(qiáng)類型的寫錯(cuò)了IDE立刻標(biāo)紅。可重構(gòu)性也強(qiáng)類改名AltEnter一按全局跟著變XML里你還得手動(dòng)改字符串。我維護(hù)遺留項(xiàng)目時(shí)最怕看到動(dòng)輒幾百行的XML配置。建議的落地策略是業(yè)務(wù)自己的類用注解自動(dòng)掃描第三方依賴和需要定制構(gòu)造參數(shù)的類用Java Config。兩者可以混用以ComponentScan的掃描路徑為界。2.4 復(fù)雜場(chǎng)景下的裝配策略真實(shí)項(xiàng)目不會(huì)像教程那么清爽我挑幾個(gè)高頻復(fù)雜場(chǎng)景說說。同類型多Bean怎么選。一個(gè)系統(tǒng)不只一個(gè)支付渠道微信、支付寶、銀聯(lián)都實(shí)現(xiàn)PaymentService。這時(shí)候容器里有三個(gè)Bean直接Autowired會(huì)報(bào)NoUniqueBeanDefinitionException。正確的做法是給每個(gè)實(shí)現(xiàn)加明確的Bean名字注入處用Qualifier指定。還可以用Primary標(biāo)出默認(rèn)實(shí)現(xiàn)這樣不想指定名字的注入點(diǎn)也能拿到主實(shí)現(xiàn)。用Import組織配置。當(dāng)配置類多起來可以在一個(gè)入口配置上通過Import引入其他配置類讓容器啟動(dòng)時(shí)的掃描入口保持整潔Configuration Import({OssConfig.class, DataSourceConfig.class}) public class AppConfig { }配置類里帶條件裝配。Spring Boot的自動(dòng)配置大量用了條件裝配比如ConditionalOnMissingBean表示“容器里沒有這個(gè)Bean時(shí)才創(chuàng)建”。理解了這個(gè)你就明白為什么Boot能那么智能地按需裝配各種組件。自己寫通用模塊時(shí)這套條件注解是控制裝配時(shí)機(jī)的利器。3. 進(jìn)階必懂Bean生命周期與三級(jí)緩存如果說注解用法是IoC的外功那Bean生命周期和三級(jí)緩存就是內(nèi)功。面試能不能鎮(zhèn)住場(chǎng)子基本看這一塊的深度。先聲明一下Spring Boot 2.6之后默認(rèn)關(guān)閉了循環(huán)依賴支持但源碼里三級(jí)緩存機(jī)制依然存在下面講的原理依然有效。3.1 Bean的一生從定義到銷毀一個(gè)Bean從被容器感知到最終銷毀大概走下面這些關(guān)卡解析Bean定義。Spring把帶有注解的類或Bean方法解析成BeanDefinition里面記錄了類的全限定名、作用域、初始化方法、屬性值等。實(shí)例化前處理。InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation有機(jī)會(huì)在Bean真正創(chuàng)建前做手腳。AOP的Configuration類代理就與這個(gè)階段有關(guān)。實(shí)例化。Spring通過反射調(diào)用構(gòu)造器創(chuàng)建原始對(duì)象。此時(shí)對(duì)象還是一張白紙。屬性填充。如果這個(gè)Bean依賴了其他BeanSpring會(huì)在這里完成依賴注入。構(gòu)造器注入發(fā)生在實(shí)例化階段字段和Setter注入發(fā)生在屬性填充階段。這個(gè)順序差異正是后面循環(huán)依賴問題的根源。初始化前處理。BeanPostProcessor.postProcessBeforeInitialization執(zhí)行比如PostConstruct標(biāo)注的方法在這個(gè)階段被調(diào)用。初始化。實(shí)現(xiàn)InitializingBean接口則調(diào)用afterPropertiesSet或者在XML/Java Config里指定initMethod。初始化后處理。BeanPostProcessor.postProcessAfterInitialization執(zhí)行。Spring AOP的代理對(duì)象很多是在這個(gè)階段生成的這也是三級(jí)緩存機(jī)制能兜住AOP場(chǎng)景的關(guān)鍵。使用。Bean進(jìn)入單例池供整個(gè)容器使用。銷毀。容器關(guān)閉時(shí)執(zhí)行PreDestroy標(biāo)注方法或調(diào)用DisposableBean.destroy方法。每次看這個(gè)清單我都要感嘆Spring往一個(gè)對(duì)象的創(chuàng)建過程里塞進(jìn)了太多擴(kuò)展點(diǎn)。只要掌握了BeanPostProcessor你幾乎能在Bean創(chuàng)建的任何環(huán)節(jié)插入邏輯MyBatis的Mapper代理、Feign的動(dòng)態(tài)代理、事務(wù)的增強(qiáng)實(shí)現(xiàn)全是這么織入的。3.2 循環(huán)依賴與Spring三級(jí)緩存循環(huán)依賴是面試?yán)锢@不開的深水區(qū)。什么是循環(huán)依賴就是A的創(chuàng)建需要BB的創(chuàng)建又需要A。如果Spring不做任何處理A等B、B等A程序直接卡死。Spring用三張Map解決了這個(gè)問題一級(jí)緩存singletonObjects存放創(chuàng)建完成的完整單例Bean二級(jí)緩存earlySingletonObjects存放已經(jīng)實(shí)例化但還沒完成屬性填充的早期Bean三級(jí)緩存singletonFactories存放ObjectFactory用來生成Bean的早期引用我畫個(gè)場(chǎng)景推演A先開始創(chuàng)建實(shí)例化得到原始A對(duì)象。Spring把A的ObjectFactory放進(jìn)三級(jí)緩存然后開始給A填充屬性發(fā)現(xiàn)A需要B。容器繼續(xù)創(chuàng)建B實(shí)例化得到原始B對(duì)象把B的工廠放進(jìn)三級(jí)緩存接著給B填充屬性發(fā)現(xiàn)B需要A。這時(shí)B去拿A一級(jí)緩存沒有二級(jí)緩存也沒有但在三級(jí)緩存里找到了A的工廠。工廠執(zhí)行后返回一個(gè)A的引用這個(gè)引用被放入二級(jí)緩存B拿到A的引用完成自身創(chuàng)建并把自己放入一級(jí)緩存。A繼續(xù)走B已經(jīng)完整創(chuàng)建了A拿到B的引用完成自己的屬性填充、初始化和代理增強(qiáng)最終放入一級(jí)緩存。這里就能看出問題A在屬性填充階段拿到的其實(shí)是自己的“提前暴露”版本不是最終完成代理增強(qiáng)后的對(duì)象。而A后面的整個(gè)初始化流程是在給自己補(bǔ)全最終一級(jí)緩存里存的后創(chuàng)建完成的A才是全量版本。這里面的引用關(guān)系Spring通過代理對(duì)象的提前引用做了處理細(xì)節(jié)比較多但核心思路就是你給我一個(gè)半成品先用著等我補(bǔ)全了你再補(bǔ)充后續(xù)的初始化。為什么一定要三級(jí)緩存而不是二級(jí)。這是高頻追問。二級(jí)緩存也能解決字段循環(huán)依賴但沒有三級(jí)緩存Spring無法優(yōu)雅處理AOP代理?？紤]A需要在創(chuàng)建完成后被代理如果B拿到的A是原始A對(duì)象那A后續(xù)創(chuàng)建的代理對(duì)象就和B持有的引用不一致業(yè)務(wù)邏輯就錯(cuò)亂了。三級(jí)緩存里存的是ObjectFactory它能在GetObject時(shí)延遲判斷A需不需要代理如果不需要就返回原始引用如果需要就生成代理對(duì)象還能保證同一Bean只代理一次。正是這個(gè)“延遲決策”能力讓Spring既保住循環(huán)依賴又保住AOP的正確性。哪些循環(huán)依賴救不了。一個(gè)是構(gòu)造器注入的循環(huán)依賴因?yàn)闃?gòu)造器注入發(fā)生在實(shí)例化階段A還沒進(jìn)三級(jí)緩存呢B創(chuàng)建時(shí)根本找不到A的半成品。另一個(gè)是prototype作用域的循環(huán)依賴原型Bean每次獲取都是新實(shí)例Spring不緩存它們自然無從提前暴露。還有Async這類導(dǎo)致代理提前生成的場(chǎng)景處理起來更容易翻車最好的辦法是從設(shè)計(jì)上消除循環(huán)依賴。我自己寫代碼的原則是字段循環(huán)依賴能用三級(jí)緩存兜底但絕不意味著你可以理直氣壯地在項(xiàng)目里寫出A依賴B、B又依賴A的爛代碼。依賴關(guān)系應(yīng)當(dāng)是清晰向下的環(huán)狀依賴本身就是設(shè)計(jì)的壞味道。3.3 作用域與后置處理器擴(kuò)展Bean的作用域決定了容器的管理粒度。默認(rèn)是單例singleton整個(gè)容器只有一份省內(nèi)存適合無狀態(tài)的Service、DAO等。prototype每次獲取都新建適合有狀態(tài)的任務(wù)類。Web環(huán)境下還有request、session、application三種作用域分別對(duì)應(yīng)一次請(qǐng)求、一個(gè)會(huì)話、整個(gè)應(yīng)用上下文。作用域使用最經(jīng)典的坑是在單例Bean里注入原型Bean。單例Bean在容器啟動(dòng)時(shí)就創(chuàng)建一次注入的原型Bean也只有一份后續(xù)獲取的永遠(yuǎn)是同一個(gè)和預(yù)期完全不符。解決辦法是Scope配合ProxyMode或者用ObjectProvider延遲獲取。Component public class SingletonBean { Autowired private ObjectProviderPrototypeBean prototypeBeanProvider; public PrototypeBean getPrototypeBean() { return prototypeBeanProvider.getIfAvailable(); } }ObjectProvider的好處是你不直接注入原型Bean實(shí)例而是注入一個(gè)“獲取器”每次調(diào)用就觸發(fā)一次容器的Bean查找從而拿到全新的原型實(shí)例。這個(gè)技巧在日常開發(fā)里能救很多次命。再聊聊BeanPostProcessor這是Spring的天花板擴(kuò)展點(diǎn)。它能在Bean初始化的前后插入自定義邏輯。很多框架集成都靠它MyBatis的MapperScannerConfigurer掃描Mapper接口并生成動(dòng)態(tài)代理注冊(cè)成BeanSpring Security的MethodSecurityInterceptor通過后置處理器給Bean掛上安全切面。Component public class MyBeanPostProcessor implements BeanPostProcessor { Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { if (bean instanceof MyService) { System.out.println(MyService 初始化完成); } return bean; } }理解了這個(gè)機(jī)制你就明白Spring為什么叫“生態(tài)”而不是“框架”。所有能力都建立在IoC容器之上通過擴(kuò)展點(diǎn)無限延展。4. 面試考點(diǎn)拆解從背誦到碾壓這部分獻(xiàn)給準(zhǔn)備面試的朋友。面試官問IoC很少只問定義他更愛連環(huán)追問。我把高頻問題整理成了鏈?zhǔn)絾柎鸱奖隳沩樦悸方M織答案。4.1 高頻連環(huán)問題與回答思路問說一下你對(duì)Spring IoC的理解。常規(guī)回答“IoC就是控制反轉(zhuǎn)把對(duì)象的創(chuàng)建和依賴交給容器管理?！边@種回答及格但不出彩。我建議的回答是先提本質(zhì)——對(duì)象創(chuàng)建權(quán)從調(diào)用者手中轉(zhuǎn)移給容器DI是其實(shí)現(xiàn)手段再舉業(yè)務(wù)場(chǎng)景——Service不依賴DaoImpl的具體類型只依賴抽象接口容器按聲明注入最后補(bǔ)一句設(shè)計(jì)意義——解耦、可測(cè)試、統(tǒng)一生命周期管理。這樣既體現(xiàn)理解又體現(xiàn)實(shí)戰(zhàn)。問IoC和DI是一回事嗎不是。IoC是設(shè)計(jì)思想DI是實(shí)現(xiàn)思想的方式之一。Spring用DI這套機(jī)制實(shí)現(xiàn)了IoC的效果。打個(gè)比方IoC是“客人不自己做飯”DI是“客人通過菜單告訴服務(wù)員自己想吃什么后廚做好端上來”。不用DI也能實(shí)現(xiàn)IoC比如用Service Locator模式但Spring選擇了DI。問Spring里的Bean默認(rèn)是單例的為什么這么設(shè)計(jì)因?yàn)榇蟛糠諷ervice、Dao這類對(duì)象是無狀態(tài)的它們內(nèi)部沒有可變字段同一時(shí)間可以被多個(gè)線程并發(fā)復(fù)用單例能極大減少對(duì)象創(chuàng)建的開銷。Spring容器作為企業(yè)級(jí)應(yīng)用的基礎(chǔ)設(shè)施啟動(dòng)時(shí)就要掃描、解析、注入大量Bean要是每個(gè)Bean每次獲取都新建一個(gè)性能和內(nèi)存都撐不住。同時(shí)Spring通過ThreadLocal、方法參數(shù)等機(jī)制保證無狀態(tài)Bean的并發(fā)安全。問Autowired和Resource有什么區(qū)別我會(huì)從幾個(gè)維度回答Autowired是Spring的注解Resource是Java EE的標(biāo)準(zhǔn)注解Autowired優(yōu)先按類型裝配多個(gè)同類型時(shí)靠Qualifier按名字補(bǔ)充Resource優(yōu)先按名字裝配名字找不到再按類型Autowired默認(rèn)要求依賴必須存在可以通過requiredfalse放寬Resource沒有這個(gè)屬性。最后補(bǔ)一句項(xiàng)目建議建議Spring項(xiàng)目統(tǒng)一用Autowired跨框架則考慮Resource。問Spring如何解決循環(huán)依賴把三級(jí)緩存的流程講清楚重點(diǎn)回答“為什么是三級(jí)不是二級(jí)”參考第3.2節(jié)。加分項(xiàng)是主動(dòng)說出哪些情況下循環(huán)依賴解決不了構(gòu)造器注入、原型作用域、以及新版本Spring Boot默認(rèn)禁止循環(huán)依賴的事實(shí)。再補(bǔ)一句個(gè)人實(shí)踐經(jīng)驗(yàn)靠緩存兜底不如靠設(shè)計(jì)消滅循環(huán)依賴。問容器啟動(dòng)時(shí)IoC和AOP的執(zhí)行順序是什么這是區(qū)分“背過答案”和“真正理解”的經(jīng)典題。Spring容器啟動(dòng)時(shí)先解析Bean定義創(chuàng)建Bean屬性填充并完成初始化然后BeanPostProcessor在初始化后階段生成AOP代理。換言之IoC負(fù)責(zé)把Bean創(chuàng)建好AOP在Bean準(zhǔn)備就緒后對(duì)方法做增強(qiáng)兩者通過后置處理器銜接。事務(wù)管理、MyBatis的Mapper代理都是這么織進(jìn)去的。4.2 手寫一個(gè)迷你IoC容器編程面試現(xiàn)在越來越喜歡讓候選人手寫一個(gè)微型IoC。你不需要真把Spring寫一遍但核心骨架要能自洽。我的實(shí)現(xiàn)思路分四步第一步掃描包下的所有類篩出帶Component的類第二步用反射實(shí)例化存入一個(gè)Mapkey是Bean名字value是實(shí)例第三步遍歷所有Bean解析字段上的Autowired從Map里找依賴并遞歸注入第四步提供getBean方法暴露對(duì)象。下面是我壓縮后的核心代碼Component public class OrderService { // 模擬需要注入的依賴 } public class MiniApplicationContext { private final MapString, Object singletonObjects new ConcurrentHashMap(); public void scan(String basePackage) throws Exception { String path basePackage.replace(., /); EnumerationURL urls Thread.currentThread().getContextClassLoader() .getResources(path); while (urls.hasMoreElements()) { URL url urls.nextElement(); File dir new File(url.toURI()); for (File file : dir.listFiles(f - f.getName().endsWith(.class))) { String className basePackage . file.getName().replace(.class, ); Class? clazz Class.forName(className); if (clazz.isAnnotationPresent(Component.class)) { String beanName clazz.getSimpleName(); Object instance clazz.getDeclaredConstructor().newInstance(); singletonObjects.put(beanName, instance); } } } injectDependencies(); } private void injectDependencies() throws IllegalAccessException { for (Object bean : singletonObjects.values()) { for (Field field : bean.getClass().getDeclaredFields()) { if (field.isAnnotationPresent(Autowired.class)) { field.setAccessible(true); Object dependency singletonObjects.get(field.getType().getSimpleName()); field.set(bean, dependency); } } } } public T T getBean(ClassT clazz) { return (T) singletonObjects.get(clazz.getSimpleName()); } }這段代碼沒有處理循環(huán)依賴也沒有AOP但已經(jīng)具備IoC容器的三要素統(tǒng)一創(chuàng)建、集中存儲(chǔ)、按需注入。面試時(shí)能寫出這個(gè)骨架再補(bǔ)一句“完整的Spring容器在此基礎(chǔ)上增加了BeanDefinition解析、多級(jí)緩存、后置處理器和復(fù)雜依賴注入”會(huì)顯得特別扎實(shí)。4.3 面試回答的避雷與加分第一個(gè)雷背定義而不懂設(shè)計(jì)。答IoC時(shí)只拋出“控制反轉(zhuǎn)”四個(gè)字面試官一聽就知道你不理解為什么。第二個(gè)雷把Autowired和Resource混為一談。我建議你不僅要知道區(qū)別最好能說出Resource屬于javax.annotation和jakarta.annotation的時(shí)代變遷這能體現(xiàn)你的Java EE背景寬度。第三個(gè)雷說Spring三級(jí)緩存是為了解決性能問題。三級(jí)緩存和性能沒有直接關(guān)聯(lián)它的本質(zhì)是解決創(chuàng)建期依賴查詢和AOP代理延遲生成問題。答錯(cuò)方向前面的印象分全丟。加分方式主動(dòng)指出Spring Boot 2.6后默認(rèn)禁止循環(huán)依賴。這傳遞一個(gè)信號(hào)你不光看了Spring的舊機(jī)制還關(guān)注了最新版本的行為變化。接著補(bǔ)一句“我在項(xiàng)目里用構(gòu)造器注入消除循環(huán)依賴”面試官基本點(diǎn)頭。5. 實(shí)務(wù)中的坑與排查經(jīng)驗(yàn)這部分是純經(jīng)驗(yàn)分享。IoC用得好項(xiàng)目清爽用得糙排查問題能讓你懷疑人生。5.1 常見問題速查表現(xiàn)象原因解決辦法注入的Bean為null類沒被Spring掃描到檢查ComponentScan的包路徑確保類所在包被覆蓋NoSuchBeanDefinitionException容器里根本沒有對(duì)應(yīng)類型檢查類是否加了注冊(cè)注解或Bean方法是否執(zhí)行NoUniqueBeanDefinitionException同類型存在多個(gè)Bean用Qualifier指定名稱或Primary設(shè)置主實(shí)現(xiàn)UnsatisfiedDependencyException構(gòu)造器需要某個(gè)依賴但找不到查看異常鏈路中具體缺哪個(gè)Bean補(bǔ)配置或補(bǔ)注解循環(huán)依賴啟動(dòng)失敗構(gòu)造器注入導(dǎo)致死鎖改成Setter/字段注入或重新梳理依賴關(guān)系單例Bean里的原型Bean不生效注入的是固定實(shí)例用ObjectProvider或Scope(proxyMode ScopedProxyMode.TARGET_CLASS)5.2 排查思路與實(shí)用工具遇到IoC相關(guān)的詭異問題我有個(gè)固定的排查順序。第一步看啟動(dòng)日志。把日志級(jí)別調(diào)到DEBUGlogging: level: org.springframework.beans.factory: DEBUG org.springframework.context: DEBUG啟動(dòng)時(shí)會(huì)打印“Creating shared instance of singleton bean xxx”“Autowired annotation processor”等詳細(xì)信息能看到每個(gè)Bean是在哪個(gè)階段出的問題。這個(gè)辦法解決了我至少一半的定位難題。第二步使用IDEA的Spring輔助窗口。IDE左側(cè)會(huì)出現(xiàn)Spring標(biāo)簽頁里面能看到啟動(dòng)時(shí)掃描到的所有Bean、它們之間的依賴關(guān)系圖。Bean被注入了沒有、注入的是哪個(gè)實(shí)現(xiàn)一目了然。我經(jīng)常在排查NoUniqueBeanDefinitionException時(shí)直接把Bean選中右鍵轉(zhuǎn)到聲明處效率極高。第三步看堆棧往里鉆三層。很多依賴注入的異常信息很繞比如BeanCreationException包了好幾層核心錯(cuò)誤在后面。你看到Caused by那一行才是真正的根因別在前面打轉(zhuǎn)。5.3 寫了這么多年Spring我的幾條心得第一能用構(gòu)造器注入就不要用字段注入。我前幾年帶的項(xiàng)目里老代碼全是字段注入結(jié)果Bean和Bean之間的依賴關(guān)系像蜘蛛網(wǎng)一樣理不清。后來強(qiáng)制推行構(gòu)造器注入每個(gè)類的依賴清單一目了然代碼評(píng)審時(shí)掃一眼構(gòu)造器就能看出這個(gè)類干了多少事。第二被Spring的“便利”迷惑不等于正確。自動(dòng)掃描、自動(dòng)裝配省事了但也把依賴關(guān)系隱藏在暗處。我見過一個(gè)團(tuán)隊(duì)在Service里注入了幾十個(gè)字段整個(gè)類臃腫得像上帝對(duì)象。IoC只是負(fù)責(zé)給你送東西不負(fù)責(zé)約束你該要多少。該按職責(zé)拆分時(shí)還是要拆分。第三循環(huán)依賴是設(shè)計(jì)警鐘而非功能開關(guān)。三級(jí)緩存的存在讓Spring看起來無所不能但你的架構(gòu)里如果頻繁出現(xiàn)環(huán)狀依賴第一步該想的不是怎么配置讓它跑通而是這里的依賴設(shè)計(jì)是不是出了問題。把公共邏輯抽出去讓依賴方向變清晰比任何配置技巧都值錢。第四善用ObjectProvider解決可選依賴。當(dāng)你需要某個(gè)Bean但它可能在容器里不存在時(shí)直接Autowired(required false)是一種解法但每次判空麻煩。用ObjectProvider優(yōu)雅得多既能判斷是否存在又能延遲獲取配合默認(rèn)值實(shí)現(xiàn)代碼干凈不少。寫在最后講完這一圈我對(duì)Spring IoCDI的印象可以用一句話總結(jié)它不是讓你偷懶不用new而是逼你把代碼結(jié)構(gòu)想清楚。很多人在IoC上栽跟頭其實(shí)不是學(xué)不會(huì)而是沒搞懂它解決的到底是哪一類工程問題。如果你能把文章里那個(gè)迷你容器親手寫一遍把三級(jí)緩存那張緩存表在紙上推演一遍再回去看看自己項(xiàng)目里的Service和Dao是怎么糾纏在一起的你會(huì)突然發(fā)現(xiàn)眼前那些注解都變成了看得見摸得著的機(jī)制。這也是我寫這篇文章的初衷Spring再花哨底層還是那些樸素的道理。把這層窗戶紙捅破后面學(xué)AOP、學(xué)事務(wù)傳播、學(xué)Spring Boot自動(dòng)配置都會(huì)順暢很多。