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