1. 為什么值得把啟動流程啃透——面試只是最表面的理由如果你搞過一段時(shí)間SpringBoot大概率被問過SpringBoot的啟動流程是什么這類問題。說實(shí)話這個(gè)問題在面試?yán)锍霈F(xiàn)的頻率非常高但它絕對不只是面試題那么簡單。我在實(shí)際生產(chǎn)環(huán)境里排查過好幾次詭異故障——應(yīng)用啟動后端口遲遲不監(jiān)聽、某些Bean在啟動階段莫名報(bào)錯(cuò)、配置項(xiàng)總是被意外覆蓋——最后追根溯源都得回到啟動流程上找原因。SpringBoot的啟動流程本質(zhì)上回答了一個(gè)核心問題一個(gè)只有幾十行代碼的main方法是怎么變成一個(gè)包含內(nèi)嵌Tomcat、數(shù)據(jù)庫連接池、各種自動配置、Bean管理體系、Web接口全部就緒的完整應(yīng)用的。這中間不是SpringBoot自己施法完成的而是SpringFramework的IoC容器啟動邏輯和SpringBoot的自動裝配機(jī)制、環(huán)境準(zhǔn)備機(jī)制、內(nèi)嵌服務(wù)器機(jī)制按特定順序組合運(yùn)行的產(chǎn)物。把這條線理順你對整個(gè)Spring生態(tài)的理解會上一個(gè)臺階。這篇文章我會從SpringApplication的構(gòu)造開始沿著run方法一路往下走把每一步做了什么、為什么在這個(gè)時(shí)機(jī)做、哪些地方容易出問題都拆開講清楚。內(nèi)容偏原理但我盡量用大白話和實(shí)際案例說話保證你能一邊看一邊在腦子里把整個(gè)執(zhí)行鏈路串起來。2. 從main方法到SpringApplication初始化——你以為的起點(diǎn)不是真起點(diǎn)很多人在項(xiàng)目里看到這樣的代碼覺得應(yīng)用就是從這行開始跑的SpringBootApplication public class MyApplication { public static void main(String[] args) { SpringApplication.run(MyApplication.class, args); } }這句話本身沒問題但啟動流程真正開始的位置要往前推一步。SpringApplication.run是一個(gè)靜態(tài)方法它內(nèi)部先要創(chuàng)建一個(gè)SpringApplication實(shí)例然后再調(diào)用實(shí)例的run方法。也就是說啟動流程的第一段其實(shí)是SpringApplication對象的構(gòu)造過程。2.1 SpringApplication構(gòu)造階段的關(guān)鍵推斷邏輯SpringApplication的構(gòu)造函數(shù)會做四件關(guān)鍵事情推斷WebApplicationType通過classpath下是否存在org.springframework.web.reactive.DispatcherHandler、org.springframework.web.servlet.DispatcherServlet、org.springframework.web.context.ConfigurableWebApplicationContext等類將應(yīng)用類型判定為NONE、SERVLET或REACTIVE。這個(gè)過程用的是ClassNameUtils的預(yù)設(shè)類名集合做存在性檢查不是new出來再看性能開銷極小。加載BootstrapRegistryInitializer從spring.factories中讀取所有BootstrapRegistryInitializer實(shí)現(xiàn)這個(gè)是SpringBoot 2.4.0之后引入的新機(jī)制用于在啟動早期階段做額外注冊。加載ApplicationContextInitializer同樣從spring.factories中讀取這些初始化器會在ApplicationContext準(zhǔn)備完成后、refresh之前被調(diào)用。她們負(fù)責(zé)做一些定制化操作比如設(shè)置Environment的默認(rèn)profile、注冊額外的BeanFactoryPostProcessor等。加載ApplicationListener從spring.factories中讀取所有的ApplicationListener實(shí)現(xiàn)這些監(jiān)聽器會在啟動流程的不同階段收到事件通知比如ApplicationStartedEvent、ApplicationReadyEvent、ApplicationFailedEvent。這四步的共同點(diǎn)是讀取并緩存配置都是在為后續(xù)的run階段做準(zhǔn)備。你可能注意到這里文件都在用spring.factories——雖說SpringBoot 2.7開始推薦用AutoConfiguration.imports文件加載自動配置類但ApplicationListener、ApplicationContextInitializer、EnvironmentPostProcessor這些基礎(chǔ)設(shè)施至今仍主要走spring.factories。2.2 構(gòu)造階段的坑為什么說主啟動類位置不能亂放我在排查一些項(xiàng)目問題時(shí)發(fā)現(xiàn)很多人對主啟動類放哪個(gè)包不太在意。其實(shí)主啟動類的位置直接決定了默認(rèn)的組件掃描根路徑——SpringBootApplication上內(nèi)置的ComponentScan如果不顯式指定basePackages默認(rèn)就以主啟動類所在包為掃描根。所以我見過的情況是把主啟動類放在頂層包結(jié)果掃描范圍一下鋪到整個(gè)項(xiàng)目啟動時(shí)加載了大量不該加載的Bean啟動速度慢不說偶爾還會出現(xiàn)Bean類型沖突。更隱蔽的一個(gè)坑是主啟動類被放在某個(gè)子包里導(dǎo)致兄弟包里的RestController、Service全部沒掃到表現(xiàn)就是啟動成功但接口404。這種問題排查起來最費(fèi)時(shí)間因?yàn)槟愕谝环磻?yīng)不會去懷疑啟動類的擺放位置。實(shí)際上啟動類放在哪本質(zhì)上是配置了掃描邊界這個(gè)邊界在啟動階段直接影響后續(xù)的ComponentScan執(zhí)行范圍。3. run方法的前半段監(jiān)聽器、環(huán)境與Banner如何交織實(shí)例構(gòu)造完成之后SpringApplication.run(String... args)方法就登場了。這個(gè)方法的內(nèi)容在SpringBoot不同版本里略有差異但主干邏輯相當(dāng)穩(wěn)定。我以SpringBoot 2.7.x為例按執(zhí)行順序拆開說。3.1 啟動計(jì)時(shí)與運(yùn)行監(jiān)聽器run方法最先做的事情是創(chuàng)建StopWatch。這個(gè)名字很直白就是個(gè)秒表。之后調(diào)用SpringApplicationRunListeners對象的starting()方法。SpringApplicationRunListeners不是單個(gè)監(jiān)聽器而是一組SpringApplicationRunListener的集合。它和ApplicationListener的區(qū)別在于SpringApplicationRunListener專門監(jiān)聽SpringApplication啟動過程中的九個(gè)階段starting、environmentPrepared、contextPrepared、contextLoaded、started、ready、failed等更偏啟動生命周期ApplicationListener則是SpringFramework的通用事件機(jī)制監(jiān)聽的是ApplicationEvent。這個(gè)階段最常見的用途是實(shí)現(xiàn)啟動耗時(shí)打點(diǎn)。我在自己的基礎(chǔ)框架里就實(shí)現(xiàn)過一個(gè)SpringApplicationRunListener在starting階段記錄啟動時(shí)間、在ready階段計(jì)算總耗時(shí)并輸出到監(jiān)控日志。要注冊這個(gè)監(jiān)聽器還是在spring.factories里加配置org.springframework.boot.SpringApplicationRunListenercom.example.support.CustomRunListener然后寫一個(gè)構(gòu)造方法簽名匹配SpringApplication, String[]的實(shí)現(xiàn)類即可。3.2 Environment準(zhǔn)備階段配置來源的合并順序接下來是配置準(zhǔn)備的重頭戲。prepareEnvironment方法會做以下這些事根據(jù)啟動參數(shù)創(chuàng)建ApplicationArguments對象供后續(xù)代碼通過getApplicationArguments()獲取main方法的原始參數(shù)。創(chuàng)建或獲取ConfigurableEnvironment對于Servlet類型的Web應(yīng)用通常是StandardServletEnvironment。配置環(huán)境的一些必要屬性spring.main.*系列配置會在這一步被讀取并應(yīng)用比如spring.main.web-application-type、spring.main.lazy-initialization等。如果有EnvironmentPostProcessor會在這里統(tǒng)一執(zhí)行。這是非常強(qiáng)大的擴(kuò)展點(diǎn)配置中心、加密配置解密器基本都是靠它實(shí)現(xiàn)的。很多人在這一步栽過的跟頭是配置覆蓋順序搞混。SpringBoot的PropertySource是有優(yōu)先級的大概從高到低是這樣優(yōu)先級配置來源最高Devtools全局配置~/.spring-boot-devtools.properties高TestPropertySource注解測試場景高命令行參數(shù)--server.port8081這種高SPRING_APPLICATION_JSON內(nèi)嵌JSON中ServletConfig / ServletContext參數(shù)中JNDI屬性中Java System PropertiesSystem.getProperties()中操作系統(tǒng)環(huán)境變量中RandomValuePropertySourcerandom.*占位符低jar包外的application-{profile}.properties/yml低jar包內(nèi)的application-{profile}.properties/yml更低jar包外的application.properties/yml最低jar包內(nèi)的application.properties/yml注意一個(gè)容易被忽略的點(diǎn)同名的application.ymljar包外的配置會覆蓋jar包內(nèi)的。這個(gè)機(jī)制在生產(chǎn)環(huán)境非常有用——不用重新打包就能調(diào)整配置——但也經(jīng)常造成本地跑得好好的服務(wù)器上配置不生效的奇怪現(xiàn)象。3.3 Banner、Headless屬性與ApplicationContext創(chuàng)建環(huán)境準(zhǔn)備完成后run方法會打印Banner。這一步的擴(kuò)展點(diǎn)在Banner接口上你想自定義啟動圖案可以實(shí)現(xiàn)這個(gè)接口并配置spring.banner.location指向自己的banner文件。熱詞里提到的SpringBoot banner生成器就是這樣來的——它生成的其實(shí)就是一個(gè)文本文件SpringBoot啟動時(shí)會把它打印到控制臺。另外spring.main.banner-modeoff可以關(guān)掉它某些生產(chǎn)環(huán)境為了日志干凈會這么設(shè)置。緊接著是一個(gè)不起眼但很重要的小操作configureHeadlessProperty。它會設(shè)置java.awt.headlesstrue確保應(yīng)用在沒有鍵盤鼠標(biāo)顯示器的服務(wù)器環(huán)境下也能正常運(yùn)行某些AWT類。這一步絕大多數(shù)人感知不到但它解釋了為什么Headless模式是SpringBoot的默認(rèn)行為。再往下是createApplicationContext。這個(gè)方法根據(jù)WebApplicationType類型創(chuàng)建對應(yīng)的ApplicationContext實(shí)現(xiàn)如果是SERVLET類型創(chuàng)建AnnotationConfigServletWebServerApplicationContext如果是REACTIVE類型創(chuàng)建AnnotationConfigReactiveWebServerApplicationContext如果是NONE類型創(chuàng)建AnnotationConfigApplicationContext這些類都是GenericApplicationContext的子類其中Servlet版本就繼承了內(nèi)嵌Web服務(wù)器的能力。SpringBoot語境里的啟動流程在創(chuàng)建ApplicationContext這一步開始與SpringFramework重疊了。4. refresh()整個(gè)流程的實(shí)權(quán)部門——SpringBoot在這里動了什么手腳ApplicationContext創(chuàng)建好以后啟動流程進(jìn)入最關(guān)鍵的一環(huán)refreshContext(context)。這個(gè)方法內(nèi)部調(diào)用的其實(shí)就是SpringFramework中AbstractApplicationContext的refresh()模板方法。如果你讀過Spring源碼就會知道refresh()方法是SpringIoC容器啟動的核心流程一共12個(gè)步驟。SpringBoot的討巧之處在于它不重寫這個(gè)方法而是通過子類覆寫其中特定的模板方法把自己的邏輯塞進(jìn)SpringFramework既有的流程里。這種在不改變骨架的前提下替換零件的設(shè)計(jì)思路是理解SpringBoot與Spring關(guān)系的關(guān)鍵。4.1 12步refresh流程里SpringBoot重點(diǎn)插手的位置refresh()的主要步驟和SpringBoot在其中的角色對應(yīng)關(guān)系如下表步驟方法SpringFramework做的事SpringBoot插手的事1prepareRefresh準(zhǔn)備刷新設(shè)置啟動時(shí)間、活躍狀態(tài)初始化屬性源在這里準(zhǔn)備WebApplicationContext相關(guān)的早期屬性2obtainFreshBeanFactory獲取/創(chuàng)建BeanFactory使用DefaultListableBeanFactory3prepareBeanFactory配置BeanFactory的標(biāo)準(zhǔn)特性比如ClassLoader、表達(dá)式解析器注冊WebApplicationContext相關(guān)的后置處理器4postProcessBeanFactory空實(shí)現(xiàn)模板方法注冊ServletContextAwareProcessor等5invokeBeanFactoryPostProcessors執(zhí)行BeanFactoryPostProcessorConfigurationClassPostProcessor在這里完成配置類解析和自動配置類導(dǎo)入6registerBeanPostProcessors注冊BeanPostProcessor無特殊7initMessageSource初始化MessageSource無特殊8initApplicationEventMulticaster初始化事件廣播器無特殊9onRefresh空實(shí)現(xiàn)模板方法創(chuàng)建并啟動內(nèi)嵌Web服務(wù)器10registerListeners注冊監(jiān)聽器無特殊11finishBeanFactoryInitialization實(shí)例化所有非懶加載的單例Bean完成所有Controller、Service的創(chuàng)建內(nèi)嵌Tomcat開始接收請求的準(zhǔn)備工作12finishRefresh完成刷新發(fā)布ContextRefreshedEvent啟動WebServer調(diào)用生命周期處理器第5步和第9步是SpringBoot影響最大的兩個(gè)位置。第5步里ConfigurationClassPostProcessor會解析所有配置類把spr自動配置類通過Import導(dǎo)入進(jìn)容器第9步里Servlet容器被創(chuàng)建并啟動端口開始監(jiān)聽。4.2 第5步為什么是自動裝配的關(guān)鍵戰(zhàn)場很多講SpringBoot啟動流程的文章講到invokeBeanFactoryPostProcessors就是一句執(zhí)行BeanFactory后置處理器帶過但這里是理解為什么SpringBoot能自動配置的重中之重。BeanFactoryPostProcessor是SpringFramework提供的擴(kuò)展點(diǎn)允許在Bean定義加載完成之后、Bean實(shí)例化之前對BeanDefinition進(jìn)行修改。ConfigurationClassPostProcessor實(shí)現(xiàn)了這個(gè)接口更準(zhǔn)確地說是BeanDefinitionRegistryPostProcessor它負(fù)責(zé)解析配置類上的Configuration、ComponentScan、Import、Bean等注解把這些注解展開成具體的BeanDefinition注冊進(jìn)容器。SpringBoot的自動配置類也是在這個(gè)階段被處理的。SpringBootApplication上的EnableAutoConfiguration注解最終會通過AutoConfigurationImportSelector選擇性地加載一批自動配置類——這個(gè)過程要走Import機(jī)制而Import的解析執(zhí)行者就是ConfigurationClassPostProcessor。所以你看到的效果是SpringBoot應(yīng)用啟動后容器里自動多出了數(shù)據(jù)源配置、MyBatis的SqlSessionFactory、RedisTemplate等Bean定義。實(shí)際上這些都是第5步里后置處理器把EnableAutoConfiguration展開后看到的一個(gè)個(gè)自動配置類再把它們內(nèi)部聲明的Bean方法轉(zhuǎn)為BeanDefinition實(shí)現(xiàn)的。4.3 第9步的onRefresh內(nèi)嵌Web服務(wù)器在這里被創(chuàng)建對于Web應(yīng)用來說onRefresh是SpringBoot啟動流程里最讓人興奮的環(huán)節(jié)之一。以Tomcat為例ServletWebServerApplicationContext重寫了onRefresh方法并在其中調(diào)用createWebServer()方法。它要做的決策是從容器里找到一個(gè)ServletWebServerFactory類型的Bean——SpringBoot自動裝配階段如果沒有人為干預(yù)會默認(rèn)注冊一個(gè)TomcatServletWebServerFactory——然后調(diào)用工廠的getWebServer(ServletContextInitializer...)方法。在這個(gè)方法內(nèi)部Tomcat實(shí)例被創(chuàng)建、配置端口、連接器、線程池參數(shù)Context和Servlet容器初始化最后tomcat.start()讓端口真正開始監(jiān)聽。這里有個(gè)非常實(shí)用的排查經(jīng)驗(yàn)如果項(xiàng)目里同時(shí)存在Tomcat的JAR包和Jetty的JAR包SpringBoot不會自己分辨用哪個(gè)而是拋出BeanDefinitionStoreException之類的沖突異常。解決方式是把不用的那個(gè)從依賴?yán)飁xclude掉或者顯式指定spring.main.web-application-type和對應(yīng)的Factory類型。很多人遇到多個(gè)ServletWebServerFactory Bean的報(bào)錯(cuò)就是因?yàn)檫@個(gè)。5. 自動裝配不是魔法Condition與ConfigurationClassPostProcessor的舞蹈既然提到了自動裝配是啟動流程中最關(guān)鍵的環(huán)節(jié)這一節(jié)專門展開講清楚。熱詞里的springboot自動裝配原理是每次面試都繞不開的點(diǎn)而它真正起作用的時(shí)機(jī)就在refresh的第5步。5.1 AutoConfiguration.imports文件的加載鏈路SpringBoot 2.7版本之后自動配置類的索引文件從META-INF/spring.factories遷移到了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。這個(gè)文件內(nèi)容的格式很簡單每行一個(gè)自動配置類的全限定類名com.example.starter.autoconfigure.DemoAutoConfiguration com.example.starter.autoconfigure.Demo2AutoConfigurationEnableAutoConfiguration通過AutoConfigurationImportSelector讀取這個(gè)文件然后對列表里的每個(gè)候選配置類做條件化處理。為什么用獨(dú)立文件而不是spring.factories官方給的理由是單獨(dú)文件更輕量、更容易解析而且避免了spring.factories里條目過多、不同模塊之間的干擾。我自己的理解是這也是一種性能優(yōu)化——啟動階段解析文件的開銷雖然不大但能少讀一點(diǎn)是一點(diǎn)。5.2 Conditional注解的評估時(shí)機(jī)與順序每個(gè)自動配置類上都有一堆Conditional相關(guān)注解比如AutoConfiguration ConditionalOnClass(RedisOperations.class) ConditionalOnMissingBean(name redisTemplate) public class RedisAutoConfiguration { Bean ConditionalOnMissingBean(name redisTemplate) public RedisTemplateObject, Object redisTemplate(RedisConnectionFactory redisConnectionFactory) { RedisTemplateObject, Object template new RedisTemplate(); template.setConnectionFactory(redisConnectionFactory); return template; } }這些條件注解的評估不是隨手就做的而是由ConditionEvaluator在配置類解析期間執(zhí)行。評估的核心邏輯是檢查類的條件ConditionalOnClassclasspath下有沒有指定類檢查Bean的條件ConditionalOnMissingBean/ConditionalOnBean容器中是否已經(jīng)存在某個(gè)BeanDefinition或Bean檢查屬性的條件ConditionalOnProperty指定的配置項(xiàng)是否為預(yù)期值這里有個(gè)容易踩坑的細(xì)節(jié)ConditionalOnBean和ConditionalOnMissingBean的判斷時(shí)機(jī)在配置類解析階段而當(dāng)時(shí)的容器里可能還沒注冊完所有BeanDefinition。所以如果同一個(gè)自動配置類里的兩個(gè)Bean方法互相依賴條件可能出現(xiàn)判斷不準(zhǔn)的情況。解決辦法是在Bean方法參數(shù)上聲明依賴讓Spring自動處理順序而不是靠條件的先后順序。5.3 自定義自動配置類的最小可運(yùn)行示例理解了原理后可以做一個(gè)最小的自定義自動配置類來驗(yàn)證整個(gè)鏈路。假設(shè)我要做一個(gè)DemoService的自動配置包第一步編寫自動配置類AutoConfiguration ConditionalOnClass(DemoService.class) ConditionalOnProperty(prefix demo, name enabled, havingValue true, matchIfMissing true) public class DemoAutoConfiguration { Bean ConditionalOnMissingBean public DemoService demoService() { return new DemoService(auto-configured-demo); } }第二步創(chuàng)建META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件內(nèi)容為com.example.demo.autoconfigure.DemoAutoConfiguration第三步在一個(gè)普通SpringBoot項(xiàng)目里引入這個(gè)包啟動后就能看到DemoService被自動注冊了。這就是SpringBoot啟動流程中第5步解析配置類時(shí)發(fā)生的事——你的自定義自動配置類和SpringBoot內(nèi)置的自動配置類走的是完全相同的通道。6. 從Bean實(shí)例化到Web服務(wù)器就緒——啟動尾段的重要細(xì)節(jié)refresh的第11步finishBeanFactoryInitialization是量變引發(fā)質(zhì)變的節(jié)點(diǎn)。在這之前所有的BeanDefinition已經(jīng)注冊所有的BeanFactoryPostProcessor已經(jīng)運(yùn)行完BeanPostProcessor也準(zhǔn)備好了。從這一步開始容器會遍歷所有非懶加載的單例BeanDefinition逐個(gè)實(shí)例化。6.1 單例Bean的實(shí)例化順序由什么決定Spring在實(shí)例化單例Bean時(shí)并不是按照BeanDefinition的注冊順序盲目new。它會先把滿足條件的BeanDefinition放入一個(gè)List通過AnnotationAwareOrderComparator排序——也就是說實(shí)現(xiàn)了Ordered接口或標(biāo)注了Order注解的Bean可以控制實(shí)例化順序。但大多數(shù)Bean之間其實(shí)沒有顯式順序依賴Spring會按照依賴關(guān)系自動構(gòu)建A依賴B那就先實(shí)例化B再實(shí)例化A。這個(gè)階段最常見的報(bào)錯(cuò)就是循環(huán)依賴。比如A和B互相注入Spring在默認(rèn)情況下單例、非構(gòu)造器注入能通過三級緩存機(jī)制解決——這是Spring閉環(huán)能力的體現(xiàn)。但如果你把其中一方改成了構(gòu)造器注入或者把spring.main.allow-circular-references設(shè)置為false循環(huán)依賴就會直接拋出BeanCurrentlyInCreationException。我處理的幾個(gè)生產(chǎn)故障里有一起就是重構(gòu)時(shí)把字段注入改成了構(gòu)造器注入結(jié)果原本正常的循環(huán)依賴立刻爆雷。實(shí)際經(jīng)驗(yàn)是比起想盡辦法繞過循環(huán)依賴不如從設(shè)計(jì)上消除它——該拆的模塊拆開該用事件驅(qū)動用的用事件驅(qū)動別指望Spring幫你兜底。6.2 onRefresh與finishBeanFactoryInitialization誰先誰后這里有個(gè)順序關(guān)系值得單獨(dú)強(qiáng)調(diào)Web服務(wù)器在onRefresh里先被創(chuàng)建并啟動端口監(jiān)聽但此時(shí)DispatcherServlet等Web相關(guān)的Bean可能還沒完成實(shí)例化。SpringBoot的巧妙處理是Tomcat啟動時(shí)不會馬上對外提供服務(wù)——實(shí)際上這時(shí)候請求進(jìn)來也是能監(jiān)聽到TCP連接的只是業(yè)務(wù)鏈路還沒完全就緒。真正可以接受請求的狀態(tài)要到refresh完成之后、ApplicationReadyEvent發(fā)布之前的那一瞬間才成立。這也是為什么你通過健康檢查腳本探測端口時(shí)端口雖然已經(jīng)通了但應(yīng)用還沒完全ready需要再等一小會兒才返回UP。很多部署腳本踩過這個(gè)坑端口一監(jiān)聽就立刻發(fā)流量結(jié)果應(yīng)用還在執(zhí)行ApplicationRunner或初始化緩存導(dǎo)致首批請求超時(shí)。6.3 ApplicationRunner與CommandLineRunner啟動收尾的鉤子refresh方法執(zhí)行完后run方法會發(fā)布ApplicationStartedEvent緊接著執(zhí)行callRunners。這一步SpringBoot會把容器里所有的ApplicationRunner和CommandLineRunner找出來依次執(zhí)行它們的run方法。兩者的區(qū)別很簡單ApplicationRunner的run方法接收一個(gè)封裝好的ApplicationArguments對象可以方便地獲取參數(shù)名和參數(shù)值CommandLineRunner的run方法接收原始String數(shù)組稍顯原始兩者的執(zhí)行順序同樣可以通過Order注解控制。在實(shí)際項(xiàng)目中我習(xí)慣把數(shù)據(jù)初始化、緩存預(yù)熱、敏感信息加載等操作放進(jìn)ApplicationRunner里做因?yàn)樗膮?shù)處理更友好。但要記住這些Runner的執(zhí)行是同步的如果它內(nèi)部長時(shí)間阻塞應(yīng)用雖然已經(jīng)啟動完成但一直等不到ApplicationReadyEvent健康檢查會一直處于DOWN狀態(tài)。7. 啟動階段高頻故障排查實(shí)錄從現(xiàn)象逆推流程中的斷點(diǎn)講完整個(gè)啟動鏈路我?guī)Т蠹铱磶讉€(gè)真實(shí)場景用從現(xiàn)象反推流程斷點(diǎn)的思路來復(fù)盤。這也是我寫這篇文章的初衷——啟動流程不是背出來的八股文而是排查問題時(shí)的導(dǎo)航地圖。7.1 端口能通但404——問題多半出在ComponentScan現(xiàn)象應(yīng)用日志顯示啟動成功Tomcat端口正常監(jiān)聽但訪問任何接口都返回404。排查鏈路先確認(rèn)DispatcherServlet有沒有被創(chuàng)建。如果在日志里看不到RequestMappingHandlerMapping注冊的接口信息說明Spring MVC的配置沒有生效。檢查SpringBootApplication所在類的位置。如果主啟動類放在com.example.admin而Controller在com.example.web默認(rèn)的組件掃描就掃不到Controller。再看是不是有多個(gè)ApplicationContext。如果引入了某些老框架它可能自己創(chuàng)建了一個(gè)獨(dú)立的WebApplicationContext接口注冊到了另一個(gè)容器里。最后檢查spring.mvc.servlet.path或server.servlet.context-path配置。這個(gè)配置如果被誤設(shè)接口路徑整體加前綴也表現(xiàn)為404。這個(gè)問題的根源本質(zhì)上就是啟動流程第5步的組件掃描邊界出了問題。主啟動類位置決定了掃描根這一點(diǎn)我再強(qiáng)調(diào)一次。7.2 啟動卡在Root WebApplicationContext: initialization completed現(xiàn)象日志停在這一行之后長時(shí)間沒有進(jìn)展進(jìn)程不退出也不報(bào)錯(cuò)。排查鏈路這一個(gè)卡住的階段對應(yīng)的是refresh第9步之后、第11步之前——也就是onRefresh創(chuàng)建Web服務(wù)器之后的Bean實(shí)例化階段。最可能的原因是某個(gè)Bean的構(gòu)造器或PostConstruct方法里有阻塞操作比如等待數(shù)據(jù)庫連接、調(diào)用外部RPC接口超時(shí)、遞歸初始化死循環(huán)。用jstack導(dǎo)出線程棧看阻塞點(diǎn)落在哪個(gè)類的哪個(gè)方法一擊命中。我遇到過的典型案例是一個(gè)連接池預(yù)熱的PostConstruct方法它在啟動時(shí)嘗試建立100個(gè)數(shù)據(jù)庫連接但數(shù)據(jù)庫連接池的最大連接數(shù)配置只有50結(jié)果互相等待直到連接超時(shí)。解決方式是調(diào)整預(yù)熱邏輯把同步預(yù)熱改成異步或者先設(shè)一個(gè)較大的連接池上限。7.3 多個(gè)ServletWebServerFactory的Bean沖突現(xiàn)象啟動直接報(bào)錯(cuò)提示有一個(gè)以上ServletWebServerFactory類型的Bean。排查鏈路檢查classpath里是不是同時(shí)引入了spring-boot-starter-tomcat和spring-boot-starter-jetty。保留一個(gè)排除另一個(gè)dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jetty/artifactId /dependency如果你需要兩種服務(wù)器共存比如一個(gè)負(fù)責(zé)REST、一個(gè)負(fù)責(zé)內(nèi)部管理接口可以手動配置兩個(gè)ServletWebServerFactory并分別指定端口但這是高級玩法不建議新手一上來就嘗試。這個(gè)沖突點(diǎn)發(fā)生在自動裝配階段兩個(gè)Factory都被注冊成Bean了第9步onRefresh要找一個(gè)時(shí)發(fā)現(xiàn)有兩個(gè)候選只能拋異常。理解了流程斷點(diǎn)你看到這種報(bào)錯(cuò)根本不需要翻日志直接去依賴?yán)锊橹丶纯伞?.4 版本太高類問題與啟動日志中的密文配置解密熱詞里有一條springboot版本太高這其實(shí)是真實(shí)存在的問題SpringBoot 3.x要求JDK 17如果項(xiàng)目還在用JDK 8強(qiáng)行升級必然啟動失敗另外某些第三方starter的版本跟不上SpringBoot大版本升級也會出現(xiàn)自動配置類的方法簽名不兼容啟動時(shí)拋NoSuchMethodError、ClassNotFoundException。還有一種情況SpringBoot 3.x里javax.*包換成了jakarta.*包如果你的老代碼里還有import javax.servlet.*啟動時(shí)根本過不了編譯。這些問題都能追溯到啟動流程第1步之前的依賴準(zhǔn)備階段——main方法都還沒進(jìn)呢類加載就失敗了。至于springboot yml密文常見做法是在配置準(zhǔn)備階段用EnvironmentPostProcessor解密帶特定前綴的配置值。解密動作發(fā)生在PropertySource加載完成之后、各Bean真正讀取配置之前這樣保證所有地方拿到的都是明文。如果你打算自己實(shí)現(xiàn)記住EnvironmentPostProcessor要注冊在spring.factories里而且不要在實(shí)現(xiàn)里依賴任何Spring容器的Bean——因?yàn)樗旧韴?zhí)行得很早容器還沒完成裝配。7.5 啟動慢的排查要點(diǎn)再補(bǔ)充一個(gè)所有項(xiàng)目都可能遇到的啟動速度慢。從啟動流程的角度看慢的地方通常是這幾塊ComponentScan掃描的包太多這個(gè)可以用spring-context-indexer生成候選組件索引來緩解finishBeanFactoryInitialization階段實(shí)例化的單例Bean太多可以考慮把不急著用的Bean改為懶加載或者用spring.main.lazy-initializationtrue全局開啟但要注意副作用懶加載Bean在首次使用時(shí)才創(chuàng)建可能把啟動期故障延遲到運(yùn)行期才暴露自動配置類評估了大量ConditionalOnClass雖然每個(gè)檢查很快但量多了也有開銷?？梢酝ㄟ^排除用不上的自動配置類來提速比如SpringBootApplication(exclude {DataSourceAutoConfiguration.class})8. 最后再說兩點(diǎn)實(shí)際體會啟動流程我讀了不下五遍每一遍都有新的收獲。第一次讀是背面試題知道run方法會調(diào)refresh、refresh里有12個(gè)步驟第二次是排查線上啟動失敗開始去理解每一步之間誰先誰后、某個(gè)異常出現(xiàn)在哪兩個(gè)斷點(diǎn)之間第三次是寫自己的starter、做公司基礎(chǔ)框架的時(shí)候猛然意識到自動裝配的本質(zhì)就是在特定時(shí)機(jī)把BeanDefinition批量注冊進(jìn)去。這個(gè)境界的提升和具體的技術(shù)細(xì)節(jié)無關(guān)純粹是看問題視角的轉(zhuǎn)變——從用它到駕馭它。如果你也想徹底掌握啟動流程我的建議是不要只看SpringBoot的代碼一定要配合SpringFramework的refresh方法一起讀。SpringBoot本身并沒有發(fā)明一套新的容器啟動機(jī)制它只是在一個(gè)成熟的容器啟動框架上利用模板方法模式在特定位置插入了自己的邏輯。理清哪些是SpringFramework的、哪些是SpringBoot的你就擁有了一張完整的啟動地圖。另外一個(gè)技巧是善用Actuator的/actuator/beans端點(diǎn)如果配置了啟動完成后可以看看哪些Bean被創(chuàng)建了、哪些條件沒滿足被跳過了。這個(gè)端點(diǎn)對理解自動裝配的生效范圍非常有幫助。最終啟動流程不是一個(gè)需要死記硬背的知識點(diǎn)而是一張排查地圖。下次啟動出問題時(shí)對照流程找斷點(diǎn)定位速度會比胡亂試快得多。