)
很多人問過我一個有點“經(jīng)典”的問題注解啟動的 Spring在new AnnotationConfigApplicationContext(...)那一刻后面到底發(fā)生了什么第一次翻開 Spring 源碼的人十有八九會卡在這個構(gòu)造方法上因為它不像看配置文件那樣直觀調(diào)用鏈會把人繞暈。我最初讀的時候也是一行一行斷點走下來才把“容器初始化”這件事串成一條線。這里的核心關(guān)鍵詞就三個AnnotationConfigApplicationContext、IOC 容器、refresh()。只要搞懂這三個詞你不僅能看懂 Spring 的啟動流程還能順手解決循環(huán)依賴、Autowired 失效、BeanDefinition 被覆蓋這一類線上問題。所以這篇文章我不想只是把源碼翻譯一遍而是按我自己踩坑后的理解把啟動過程拆成幾個能復(fù)現(xiàn)、能驗證的環(huán)節(jié)。適合正在讀 Spring 源碼的人、準備面試的人以及被 IOC 相關(guān) Bug 折磨過的人。1. 啟動入口拆解從構(gòu)造方法一路跟到 refresh()1.1 構(gòu)造方法的四條分支AnnotationConfigApplicationContext的構(gòu)造方法有四種常見用法代碼層面對應(yīng)四條路徑。// 用法1直接傳入配置類 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(AppConfig.class); // 用法2直接傳入包路徑 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(com.example.project); // 用法3先創(chuàng)建空容器再手動注冊并刷新 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(); context.register(AppConfig.class); context.refresh(); // 用法4同時傳配置類和包路徑 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(); context.register(AppConfig.class); context.scan(com.example.project); context.refresh();不管哪種用法最終都繞不開兩件事把“要交給容器管理的類”變成BeanDefinition然后調(diào)用refresh()把BeanDefinition變成可用的單例 Bean?？礋o參構(gòu)造方法源碼是這樣public AnnotationConfigApplicationContext() { this.reader new AnnotatedBeanDefinitionReader(this); this.scanner new ClassPathBeanDefinitionScanner(this); }這里創(chuàng)建了兩個核心組件。AnnotatedBeanDefinitionReader負責(zé)處理顯式傳入的配置類和組件類ClassPathBeanDefinitionScanner負責(zé)按包路徑掃描。這兩個組件各管一攤但最終都把信息注冊到同一個DefaultListableBeanFactory里。有參構(gòu)造方法里能看到清晰的調(diào)用鏈public AnnotationConfigApplicationContext(Class?... componentClasses) { this(); register(componentClasses); refresh(); }register和scan來自AnnotationConfigRegistry接口這個接口只有這兩個方法含義很明確注解容器支持的注冊方式就兩種要么注冊類要么掃包。無論哪種真正的容器啟動動作都在后面的refresh()。1.2 register()顯式注冊配置類register()方法內(nèi)部最終會走到AnnotatedBeanDefinitionReader.doRegisterBean。這個方法做的事情表面上是“注冊類”實際上有一整套細節(jié)先判斷類上的Conditional條件是否滿足滿足之后包裝成AnnotatedGenericBeanDefinition再解析Scope、Lazy、Primary、DependsOn、Role、Description等注解把它們設(shè)置到 BeanDefinition 上最后調(diào)用DefaultListableBeanFactory.registerBeanDefinition把 BeanDefinition 放進容器。這里有一個容易被忽略的點注冊配置類時Spring 并不會立刻解析配置類里的Bean方法。它只是把配置類本身當作一個普通 BeanDefinition 存起來。真正的解析發(fā)生在refresh()的invokeBeanFactoryPostProcessors階段由ConfigurationClassPostProcessor完成。我把這個過程理解為“報名”和“考試”的關(guān)系。register()只是幫這些類報名讓他們進入候選名單但誰有資格成為 Bean、哪些Bean方法要生效要等refresh()里的“考官”來判定。1.3 scan()按包路徑批量注冊scan()方法走的是另一條線最終會進入ClassPathBeanDefinitionScanner.doScan。這里的核心邏輯是根據(jù)傳入的包路徑把它轉(zhuǎn)換成classpath*:com/example/project/**/*.class這樣的資源路徑然后掃描所有匹配的.class文件。這里有個細節(jié)值得多提一句掃描過程用的是 ASM 讀取類的元數(shù)據(jù)并不會真正加載類到 JVM。所以即使某些類沒有依賴 Spring 的注解也不會因為加載失敗導(dǎo)致掃描崩潰。掃描到候選類之后再用isCandidateComponent判斷是不是符合規(guī)則最后照樣注冊成 BeanDefinition。我在剛接觸這部分時犯過一個糊涂以為scan()注冊完成之后Bean 就已經(jīng)創(chuàng)建了。實際上不是scan()只完成 BeanDefinition 的注冊真正的單例實例化要等到refresh()里的finishBeanFactoryInitialization。理解這個先后順序后面排查“為什么 Bean 沒創(chuàng)建”“為什么靜態(tài)變量沒注入”之類的問題會順很多。2. 包掃描機制ClassPathBeanDefinitionScanner 如何把 Component 變成 BeanDefinition2.1 includeFilters 與 excludeFilters 過濾規(guī)則ClassPathBeanDefinitionScanner的過濾規(guī)則是理解掃描行為的關(guān)鍵。構(gòu)造方法里會調(diào)用registerDefaultFilters()默認注冊Component的AnnotationTypeFilter。因為Service、Controller、Repository都帶有Component元注解而AnnotationTypeFilter默認會考慮元注解所以這些注解標注的類也會被掃描到。另外 JSR-330 的Named、JSR-250 的ManagedBean也在默認過濾器中。實際開發(fā)中如果你想只掃描自己定義的注解可以這樣設(shè)置scanner.addIncludeFilter(new AnnotationTypeFilter(MyMarker.class));但要注意addIncludeFilter是追加不是覆蓋。要覆蓋默認規(guī)則需要先清空scanner.resetFilters(false); scanner.addIncludeFilter(new AnnotationTypeFilter(MyMarker.class));resetFilters(true)會把 includeFilters 清空false則保留默認。這個細節(jié)經(jīng)常有人在自定義掃描時踩坑以為設(shè)置了自己的 includeFilter 就只會掃自己指定的注解結(jié)果默認的Component依然生效導(dǎo)致掃進來一堆意料之外的 Bean。2.2 isCandidateComponent 的具體判斷ClassPathScanningCandidateComponentProvider里的isCandidateComponent是過濾鏈的最后一環(huán)。它的判斷邏輯分為兩層。第一層是過濾器的匹配先檢查 excludeFilters只要有一個匹配就排除再檢查 includeFilters必須至少有一個匹配才進入下一層。第二層是類本身的判斷不允許是注解、不允許是接口、不允許是抽象類還要是可以獨立存在的類非內(nèi)部類或者靜態(tài)內(nèi)部類。這套邏輯非常講究。接口和抽象類不能直接實例化如果放進來后面createBean時會直接報錯。內(nèi)部類如果沒有 static 修飾依賴外部類實例也沒法獨立創(chuàng)建。所以這一層過濾是必要的保護。還有一種情況容易被誤解一個抽象類標注了Component正常情況下不會被注冊。但如果抽象類里面有Lookup方法情況會變得復(fù)雜。不過這是很偏的場景一般業(yè)務(wù)代碼不會遇到知道有這層機制就行真遇到再深入查。2.3 掃描到 class 之后如何變成 BeanDefinition過濾通過后scanCandidateComponents會生成一個ScannedGenericBeanDefinition里面包含了類的元數(shù)據(jù)、注解信息。接著doScan方法會做一系列補充處理。首先是解析Scope得到 scope 名稱并設(shè)置到 BeanDefinition。之后用AnnotationConfigUtils.processCommonDefinitionAnnotations處理公共注解包括Lazy、Primary、DependsOn、Role、Description這些。最后通過checkCandidate檢查是否有重名沖突沒有沖突就注冊到容器。整個過程可以用一句話總結(jié)包掃描的本質(zhì)是把“類路徑下的 class 文件”翻譯成“容器能識別的 BeanDefinition”。它沒有創(chuàng)建任何實例也沒有執(zhí)行任何初始化只是拿到了“菜的原材料”和“菜譜”。3. 內(nèi)置后置處理器AnnotatedBeanDefinitionReader 注冊了哪些關(guān)鍵組件3.1 五個處理器分別負責(zé)什么AnnotatedBeanDefinitionReader的構(gòu)造方法里有一行關(guān)鍵調(diào)用AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry)。這一行會往容器里注冊一批固定名稱的“基礎(chǔ)設(shè)施 Bean”。這些 Bean 不是通過包掃描發(fā)現(xiàn)的而是直接以 RootBeanDefinition 的方式硬注冊進去的。它們包括ConfigurationClassPostProcessorBeanDefinitionRegistryPostProcessor負責(zé)解析Configuration、ComponentScan、Import、Bean、PropertySource等所有注解驅(qū)動配置。AutowiredAnnotationBeanPostProcessorBeanPostProcessor負責(zé)處理Autowired和Value的注入。CommonAnnotationBeanPostProcessorBeanPostProcessor負責(zé)處理Resource、PostConstruct、PreDestroy。EventListenerMethodProcessorSmartInitializingSingleton負責(zé)把EventListener方法包裝成 ApplicationListener。DefaultEventListenerFactory配合上面的處理器創(chuàng)建事件監(jiān)聽器適配器。這里要注意一個關(guān)鍵設(shè)計ConfigurationClassPostProcessor不是普通的后置處理器它是BeanDefinitionRegistryPostProcessor并且實現(xiàn)了PriorityOrdered。這意味著它在refresh()的invokeBeanFactoryPostProcessors階段會最先被執(zhí)行。只有它先跑完配置類里的Bean、掃描到的組件才會被注冊成 BeanDefinition后續(xù)其他處理器才有東西可處理。3.2 重復(fù)注冊與自定義覆蓋的判斷邏輯AnnotationConfigUtils.registerAnnotationConfigProcessors在注冊這些基礎(chǔ)設(shè)施 Bean 之前會先判斷容器里是否已經(jīng)有同名 BeanDefinition。如果已經(jīng)有了就不會重復(fù)注冊。這些基礎(chǔ)設(shè)施 Bean 的固定名稱是org.springframework.context.annotation.internalConfigurationAnnotationProcessor這樣的長名字。如果你好奇心強在DefaultListableBeanFactory里 dump 一下 BeanDefinitionNames能看到這些長名稱。這也帶來一個實際啟示如果你想替換 Spring 內(nèi)置的AutowiredAnnotationBeanPostProcessor不能簡單地在配置類里定義一個同名 Bean 去覆蓋。因為containsBeanDefinition已經(jīng)為 trueSpring 會跳過注冊。想要自定義需要修改BeanFactory里已有的 RootBeanDefinition或者用別的機制比如定制BeanPostProcessor的注冊邏輯。我見過有人在項目里試著用Bean定義一個internalAutowiredAnnotationProcessor來替換結(jié)果發(fā)現(xiàn)根本不生效就是這個原因。3.3 為什么這些處理器必須先注冊如果這些處理器不在會出現(xiàn)什么情況最直觀的是Autowired完全失效。因為Autowired的處理依賴AutowiredAnnotationBeanPostProcessor如果容器里沒有這個 BeanPostProcessor那么在populateBean階段就沒有人執(zhí)行字段注入邏輯所有Autowired字段全是 null。同理沒有CommonAnnotationBeanPostProcessorResource、PostConstruct、PreDestroy也不會生效。這也就解釋了為什么在某些“自定義容器”或“半手工 Spring”環(huán)境里明明類掃描進來了但依賴注入就是不工作——大概率是沒走完整套registerAnnotationConfigProcessors。從源碼里挖這一層比背面試題里“Autowired 是怎么實現(xiàn)的”要有用得多。你一旦知道它是靠AutowiredAnnotationBeanPostProcessor處理的遇到“Autowired 不生效”的問題排查思路馬上就有了查這個 BeanPostProcessor 是否注冊、是否在registerBeanPostProcessors階段被實例化、它的執(zhí)行順序是否被其他后置處理器影響。4. refresh() 源碼逐段解讀IOC 容器初始化的十二個關(guān)鍵步驟4.1 prepareRefresh 到 prepareBeanFactoryrefresh()是AbstractApplicationContext的核心模板方法整個 IOC 容器初始化最壯觀的場面都集中在這里。我把調(diào)用鏈拆開講。第一步prepareRefresh()負責(zé)狀態(tài)準備設(shè)置啟動時間、標記容器激活、初始化屬性源、校驗必需的屬性。這一步比較輕重點是讓容器進入“可刷新”狀態(tài)。第二步obtainFreshBeanFactory()在AnnotationConfigApplicationContext這條繼承鏈上比較特殊。因為GenericApplicationContext的 BeanFactory 在構(gòu)造時就已經(jīng)是DefaultListableBeanFactory了所以這里主要是刷新 BeanFactory 的 id并且復(fù)用原有的 BeanDefinition。如果是ClassPathXmlApplicationContext這一步會銷毀舊工廠重建邏輯完全不同。這也是注解容器和 XML 容器在實現(xiàn)上的一個典型差異。第三步prepareBeanFactory(beanFactory)是給工廠“裝基礎(chǔ)設(shè)施”。它做了幾件關(guān)鍵的事設(shè)置類加載器和表達式解析器。添加ApplicationContextAwareProcessor專門處理ApplicationContextAware等 Aware 接口。把BeanFactory、ResourceLoader、ApplicationEventPublisher、ApplicationContext這幾個類型的依賴納入可解析范圍這樣 Bean 里通過Autowired注入這些類型時可以拿到當前容器實例。添加ApplicationListenerDetector用于把容器里的普通 Bean 識別成事件監(jiān)聽器。這一步之后BeanFactory 才算具備了完整的能力。4.2 invokeBeanFactoryPostProcessors配置解析的黃金時機invokeBeanFactoryPostProcessors(beanFactory)是整個refresh()里信息量最大的一步。它負責(zé)觸發(fā)所有BeanFactoryPostProcessor其中最重要的是BeanDefinitionRegistryPostProcessor子接口的實現(xiàn)。執(zhí)行順序有講究我整理成如下規(guī)則先找出所有已注冊的BeanDefinitionRegistryPostProcessor。在這些處理器內(nèi)部按PriorityOrdered、Ordered、普通順序分組執(zhí)行postProcessBeanDefinitionRegistry。執(zhí)行過程中新注冊進來的BeanDefinitionRegistryPostProcessor會被循環(huán)取出并繼續(xù)執(zhí)行。所有BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry跑完后再依次調(diào)用它們的postProcessBeanFactory。最后處理普通的BeanFactoryPostProcessor同樣按優(yōu)先級分組。ConfigurationClassPostProcessor是PriorityOrdered的實現(xiàn)類所以它是第一批執(zhí)行的。它的processConfigBeanDefinitions會找出所有配置類然后通過ConfigurationClassParser解析配置類上的ComponentScan、Import、Bean方法、ImportResource等注解并把解析結(jié)果轉(zhuǎn)換為新的 BeanDefinition 注冊到容器。這一步做完配置類里的Bean方法變成了一個個ConfigurationClassBeanDefinition掃描的路徑變成了具體的ScannedGenericBeanDefinition。可以說用戶寫的注解配置就是在這里被翻譯成 Spring 內(nèi)部的 BeanDefinition 模型的。這里給一個排查思路如果你自定義了一個BeanFactoryPostProcessor希望它能修改所有 BeanDefinition但它不生效先檢查它是不是BeanDefinitionRegistryPostProcessor再檢查優(yōu)先級。因為ConfigurationClassPostProcessor優(yōu)先執(zhí)行如果它還沒解析配置類你的后置處理器可能只看到了極少數(shù) BeanDefinition。4.3 registerBeanPostProcessors 到 registerListenersregisterBeanPostProcessors(beanFactory)負責(zé)注冊所有BeanPostProcessor。這一階段同樣按PriorityOrdered、Ordered、普通順序注冊。BeanPostProcessor的作用時機在 Bean 實例創(chuàng)建階段也就是populateBean和initializeBean時。這里要說一個很多人忽略的點BeanPostProcessor和BeanFactoryPostProcessor的注冊時機不同。后者在 Bean 實例創(chuàng)建之前執(zhí)行作用于 BeanDefinition前者在 Bean 實例創(chuàng)建過程中執(zhí)行作用于實例。理解這條界限對排查“為什么我的后置處理器沒生效”至關(guān)重要。接下來幾步相對輕量。initMessageSource()初始化國際化資源沒有配置就用默認的DelegatingMessageSource。initApplicationEventMulticaster()初始化事件廣播器默認是SimpleApplicationEventMulticaster。onRefresh()是模板方法給子類擴展用比如 Spring MVC 在這里初始化主題解析器。registerListeners()把容器里的ApplicationListenerBean 注冊到廣播器并補發(fā)啟動早期緩存的事件。4.4 finishBeanFactoryInitializationBean 真正實例化的開始finishBeanFactoryInitialization(beanFactory)是容器從“定義階段”進入“運行階段”的分水嶺。注釋寫得很明確實例化所有剩余的非懶加載單例 Bean。這一階段內(nèi)部的關(guān)鍵調(diào)用鏈是preInstantiateSingletons-getBean-doGetBean-createBean-doCreateBean。在doGetBean中Spring 會先從三級緩存singletonObjects、earlySingletonObjects、singletonFactories中查找。如果沒找到再去創(chuàng)建。創(chuàng)建過程在doCreateBean里分幾步實例化構(gòu)造器或工廠方法、暴露到三級緩存允許提前引用、populateBean填充屬性、initializeBean執(zhí)行初始化方法。populateBean會應(yīng)用InstantiationAwareBeanPostProcessor其中就包括處理Autowired的AutowiredAnnotationBeanPostProcessor。initializeBean會依次執(zhí)行 Aware 接口回調(diào)、BeanPostProcessor.postProcessBeforeInitialization、afterPropertiesSet/PostConstruct/init-method、BeanPostProcessor.postProcessAfterInitialization。這一步執(zhí)行完畢之后業(yè)務(wù) Bean 才算真正可用。4.5 finishRefresh發(fā)出容器啟動完成事件最后一步finishRefresh()做收尾工作清理資源緩存、初始化LifecycleProcessor、調(diào)用onRefresh()觸發(fā) Lifecycle Bean 的啟動、發(fā)布ContextRefreshedEvent事件。ContextRefreshedEvent是 Spring 容器啟動完成的信號。我們經(jīng)常用ApplicationListenerContextRefreshedEvent在容器啟動后執(zhí)行初始化數(shù)據(jù)、預(yù)熱緩存等操作就是掛在這一步之后。從源碼順序看這個事件是在所有單例 Bean 都創(chuàng)建完成后才發(fā)布的所以監(jiān)聽器里可以放心地Autowired任何容器 Bean不會出現(xiàn)“Bean 還沒創(chuàng)建好就去用”的情況。把十二步串起來看refresh()就像是容器的一張執(zhí)行清單。每一步都有明確職責(zé)順序也經(jīng)過精心設(shè)計狀態(tài)準備在前BeanDefinition 處理在后實例化再往后最后收尾發(fā)布事件。這張清單值得多看幾遍讀懂了它IOC 容器就不再有黑盒。5. Configuration 增強機制CGLIB 代理與 Full/Lite 模式詳解5.1 為什么要對配置類做增強ConfigurationClassPostProcessor解析完配置類還會做一件很有意思的事對Configuration類進行 CGLIB 增強。ConfigurationClassEnhancer會給配置類生成一個子類代理攔截Bean方法的調(diào)用。為什么要攔截看一個典型例子Configuration public class AppConfig { Bean public DataSource dataSource() { return new DataSource(); } Bean public JdbcTemplate jdbcTemplate() { return new JdbcTemplate(dataSource()); } }jdbcTemplate()方法內(nèi)部調(diào)用了dataSource()。如果配置類不被代理這個調(diào)用會直接執(zhí)行原方法每次調(diào)用都new DataSource()產(chǎn)生一個全新的對象。結(jié)果就是jdbcTemplate里用的 DataSource 和容器中的dataSourceBean 不是同一個實例單例語義被破壞。有了 CGLIB 代理后對dataSource()的調(diào)用會被攔截。代理會先去容器里查dataSourceBean如果已經(jīng)創(chuàng)建就直接返回沒創(chuàng)建就先創(chuàng)建再返回。這樣無論內(nèi)部怎么互相調(diào)用所有Bean方法返回的都是容器管理的單例對象。5.2 proxyBeanMethodsfalse 什么時候用從 Spring 5.2 開始Configuration注解增加了proxyBeanMethods屬性默認是 true也就是默認走 CGLIB 代理。如果設(shè)置為 false配置類就是“Lite 模式”不會被 CGLIB 增強。那什么時候可以關(guān)掉關(guān)鍵看配置類內(nèi)部是否有Bean方法之間的互相調(diào)用。如果不互相調(diào)用只是各自獨立創(chuàng)建 Bean那么代理就沒有必要。關(guān)掉之后有三個好處啟動階段少了 CGLIB 增強的開銷配置類不再要求能被繼承子類代理必須要繼承final 類也能用了Bean方法可以是 final 的。我這里給一個經(jīng)驗如果你只是單純用 Java 配置類把Bean方法列出來方法里沒有互相調(diào)用proxyBeanMethods false是非常安全的優(yōu)化。一旦配置類里有Bean方法互相調(diào)用且依賴單例語義就必須保持默認 true。5.3 Bean 方法里互相調(diào)用的坑既然提到互相調(diào)用就多說一句踩坑記錄。有人會在Component類里寫B(tài)ean方法這樣配置類不會被 CGLIB 增強內(nèi)部調(diào)用Bean方法每次都會新建對象。這種代碼跑起來不一定報錯但單例會悄悄失效很難排查。還有個坑是Configuration類里注入依賴時直接注入配置類類型。由于配置類本身被 CGLIB 代理注入的類型和期望的類型對不上時會拋出BeanNotOfRequiredTypeException。不過一般場景不會注入整個配置類更常見的是注入配置類中某個Bean方法產(chǎn)生的對象這種沒有這個問題。我記得有一次排查一個“DataSource 被創(chuàng)建了兩次”的問題根源就是配置類被 Lite 化處理某處代碼直接new了配置類再調(diào)用Bean方法。如果想避免這種問題盡量保證所有地方都從容器拿 Bean而不是手動new配置類。6. 把源碼變成排查工具三個常見問題的根因分析6.1 循環(huán)依賴到底是怎么被三級緩存解決的循環(huán)依賴是面試高頻題也是線上排查的重災(zāi)區(qū)。Spring 解決循環(huán)依賴的核心在DefaultSingletonBeanRegistry里的三級緩存singletonObjects一級緩存存的是完整初始化后的單例 Bean。earlySingletonObjects二級緩存存的是提前暴露的早期引用可能還沒完成屬性填充。singletonFactories三級緩存存的是 ObjectFactory通過它可以拿到早期引用。流程大致是這樣A 創(chuàng)建時實例化完成后會把ObjectFactory放入三級緩存。A 在populateBean填充屬性時發(fā)現(xiàn)依賴 B于是去創(chuàng)建 B。B 創(chuàng)建時填充屬性發(fā)現(xiàn)依賴 A此時從三級緩存取到 A 的ObjectFactory調(diào)用getEarlyBeanReference得到 A 的早期引用放入二級緩存注入給 B。B 創(chuàng)建完成后A 拿到 B 的完整引用繼續(xù)完成初始化。最后 A 初始化完畢從一級緩存返回。為什么需要三級緩存而不是二級關(guān)鍵原因和 BeanPostProcessor 有關(guān)。某些SmartInstantiationAwareBeanPostProcessor比如 AOP 相關(guān)的在getEarlyBeanReference時可能生成代理對象。如果把原始實例直接放進二級緩存后續(xù)就沒法再做代理增強。三級緩存存的是一個工廠真正需要早期引用時才觸發(fā)代理邏輯這樣就兼顧了性能和正確性。構(gòu)造器注入的循環(huán)依賴為什么解決不了因為在構(gòu)造器階段對象還沒創(chuàng)建完成還沒把ObjectFactory暴露到三級緩存。Spring 在查找依賴時發(fā)現(xiàn)緩存里沒有會嘗試繼續(xù)創(chuàng)建從而形成死循環(huán)最終報BeanCurrentlyInCreationException。遇到構(gòu)造器循環(huán)依賴可以用Lazy注入代理來拆解。6.2 Autowired 為 null 或失效時的排查思路遇到Autowired字段為 null很多人的第一反應(yīng)是“是不是容器沒掃到這個類”。這當然是一部分原因但從源碼角度排查可以按下面的順序來。第一查 BeanDefinition 是否注冊。在DefaultListableBeanFactory里打斷點看beanDefinitionNames里有沒有目標類。沒有就查掃描路徑是否正確、ComponentScan是否覆蓋到目標包、類上是否有Component族注解。第二查是否被過濾規(guī)則排除。如果自定義了 TypeFilter檢查過濾規(guī)則是否誤傷。第三查是否在 BeanPostProcessor 注冊之后手動 new 了對象。Autowired只對容器管理的 Bean 生效自己 new 出來的對象沒有經(jīng)過populateBean字段當然不會注入。第四查作用域。如果是 prototype 作用域每次獲取都是新對象需要確認獲取時機。如果是在容器啟動早期手動獲取可能 Bean 還沒創(chuàng)建完成。還有一個常見現(xiàn)象在static字段上加Autowired永遠為 null。原因從源碼看很直接AutowiredAnnotationBeanPostProcessor的postProcessProperties是面向?qū)嵗膕tatic 字段不屬于某個具體實例Spring 根本沒打算處理它。如果要注入靜態(tài)資源建議用 setter 方法在啟動時手動賦值或者重新設(shè)計一下依賴結(jié)構(gòu)。6.3 進階實戰(zhàn)自定義 BeanDefinitionRegistryPostProcessor 注冊 Bean理解了invokeBeanFactoryPostProcessors的時機之后你可以利用源碼知識做一件事在容器啟動早期動態(tài)注冊一個新的 BeanDefinition。這個技巧在中間件集成、動態(tài)擴展場景下很實用。先寫一個處理器Component public class DynamicBeanRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor { Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException { GenericBeanDefinition definition new GenericBeanDefinition(); definition.setBeanClassName(CacheService.class.getName()); definition.setScope(ConfigurableBeanFactory.SCOPE_SINGLETON); registry.registerBeanDefinition(cacheService, definition); System.out.println(registered cacheService: registry.containsBeanDefinition(cacheService)); } Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { // 可以在這里修改 beanFactory 的配置比如設(shè)置 ignoreDependencyInterface } }再定義一個普通的CacheService類不加任何注解。啟動容器后通過context.getBean(CacheService.class)能拿到實例因為 BeanDefinition 已經(jīng)在postProcessBeanDefinitionRegistry階段被注冊后續(xù)finishBeanFactoryInitialization會正常實例化它。這個機制能做什么比如從數(shù)據(jù)庫或配置中心讀取一段配置動態(tài)決定要不要注冊某個 Bean、注冊多少個 Bean、BeanClass 是什么。這些場景下寫死在ComponentScan里反而不靈活動態(tài)注冊 BeanDefinition 就成了更合適的方案。核心要點只有一個把握住執(zhí)行時機確保注冊操作發(fā)生在 BeanDefinition 處理階段。7. 高效閱讀 Spring 源碼的斷點與路線圖7.1 合適的入口斷點哪里打讀源碼最怕亂翻。我的建議是第一遍先只打一個斷點AbstractApplicationContext.refresh()。這一步是容器初始化的主干所有后續(xù)流程都由它驅(qū)動。跟著調(diào)用棧往下走一遍先把十二步整體過一遍。第二遍再進細節(jié)。推薦的斷點位置AnnotationConfigApplicationContext構(gòu)造方法看容器如何創(chuàng)建 reader/scanner。ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry看配置解析的起點。ConfigurationClassParser.doProcessConfigurationClass看配置類的解析步驟包括ComponentScan、Import、Bean的逐個處理。DefaultListableBeanFactory.registerBeanDefinition看 BeanDefinition 注冊到容器的入口。AbstractAutowireCapableBeanFactory.doCreateBean看 Bean 實例化的全過程。DefaultSingletonBeanRegistry.getSingleton看三級緩存的查找邏輯。有了這些斷點你在實際調(diào)試一個 Demo 時可以帶著“當前執(zhí)行到哪一步了”的意識配合Evaluate Expression查看上下文信息比干讀源碼效率高很多。7.2 源碼閱讀路線圖如果按路線圖來我建議分四條線走。第一條線是入口線從AnnotationConfigApplicationContext構(gòu)造方法開始走到refresh()整體把握容器啟動流程。第二條線是配置解析線從ConfigurationClassPostProcessor開始進入ConfigurationClassParser看它是如何逐個處理配置類注解的。這一線是注解驅(qū)動開發(fā)的核心。第三條線是實例化線從finishBeanFactoryInitialization進入preInstantiateSingletons再到getBean、doGetBean、createBean、doCreateBean完整看一遍 Bean 從無到有的過程。這條線對理解生命周期、循環(huán)依賴至關(guān)重要。第四條線是生命周期線從doCreateBean里的populateBean和initializeBean入手看 BeanPostProcessor 是如何嵌入實例化和初始化過程的。這條線真正體現(xiàn)了“Spring 的可擴展性是怎么設(shè)計出來的”。四條線之間有交叉但每條線都有清晰主線。按照這條路線讀下來我自己的體會是比零散看源碼要快得多。7.3 調(diào)試過程中容易誤判的現(xiàn)象調(diào)試 Spring 源碼有兩個容易讓人誤判的點我提一下。第一個是getBeanNamesForType會提前觸發(fā) Bean 創(chuàng)建。在調(diào)試時你可能會發(fā)現(xiàn)在preInstantiateSingletons之前某些 Bean 已經(jīng)被實例化了。原因是getBeanNamesForType內(nèi)部需要確定類型可能觸發(fā)getBean。所以不要看到有 Bean 創(chuàng)建就以為容器已經(jīng)開始實例化了要確認觸發(fā)時機。第二個是 BeanPostProcessor 的執(zhí)行順序很容易被忽略。多個BeanPostProcessor之間有順序如果你的后置處理器依賴其他處理器先執(zhí)行建議實現(xiàn)Ordered或PriorityOrdered來保證順序。否則調(diào)試時看到的現(xiàn)象會非常隨機因為 Bean 創(chuàng)建順序本身不是嚴格按代碼書寫順序來的。最后一個建議讀源碼一定要配一個最小的可執(zhí)行 Demo。光看不練很容易看著看著就迷失在調(diào)用棧里。我通常會在項目里放一個空的AnnotationConfigApplicationContext啟動類所有斷點都掛在源碼上跑一遍觀察每一步的 BeanDefinitionNames 變化。把這一步做完你再回頭看那些 IOC 的面試題和線上問題會發(fā)現(xiàn)它們變成了一條清晰的邏輯鏈。 Spring IOC容器啟動原理：從AnnotationConfigApplicationContext到refresh()
很多人問過我一個有點“經(jīng)典”的問題注解啟動的 Spring在new AnnotationConfigApplicationContext(...)那一刻后面到底發(fā)生了什么第一次翻開 Spring 源碼的人十有八九會卡在這個構(gòu)造方法上因為它不像看配置文件那樣直觀調(diào)用鏈會把人繞暈。我最初讀的時候也是一行一行斷點走下來才把“容器初始化”這件事串成一條線。這里的核心關(guān)鍵詞就三個AnnotationConfigApplicationContext、IOC 容器、refresh()。只要搞懂這三個詞你不僅能看懂 Spring 的啟動流程還能順手解決循環(huán)依賴、Autowired 失效、BeanDefinition 被覆蓋這一類線上問題。所以這篇文章我不想只是把源碼翻譯一遍而是按我自己踩坑后的理解把啟動過程拆成幾個能復(fù)現(xiàn)、能驗證的環(huán)節(jié)。適合正在讀 Spring 源碼的人、準備面試的人以及被 IOC 相關(guān) Bug 折磨過的人。1. 啟動入口拆解從構(gòu)造方法一路跟到 refresh()1.1 構(gòu)造方法的四條分支AnnotationConfigApplicationContext的構(gòu)造方法有四種常見用法代碼層面對應(yīng)四條路徑。// 用法1直接傳入配置類 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(AppConfig.class); // 用法2直接傳入包路徑 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(com.example.project); // 用法3先創(chuàng)建空容器再手動注冊并刷新 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(); context.register(AppConfig.class); context.refresh(); // 用法4同時傳配置類和包路徑 AnnotationConfigApplicationContext context new AnnotationConfigApplicationContext(); context.register(AppConfig.class); context.scan(com.example.project); context.refresh();不管哪種用法最終都繞不開兩件事把“要交給容器管理的類”變成BeanDefinition然后調(diào)用refresh()把BeanDefinition變成可用的單例 Bean?？礋o參構(gòu)造方法源碼是這樣public AnnotationConfigApplicationContext() { this.reader new AnnotatedBeanDefinitionReader(this); this.scanner new ClassPathBeanDefinitionScanner(this); }這里創(chuàng)建了兩個核心組件。AnnotatedBeanDefinitionReader負責(zé)處理顯式傳入的配置類和組件類ClassPathBeanDefinitionScanner負責(zé)按包路徑掃描。這兩個組件各管一攤但最終都把信息注冊到同一個DefaultListableBeanFactory里。有參構(gòu)造方法里能看到清晰的調(diào)用鏈public AnnotationConfigApplicationContext(Class?... componentClasses) { this(); register(componentClasses); refresh(); }register和scan來自AnnotationConfigRegistry接口這個接口只有這兩個方法含義很明確注解容器支持的注冊方式就兩種要么注冊類要么掃包。無論哪種真正的容器啟動動作都在后面的refresh()。1.2 register()顯式注冊配置類register()方法內(nèi)部最終會走到AnnotatedBeanDefinitionReader.doRegisterBean。這個方法做的事情表面上是“注冊類”實際上有一整套細節(jié)先判斷類上的Conditional條件是否滿足滿足之后包裝成AnnotatedGenericBeanDefinition再解析Scope、Lazy、Primary、DependsOn、Role、Description等注解把它們設(shè)置到 BeanDefinition 上最后調(diào)用DefaultListableBeanFactory.registerBeanDefinition把 BeanDefinition 放進容器。這里有一個容易被忽略的點注冊配置類時Spring 并不會立刻解析配置類里的Bean方法。它只是把配置類本身當作一個普通 BeanDefinition 存起來。真正的解析發(fā)生在refresh()的invokeBeanFactoryPostProcessors階段由ConfigurationClassPostProcessor完成。我把這個過程理解為“報名”和“考試”的關(guān)系。register()只是幫這些類報名讓他們進入候選名單但誰有資格成為 Bean、哪些Bean方法要生效要等refresh()里的“考官”來判定。1.3 scan()按包路徑批量注冊scan()方法走的是另一條線最終會進入ClassPathBeanDefinitionScanner.doScan。這里的核心邏輯是根據(jù)傳入的包路徑把它轉(zhuǎn)換成classpath*:com/example/project/**/*.class這樣的資源路徑然后掃描所有匹配的.class文件。這里有個細節(jié)值得多提一句掃描過程用的是 ASM 讀取類的元數(shù)據(jù)并不會真正加載類到 JVM。所以即使某些類沒有依賴 Spring 的注解也不會因為加載失敗導(dǎo)致掃描崩潰。掃描到候選類之后再用isCandidateComponent判斷是不是符合規(guī)則最后照樣注冊成 BeanDefinition。我在剛接觸這部分時犯過一個糊涂以為scan()注冊完成之后Bean 就已經(jīng)創(chuàng)建了。實際上不是scan()只完成 BeanDefinition 的注冊真正的單例實例化要等到refresh()里的finishBeanFactoryInitialization。理解這個先后順序后面排查“為什么 Bean 沒創(chuàng)建”“為什么靜態(tài)變量沒注入”之類的問題會順很多。2. 包掃描機制ClassPathBeanDefinitionScanner 如何把 Component 變成 BeanDefinition2.1 includeFilters 與 excludeFilters 過濾規(guī)則ClassPathBeanDefinitionScanner的過濾規(guī)則是理解掃描行為的關(guān)鍵。構(gòu)造方法里會調(diào)用registerDefaultFilters()默認注冊Component的AnnotationTypeFilter。因為Service、Controller、Repository都帶有Component元注解而AnnotationTypeFilter默認會考慮元注解所以這些注解標注的類也會被掃描到。另外 JSR-330 的Named、JSR-250 的ManagedBean也在默認過濾器中。實際開發(fā)中如果你想只掃描自己定義的注解可以這樣設(shè)置scanner.addIncludeFilter(new AnnotationTypeFilter(MyMarker.class));但要注意addIncludeFilter是追加不是覆蓋。要覆蓋默認規(guī)則需要先清空scanner.resetFilters(false); scanner.addIncludeFilter(new AnnotationTypeFilter(MyMarker.class));resetFilters(true)會把 includeFilters 清空false則保留默認。這個細節(jié)經(jīng)常有人在自定義掃描時踩坑以為設(shè)置了自己的 includeFilter 就只會掃自己指定的注解結(jié)果默認的Component依然生效導(dǎo)致掃進來一堆意料之外的 Bean。2.2 isCandidateComponent 的具體判斷ClassPathScanningCandidateComponentProvider里的isCandidateComponent是過濾鏈的最后一環(huán)。它的判斷邏輯分為兩層。第一層是過濾器的匹配先檢查 excludeFilters只要有一個匹配就排除再檢查 includeFilters必須至少有一個匹配才進入下一層。第二層是類本身的判斷不允許是注解、不允許是接口、不允許是抽象類還要是可以獨立存在的類非內(nèi)部類或者靜態(tài)內(nèi)部類。這套邏輯非常講究。接口和抽象類不能直接實例化如果放進來后面createBean時會直接報錯。內(nèi)部類如果沒有 static 修飾依賴外部類實例也沒法獨立創(chuàng)建。所以這一層過濾是必要的保護。還有一種情況容易被誤解一個抽象類標注了Component正常情況下不會被注冊。但如果抽象類里面有Lookup方法情況會變得復(fù)雜。不過這是很偏的場景一般業(yè)務(wù)代碼不會遇到知道有這層機制就行真遇到再深入查。2.3 掃描到 class 之后如何變成 BeanDefinition過濾通過后scanCandidateComponents會生成一個ScannedGenericBeanDefinition里面包含了類的元數(shù)據(jù)、注解信息。接著doScan方法會做一系列補充處理。首先是解析Scope得到 scope 名稱并設(shè)置到 BeanDefinition。之后用AnnotationConfigUtils.processCommonDefinitionAnnotations處理公共注解包括Lazy、Primary、DependsOn、Role、Description這些。最后通過checkCandidate檢查是否有重名沖突沒有沖突就注冊到容器。整個過程可以用一句話總結(jié)包掃描的本質(zhì)是把“類路徑下的 class 文件”翻譯成“容器能識別的 BeanDefinition”。它沒有創(chuàng)建任何實例也沒有執(zhí)行任何初始化只是拿到了“菜的原材料”和“菜譜”。3. 內(nèi)置后置處理器AnnotatedBeanDefinitionReader 注冊了哪些關(guān)鍵組件3.1 五個處理器分別負責(zé)什么AnnotatedBeanDefinitionReader的構(gòu)造方法里有一行關(guān)鍵調(diào)用AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry)。這一行會往容器里注冊一批固定名稱的“基礎(chǔ)設(shè)施 Bean”。這些 Bean 不是通過包掃描發(fā)現(xiàn)的而是直接以 RootBeanDefinition 的方式硬注冊進去的。它們包括ConfigurationClassPostProcessorBeanDefinitionRegistryPostProcessor負責(zé)解析Configuration、ComponentScan、Import、Bean、PropertySource等所有注解驅(qū)動配置。AutowiredAnnotationBeanPostProcessorBeanPostProcessor負責(zé)處理Autowired和Value的注入。CommonAnnotationBeanPostProcessorBeanPostProcessor負責(zé)處理Resource、PostConstruct、PreDestroy。EventListenerMethodProcessorSmartInitializingSingleton負責(zé)把EventListener方法包裝成 ApplicationListener。DefaultEventListenerFactory配合上面的處理器創(chuàng)建事件監(jiān)聽器適配器。這里要注意一個關(guān)鍵設(shè)計ConfigurationClassPostProcessor不是普通的后置處理器它是BeanDefinitionRegistryPostProcessor并且實現(xiàn)了PriorityOrdered。這意味著它在refresh()的invokeBeanFactoryPostProcessors階段會最先被執(zhí)行。只有它先跑完配置類里的Bean、掃描到的組件才會被注冊成 BeanDefinition后續(xù)其他處理器才有東西可處理。3.2 重復(fù)注冊與自定義覆蓋的判斷邏輯AnnotationConfigUtils.registerAnnotationConfigProcessors在注冊這些基礎(chǔ)設(shè)施 Bean 之前會先判斷容器里是否已經(jīng)有同名 BeanDefinition。如果已經(jīng)有了就不會重復(fù)注冊。這些基礎(chǔ)設(shè)施 Bean 的固定名稱是org.springframework.context.annotation.internalConfigurationAnnotationProcessor這樣的長名字。如果你好奇心強在DefaultListableBeanFactory里 dump 一下 BeanDefinitionNames能看到這些長名稱。這也帶來一個實際啟示如果你想替換 Spring 內(nèi)置的AutowiredAnnotationBeanPostProcessor不能簡單地在配置類里定義一個同名 Bean 去覆蓋。因為containsBeanDefinition已經(jīng)為 trueSpring 會跳過注冊。想要自定義需要修改BeanFactory里已有的 RootBeanDefinition或者用別的機制比如定制BeanPostProcessor的注冊邏輯。我見過有人在項目里試著用Bean定義一個internalAutowiredAnnotationProcessor來替換結(jié)果發(fā)現(xiàn)根本不生效就是這個原因。3.3 為什么這些處理器必須先注冊如果這些處理器不在會出現(xiàn)什么情況最直觀的是Autowired完全失效。因為Autowired的處理依賴AutowiredAnnotationBeanPostProcessor如果容器里沒有這個 BeanPostProcessor那么在populateBean階段就沒有人執(zhí)行字段注入邏輯所有Autowired字段全是 null。同理沒有CommonAnnotationBeanPostProcessorResource、PostConstruct、PreDestroy也不會生效。這也就解釋了為什么在某些“自定義容器”或“半手工 Spring”環(huán)境里明明類掃描進來了但依賴注入就是不工作——大概率是沒走完整套registerAnnotationConfigProcessors。從源碼里挖這一層比背面試題里“Autowired 是怎么實現(xiàn)的”要有用得多。你一旦知道它是靠AutowiredAnnotationBeanPostProcessor處理的遇到“Autowired 不生效”的問題排查思路馬上就有了查這個 BeanPostProcessor 是否注冊、是否在registerBeanPostProcessors階段被實例化、它的執(zhí)行順序是否被其他后置處理器影響。4. refresh() 源碼逐段解讀IOC 容器初始化的十二個關(guān)鍵步驟4.1 prepareRefresh 到 prepareBeanFactoryrefresh()是AbstractApplicationContext的核心模板方法整個 IOC 容器初始化最壯觀的場面都集中在這里。我把調(diào)用鏈拆開講。第一步prepareRefresh()負責(zé)狀態(tài)準備設(shè)置啟動時間、標記容器激活、初始化屬性源、校驗必需的屬性。這一步比較輕重點是讓容器進入“可刷新”狀態(tài)。第二步obtainFreshBeanFactory()在AnnotationConfigApplicationContext這條繼承鏈上比較特殊。因為GenericApplicationContext的 BeanFactory 在構(gòu)造時就已經(jīng)是DefaultListableBeanFactory了所以這里主要是刷新 BeanFactory 的 id并且復(fù)用原有的 BeanDefinition。如果是ClassPathXmlApplicationContext這一步會銷毀舊工廠重建邏輯完全不同。這也是注解容器和 XML 容器在實現(xiàn)上的一個典型差異。第三步prepareBeanFactory(beanFactory)是給工廠“裝基礎(chǔ)設(shè)施”。它做了幾件關(guān)鍵的事設(shè)置類加載器和表達式解析器。添加ApplicationContextAwareProcessor專門處理ApplicationContextAware等 Aware 接口。把BeanFactory、ResourceLoader、ApplicationEventPublisher、ApplicationContext這幾個類型的依賴納入可解析范圍這樣 Bean 里通過Autowired注入這些類型時可以拿到當前容器實例。添加ApplicationListenerDetector用于把容器里的普通 Bean 識別成事件監(jiān)聽器。這一步之后BeanFactory 才算具備了完整的能力。4.2 invokeBeanFactoryPostProcessors配置解析的黃金時機invokeBeanFactoryPostProcessors(beanFactory)是整個refresh()里信息量最大的一步。它負責(zé)觸發(fā)所有BeanFactoryPostProcessor其中最重要的是BeanDefinitionRegistryPostProcessor子接口的實現(xiàn)。執(zhí)行順序有講究我整理成如下規(guī)則先找出所有已注冊的BeanDefinitionRegistryPostProcessor。在這些處理器內(nèi)部按PriorityOrdered、Ordered、普通順序分組執(zhí)行postProcessBeanDefinitionRegistry。執(zhí)行過程中新注冊進來的BeanDefinitionRegistryPostProcessor會被循環(huán)取出并繼續(xù)執(zhí)行。所有BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry跑完后再依次調(diào)用它們的postProcessBeanFactory。最后處理普通的BeanFactoryPostProcessor同樣按優(yōu)先級分組。ConfigurationClassPostProcessor是PriorityOrdered的實現(xiàn)類所以它是第一批執(zhí)行的。它的processConfigBeanDefinitions會找出所有配置類然后通過ConfigurationClassParser解析配置類上的ComponentScan、Import、Bean方法、ImportResource等注解并把解析結(jié)果轉(zhuǎn)換為新的 BeanDefinition 注冊到容器。這一步做完配置類里的Bean方法變成了一個個ConfigurationClassBeanDefinition掃描的路徑變成了具體的ScannedGenericBeanDefinition。可以說用戶寫的注解配置就是在這里被翻譯成 Spring 內(nèi)部的 BeanDefinition 模型的。這里給一個排查思路如果你自定義了一個BeanFactoryPostProcessor希望它能修改所有 BeanDefinition但它不生效先檢查它是不是BeanDefinitionRegistryPostProcessor再檢查優(yōu)先級。因為ConfigurationClassPostProcessor優(yōu)先執(zhí)行如果它還沒解析配置類你的后置處理器可能只看到了極少數(shù) BeanDefinition。4.3 registerBeanPostProcessors 到 registerListenersregisterBeanPostProcessors(beanFactory)負責(zé)注冊所有BeanPostProcessor。這一階段同樣按PriorityOrdered、Ordered、普通順序注冊。BeanPostProcessor的作用時機在 Bean 實例創(chuàng)建階段也就是populateBean和initializeBean時。這里要說一個很多人忽略的點BeanPostProcessor和BeanFactoryPostProcessor的注冊時機不同。后者在 Bean 實例創(chuàng)建之前執(zhí)行作用于 BeanDefinition前者在 Bean 實例創(chuàng)建過程中執(zhí)行作用于實例。理解這條界限對排查“為什么我的后置處理器沒生效”至關(guān)重要。接下來幾步相對輕量。initMessageSource()初始化國際化資源沒有配置就用默認的DelegatingMessageSource。initApplicationEventMulticaster()初始化事件廣播器默認是SimpleApplicationEventMulticaster。onRefresh()是模板方法給子類擴展用比如 Spring MVC 在這里初始化主題解析器。registerListeners()把容器里的ApplicationListenerBean 注冊到廣播器并補發(fā)啟動早期緩存的事件。4.4 finishBeanFactoryInitializationBean 真正實例化的開始finishBeanFactoryInitialization(beanFactory)是容器從“定義階段”進入“運行階段”的分水嶺。注釋寫得很明確實例化所有剩余的非懶加載單例 Bean。這一階段內(nèi)部的關(guān)鍵調(diào)用鏈是preInstantiateSingletons-getBean-doGetBean-createBean-doCreateBean。在doGetBean中Spring 會先從三級緩存singletonObjects、earlySingletonObjects、singletonFactories中查找。如果沒找到再去創(chuàng)建。創(chuàng)建過程在doCreateBean里分幾步實例化構(gòu)造器或工廠方法、暴露到三級緩存允許提前引用、populateBean填充屬性、initializeBean執(zhí)行初始化方法。populateBean會應(yīng)用InstantiationAwareBeanPostProcessor其中就包括處理Autowired的AutowiredAnnotationBeanPostProcessor。initializeBean會依次執(zhí)行 Aware 接口回調(diào)、BeanPostProcessor.postProcessBeforeInitialization、afterPropertiesSet/PostConstruct/init-method、BeanPostProcessor.postProcessAfterInitialization。這一步執(zhí)行完畢之后業(yè)務(wù) Bean 才算真正可用。4.5 finishRefresh發(fā)出容器啟動完成事件最后一步finishRefresh()做收尾工作清理資源緩存、初始化LifecycleProcessor、調(diào)用onRefresh()觸發(fā) Lifecycle Bean 的啟動、發(fā)布ContextRefreshedEvent事件。ContextRefreshedEvent是 Spring 容器啟動完成的信號。我們經(jīng)常用ApplicationListenerContextRefreshedEvent在容器啟動后執(zhí)行初始化數(shù)據(jù)、預(yù)熱緩存等操作就是掛在這一步之后。從源碼順序看這個事件是在所有單例 Bean 都創(chuàng)建完成后才發(fā)布的所以監(jiān)聽器里可以放心地Autowired任何容器 Bean不會出現(xiàn)“Bean 還沒創(chuàng)建好就去用”的情況。把十二步串起來看refresh()就像是容器的一張執(zhí)行清單。每一步都有明確職責(zé)順序也經(jīng)過精心設(shè)計狀態(tài)準備在前BeanDefinition 處理在后實例化再往后最后收尾發(fā)布事件。這張清單值得多看幾遍讀懂了它IOC 容器就不再有黑盒。5. Configuration 增強機制CGLIB 代理與 Full/Lite 模式詳解5.1 為什么要對配置類做增強ConfigurationClassPostProcessor解析完配置類還會做一件很有意思的事對Configuration類進行 CGLIB 增強。ConfigurationClassEnhancer會給配置類生成一個子類代理攔截Bean方法的調(diào)用。為什么要攔截看一個典型例子Configuration public class AppConfig { Bean public DataSource dataSource() { return new DataSource(); } Bean public JdbcTemplate jdbcTemplate() { return new JdbcTemplate(dataSource()); } }jdbcTemplate()方法內(nèi)部調(diào)用了dataSource()。如果配置類不被代理這個調(diào)用會直接執(zhí)行原方法每次調(diào)用都new DataSource()產(chǎn)生一個全新的對象。結(jié)果就是jdbcTemplate里用的 DataSource 和容器中的dataSourceBean 不是同一個實例單例語義被破壞。有了 CGLIB 代理后對dataSource()的調(diào)用會被攔截。代理會先去容器里查dataSourceBean如果已經(jīng)創(chuàng)建就直接返回沒創(chuàng)建就先創(chuàng)建再返回。這樣無論內(nèi)部怎么互相調(diào)用所有Bean方法返回的都是容器管理的單例對象。5.2 proxyBeanMethodsfalse 什么時候用從 Spring 5.2 開始Configuration注解增加了proxyBeanMethods屬性默認是 true也就是默認走 CGLIB 代理。如果設(shè)置為 false配置類就是“Lite 模式”不會被 CGLIB 增強。那什么時候可以關(guān)掉關(guān)鍵看配置類內(nèi)部是否有Bean方法之間的互相調(diào)用。如果不互相調(diào)用只是各自獨立創(chuàng)建 Bean那么代理就沒有必要。關(guān)掉之后有三個好處啟動階段少了 CGLIB 增強的開銷配置類不再要求能被繼承子類代理必須要繼承final 類也能用了Bean方法可以是 final 的。我這里給一個經(jīng)驗如果你只是單純用 Java 配置類把Bean方法列出來方法里沒有互相調(diào)用proxyBeanMethods false是非常安全的優(yōu)化。一旦配置類里有Bean方法互相調(diào)用且依賴單例語義就必須保持默認 true。5.3 Bean 方法里互相調(diào)用的坑既然提到互相調(diào)用就多說一句踩坑記錄。有人會在Component類里寫B(tài)ean方法這樣配置類不會被 CGLIB 增強內(nèi)部調(diào)用Bean方法每次都會新建對象。這種代碼跑起來不一定報錯但單例會悄悄失效很難排查。還有個坑是Configuration類里注入依賴時直接注入配置類類型。由于配置類本身被 CGLIB 代理注入的類型和期望的類型對不上時會拋出BeanNotOfRequiredTypeException。不過一般場景不會注入整個配置類更常見的是注入配置類中某個Bean方法產(chǎn)生的對象這種沒有這個問題。我記得有一次排查一個“DataSource 被創(chuàng)建了兩次”的問題根源就是配置類被 Lite 化處理某處代碼直接new了配置類再調(diào)用Bean方法。如果想避免這種問題盡量保證所有地方都從容器拿 Bean而不是手動new配置類。6. 把源碼變成排查工具三個常見問題的根因分析6.1 循環(huán)依賴到底是怎么被三級緩存解決的循環(huán)依賴是面試高頻題也是線上排查的重災(zāi)區(qū)。Spring 解決循環(huán)依賴的核心在DefaultSingletonBeanRegistry里的三級緩存singletonObjects一級緩存存的是完整初始化后的單例 Bean。earlySingletonObjects二級緩存存的是提前暴露的早期引用可能還沒完成屬性填充。singletonFactories三級緩存存的是 ObjectFactory通過它可以拿到早期引用。流程大致是這樣A 創(chuàng)建時實例化完成后會把ObjectFactory放入三級緩存。A 在populateBean填充屬性時發(fā)現(xiàn)依賴 B于是去創(chuàng)建 B。B 創(chuàng)建時填充屬性發(fā)現(xiàn)依賴 A此時從三級緩存取到 A 的ObjectFactory調(diào)用getEarlyBeanReference得到 A 的早期引用放入二級緩存注入給 B。B 創(chuàng)建完成后A 拿到 B 的完整引用繼續(xù)完成初始化。最后 A 初始化完畢從一級緩存返回。為什么需要三級緩存而不是二級關(guān)鍵原因和 BeanPostProcessor 有關(guān)。某些SmartInstantiationAwareBeanPostProcessor比如 AOP 相關(guān)的在getEarlyBeanReference時可能生成代理對象。如果把原始實例直接放進二級緩存后續(xù)就沒法再做代理增強。三級緩存存的是一個工廠真正需要早期引用時才觸發(fā)代理邏輯這樣就兼顧了性能和正確性。構(gòu)造器注入的循環(huán)依賴為什么解決不了因為在構(gòu)造器階段對象還沒創(chuàng)建完成還沒把ObjectFactory暴露到三級緩存。Spring 在查找依賴時發(fā)現(xiàn)緩存里沒有會嘗試繼續(xù)創(chuàng)建從而形成死循環(huán)最終報BeanCurrentlyInCreationException。遇到構(gòu)造器循環(huán)依賴可以用Lazy注入代理來拆解。6.2 Autowired 為 null 或失效時的排查思路遇到Autowired字段為 null很多人的第一反應(yīng)是“是不是容器沒掃到這個類”。這當然是一部分原因但從源碼角度排查可以按下面的順序來。第一查 BeanDefinition 是否注冊。在DefaultListableBeanFactory里打斷點看beanDefinitionNames里有沒有目標類。沒有就查掃描路徑是否正確、ComponentScan是否覆蓋到目標包、類上是否有Component族注解。第二查是否被過濾規(guī)則排除。如果自定義了 TypeFilter檢查過濾規(guī)則是否誤傷。第三查是否在 BeanPostProcessor 注冊之后手動 new 了對象。Autowired只對容器管理的 Bean 生效自己 new 出來的對象沒有經(jīng)過populateBean字段當然不會注入。第四查作用域。如果是 prototype 作用域每次獲取都是新對象需要確認獲取時機。如果是在容器啟動早期手動獲取可能 Bean 還沒創(chuàng)建完成。還有一個常見現(xiàn)象在static字段上加Autowired永遠為 null。原因從源碼看很直接AutowiredAnnotationBeanPostProcessor的postProcessProperties是面向?qū)嵗膕tatic 字段不屬于某個具體實例Spring 根本沒打算處理它。如果要注入靜態(tài)資源建議用 setter 方法在啟動時手動賦值或者重新設(shè)計一下依賴結(jié)構(gòu)。6.3 進階實戰(zhàn)自定義 BeanDefinitionRegistryPostProcessor 注冊 Bean理解了invokeBeanFactoryPostProcessors的時機之后你可以利用源碼知識做一件事在容器啟動早期動態(tài)注冊一個新的 BeanDefinition。這個技巧在中間件集成、動態(tài)擴展場景下很實用。先寫一個處理器Component public class DynamicBeanRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor { Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException { GenericBeanDefinition definition new GenericBeanDefinition(); definition.setBeanClassName(CacheService.class.getName()); definition.setScope(ConfigurableBeanFactory.SCOPE_SINGLETON); registry.registerBeanDefinition(cacheService, definition); System.out.println(registered cacheService: registry.containsBeanDefinition(cacheService)); } Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { // 可以在這里修改 beanFactory 的配置比如設(shè)置 ignoreDependencyInterface } }再定義一個普通的CacheService類不加任何注解。啟動容器后通過context.getBean(CacheService.class)能拿到實例因為 BeanDefinition 已經(jīng)在postProcessBeanDefinitionRegistry階段被注冊后續(xù)finishBeanFactoryInitialization會正常實例化它。這個機制能做什么比如從數(shù)據(jù)庫或配置中心讀取一段配置動態(tài)決定要不要注冊某個 Bean、注冊多少個 Bean、BeanClass 是什么。這些場景下寫死在ComponentScan里反而不靈活動態(tài)注冊 BeanDefinition 就成了更合適的方案。核心要點只有一個把握住執(zhí)行時機確保注冊操作發(fā)生在 BeanDefinition 處理階段。7. 高效閱讀 Spring 源碼的斷點與路線圖7.1 合適的入口斷點哪里打讀源碼最怕亂翻。我的建議是第一遍先只打一個斷點AbstractApplicationContext.refresh()。這一步是容器初始化的主干所有后續(xù)流程都由它驅(qū)動。跟著調(diào)用棧往下走一遍先把十二步整體過一遍。第二遍再進細節(jié)。推薦的斷點位置AnnotationConfigApplicationContext構(gòu)造方法看容器如何創(chuàng)建 reader/scanner。ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry看配置解析的起點。ConfigurationClassParser.doProcessConfigurationClass看配置類的解析步驟包括ComponentScan、Import、Bean的逐個處理。DefaultListableBeanFactory.registerBeanDefinition看 BeanDefinition 注冊到容器的入口。AbstractAutowireCapableBeanFactory.doCreateBean看 Bean 實例化的全過程。DefaultSingletonBeanRegistry.getSingleton看三級緩存的查找邏輯。有了這些斷點你在實際調(diào)試一個 Demo 時可以帶著“當前執(zhí)行到哪一步了”的意識配合Evaluate Expression查看上下文信息比干讀源碼效率高很多。7.2 源碼閱讀路線圖如果按路線圖來我建議分四條線走。第一條線是入口線從AnnotationConfigApplicationContext構(gòu)造方法開始走到refresh()整體把握容器啟動流程。第二條線是配置解析線從ConfigurationClassPostProcessor開始進入ConfigurationClassParser看它是如何逐個處理配置類注解的。這一線是注解驅(qū)動開發(fā)的核心。第三條線是實例化線從finishBeanFactoryInitialization進入preInstantiateSingletons再到getBean、doGetBean、createBean、doCreateBean完整看一遍 Bean 從無到有的過程。這條線對理解生命周期、循環(huán)依賴至關(guān)重要。第四條線是生命周期線從doCreateBean里的populateBean和initializeBean入手看 BeanPostProcessor 是如何嵌入實例化和初始化過程的。這條線真正體現(xiàn)了“Spring 的可擴展性是怎么設(shè)計出來的”。四條線之間有交叉但每條線都有清晰主線。按照這條路線讀下來我自己的體會是比零散看源碼要快得多。7.3 調(diào)試過程中容易誤判的現(xiàn)象調(diào)試 Spring 源碼有兩個容易讓人誤判的點我提一下。第一個是getBeanNamesForType會提前觸發(fā) Bean 創(chuàng)建。在調(diào)試時你可能會發(fā)現(xiàn)在preInstantiateSingletons之前某些 Bean 已經(jīng)被實例化了。原因是getBeanNamesForType內(nèi)部需要確定類型可能觸發(fā)getBean。所以不要看到有 Bean 創(chuàng)建就以為容器已經(jīng)開始實例化了要確認觸發(fā)時機。第二個是 BeanPostProcessor 的執(zhí)行順序很容易被忽略。多個BeanPostProcessor之間有順序如果你的后置處理器依賴其他處理器先執(zhí)行建議實現(xiàn)Ordered或PriorityOrdered來保證順序。否則調(diào)試時看到的現(xiàn)象會非常隨機因為 Bean 創(chuàng)建順序本身不是嚴格按代碼書寫順序來的。最后一個建議讀源碼一定要配一個最小的可執(zhí)行 Demo。光看不練很容易看著看著就迷失在調(diào)用棧里。我通常會在項目里放一個空的AnnotationConfigApplicationContext啟動類所有斷點都掛在源碼上跑一遍觀察每一步的 BeanDefinitionNames 變化。把這一步做完你再回頭看那些 IOC 的面試題和線上問題會發(fā)現(xiàn)它們變成了一條清晰的邏輯鏈。