首先貼一張很不錯的圖，SpringBoot啟動結構圖，圖片出自SpringBoot啟動流程解析。
本文的分析基於Spring Boot 2.1.5，非Spring的代碼只有下面這個啟動main函數：
@SpringBootApplication public class App { public static void main(String[] args) { SpringApplication application = new SpringApplication(AppServer.class); application.run(args); } } 構造函數
SpringApplication的構造函數實例化了 初始化上下文的各種接口--ApplicationContextInitializer以及監聽器--ApplicationListener，要注意的是這里的實例化，並不像平時的Spring Components一樣通過注解和掃包完成，而是通過一種不依賴Spring上下文的加載方法，這樣才能在Spring完成啟動前做各種配置。Spring的解決方法是以接口的全限定名作為key，實現類的全限定名作為value記錄在項目的META-INF/spring.factories文件中，然后通過SpringFactoriesLoader工具類提供靜態方法進行類加載並緩存下來，spring.factories是Spring Boot的核心配置文件，后面會繼續說明。另外比較有意思的是兩個deduce方法，Spring Boot項目主要的目標之一就是自動化配置，通過這兩個deduce方法可以看出，Spring Boot的判斷方法之一是檢查系統中是否存在的核心類。
public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) { this.resourceLoader = resourceLoader; Assert.notNull(primarySources, "PrimarySources must not be null"); this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources)); this.webApplicationType = WebApplicationType.deduceFromClasspath();//通過核心類判斷是否開啟、開啟什么web容器 //實例化初始器 setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class)); //實例化監聽器 setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class)); this.mainApplicationClass = deduceMainApplicationClass(); } Run
初始化完成之后就進到了run方法，run方法完成了所有Spring的整個啟動過程：准備Environment——發布事件——創建上下文、bean——刷新上下文——結束，其中穿插了很多監聽器的動作，並且很多邏輯都是靠各種監聽器的實現類執行的，所以在分析run方法之前，先看下各種核心監聽器、接口的作用。
ConfigurableApplicationContext
不得不說，用IDEA分析源碼真的很方便，直接生成接口的UML類圖：
相對於只讀的
ApplicationContext而言，
ConfigurableApplicationContext提供了配置上下文的接口，如設置Environment、監聽器、切面類、關閉上下文的鈎子等，還有刷新上下文的接口。默認是只讀的接口，接口名前面加
Configurable對應是一個提供可配置接口的新接口——在Spring很多配置相關的接口中都有這樣的繼承形式，例如ConfigurableEnvironment和Environment、ConfigurablePropertyResolver和PropertyResolver、ConfigurableBeanFactory和BeanFactory等等。
繼承的三個父類接口里，
Closeable提供了關閉時資源釋放的接口，
Lifecycle是提供對生命周期控制的接口(start\stop)以及查詢當前運行狀態的接口，
ApplicationContext則是配置上下文的中心配置接口，繼承了其他很多配置接口，其本身提供查詢諸如id、應用程序名等上下文檔案信息的只讀接口，以及構建自動裝配bean的工廠（注釋上官方說該接口提供的工廠是用於注冊上下文外部的bean的，但調試發現和在程序內
@Autowired獲取到的工廠是同一個對象...）。簡單寫下
ApplicationContext繼承的父類接口。
- EnvironmentCapable
提供Environment接口。 - MessageSource
國際化資源接口。 - ApplicationEventPublisher
事件發布器。 - ResourcePatternResolver
資源加載器。 - HierarchicalBeanFactory、ListableBeanFactory
這兩個都繼承了bean容器的根接口BeanFactory，具體在另一篇博客Spring的bean工廠分析分析。
ConfigurableEnvironment
一般在寫業務代碼時使用的都是只讀類型的接口Environment，該接口是對運行程序環境的抽象，是保存系統配置的中心，而在啟動過程中使用的則是可編輯的ConfigurableEnvironment。接口的UML類圖如下，提供了合並父環境、添加active profile以及一些設置解析配置文件方式的接口。
其中一個比較重要的方法MutablePropertySources getPropertySources();，該方法返回一個可編輯的PropertySources，如果有在啟動階段自定義環境的PropertySources的需求，就可以通過該方法設置。
EventPublishingRunListener
該監聽器實際上是一個用於廣播Spring事件的廣播器，實現SpringApplicationRunListener接口的方法都是包裝一個Spring事件並進行廣播，例如：
@Override public void contextPrepared(ConfigurableApplicationContext context) { this.initialMulticaster.multicastEvent(new ApplicationContextInitializedEvent(this.application, this.args, context)); } @Override public void running(ConfigurableApplicationContext context) { context.publishEvent(new ApplicationReadyEvent(this.application, this.args, context)); } 可以看到有兩種廣播方式，一種是當Spring還在啟動的時候，通過監聽器內部的SimpleApplicationEventMulticaster廣播器進行廣播；一種是當Spring啟動完成內部的廣播器可用時，直接調用上下文提供的接口進行廣播。
繼續分析Run
了解了一些核心的接口后，就可以啟動Debug模式運行Run方法了，由於涉及的方法調用很多，以下代碼將拆分源碼，並將方法簽名記在前面。
首先開啟了一個秒表用來統計啟動時間並在日志打印（如果開啟控制字），聲明了一些在后面需要用到的變量，然后開始初始化SpringApplicationRunListener類型的監聽器，SpringApplicationRunListeners對監聽器List進行了封裝，例如調用.starting()時會遍歷內部所有監聽器調用其.starting()方法。
public ConfigurableApplicationContext run(String... args){ StopWatch stopWatch = new StopWatch(); stopWatch.start(); ConfigurableApplicationContext context = null; Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>(); configureHeadlessProperty();//開啟設置，讓系統模擬不存在io設備，略。。 SpringApplicationRunListeners listeners = getRunListeners(args);//初始化監聽器 listeners.starting(); ... private SpringApplicationRunListeners getRunListeners(String[] args) { Class<?>[] types = new Class<?>[] { SpringApplication.class, String[].class };//SpringApplicationRunListener的構造函數參數類型 return new SpringApplicationRunListeners(logger, getSpringFactoriesInstances(SpringApplicationRunListener.class, types, this, args)); } private <T> Collection<T> getSpringFactoriesInstances(Class<T> type, Class<?>[] parameterTypes, Object... args) { ClassLoader classLoader = getClassLoader();//從當前線程獲取類加載器 //Spring的類加載工具會從注冊文件META-INF/spring.factories用指定的類加載器加載類，這里返回相應類型的實現類全限定名 Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader)); List<T> instances = createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names);//實例化 //Spring的排序工具，對繼承了Ordered接口或者@Priority標記的類進行排序 AnnotationAwareOrderComparator.sort(instances); return instances; } 調試發現，注冊為SpringApplicationRunListener的實現類只有EventPublishingRunListener，之前說過該注冊器是一個用於廣播Spring事件的廣播器，進到構造函數中可以看到都有哪些監聽器被綁定到了這個廣播器中，這里每個監聽器的作用就不再深入了，需要說的是，如果在項目中有什么需要集成到Spring的框架，可以注冊SpringApplicationRunListener\ApplicationListener的實現類，監聽Spring的不同啟動事件並執行集成的邏輯。當然也有別的方法，例如：Creating a Custom Starter with Spring Boot。
繼續往下看run方法，這里重點是准備Environment的邏輯。首先Spring會根據web容器的類型新建一個ConfigurableEnvironment，不同的web容器類型的Environment會重載customizePropertySources方法，該方法會注入不同的propertySources，例如如果開啟內嵌的Servlet容器，就會注入servlet context init params等相關的參數。接下來會對新建的Environment執行配置寫入的邏輯，主要是把main方法中設置到SpringApplication的參數寫入到Environment中，然后發布ApplicationEnvironmentPreparedEvent事件，做一些綁定后返回Environment。吐槽下Spring對Environment的處理這塊的代碼寫得很深奧，看不懂~
try {
ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);//封裝main方法的參數
//初始化填充Environment的參數
ConfigurableEnvironment environment = prepareEnvironment(listeners,applicationArguments);
configureIgnoreBeanInfo(environment);//設置獲取BeanInfo的一個參數，有興趣的可以去了解下Introspector.getBeanInfo(Class<?> beanClass, int flags)這個方法 ... private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments) { //新建\獲取當前Environment實例 ConfigurableEnvironment environment = getOrCreateEnvironment(); configureEnvironment(environment, applicationArguments.getSourceArgs());//配置參數 listeners.environmentPrepared(environment);//發布事件 bindToSpringApplication(environment);//綁定"spring.main"為當前的application，做SpEL用 if (!this.isCustomEnvironment) {//轉換environment的類型，但這里應該類型和deduce的相同不用轉換 environment = new EnvironmentConverter(getClassLoader()).convertEnvironmentIfNecessary(environment, deduceEnvironmentClass()); } //將現有的配置封裝成ConfigurationPropertySourcesPropertySource，看起來是為了做SpEL的，看不懂~ ConfigurationPropertySources.attach(environment); return environment; } protected void configureEnvironment(ConfigurableEnvironment environment, String[] args) { if (this.addConversionService) {//默認開啟，會注入一組轉換工具，例如StringToDurationConverter ConversionService conversionService = ApplicationConversionService.getSharedInstance(); environment.setConversionService(ConfigurableConversionService) conversionService); } configurePropertySources(environment, args);//如果main啟動時設置了默認參數或者有命令行參數，則寫入到environment中 configureProfiles(environment, args);//如果main啟動時設置了profile，則寫入到environment的ActiveProfiles中 } 繼續往下看run方法，這里會創建Spring的上下文實例，詳情請看另一篇博客Spring Boot Context分析，簡而言之就是根據Web容器類型的不同來創建不用的上下文實例。
Banner printedBanner = printBanner(environment);//打應標語 context = createApplicationContext();//創建上下文實例 //異常播報器，默認有org.springframework.boot.diagnostics.FailureAnalyzers exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class, new Class[] { ConfigurableApplicationContext.class }, context); ... 繼續往下看run方法，接下來是對剛創建的上下文完成加載。加載過程先填充Environment以及設置的參數，然后執行注冊到spring.factories的ApplicationContextInitializer切面，如果自己實現切面的話要注意這時context已經有的信息是什么。接着發布ApplicationContextInitializedEvent事件，然后加載bean，最后發布ApplicationPreparedEvent事件。
prepareContext(context, environment, listeners, applicationArguments,printedBanner);
...
private void prepareContext(ConfigurableApplicationContext context, ConfigurableEnvironment environment, SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments, Banner printedBanner) { context.setEnvironment(environment); //如果application有設置beanNameGenerator、resourceLoader就將其注入到上下文中，並將轉換工具也注入到上下文中 postProcessApplicationContext(context); applyInitializers(context);//調用初始化的切面 listeners.contextPrepared(context);//發布ApplicationContextInitializedEvent事件 if (this.logStartupInfo) {//日志 logStartupInfo(context.getParent() == null); logStartupProfileInfo(context); } // Add boot specific singleton beans ConfigurableListableBeanFactory beanFactory = context.getBeanFactory(); beanFactory.registerSingleton("springApplicationArguments", applicationArguments);//注入main方法的參數 if (printedBanner != null) { beanFactory.registerSingleton("springBootBanner", printedBanner); } if (beanFactory instanceof DefaultListableBeanFactory) { //如果bean名相同的話是否允許覆蓋，默認為false，相同會拋出異常 ((DefaultListableBeanFactory) beanFactory).setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding); } // 這里獲取到的是BootstrapImportSelectorConfiguration這個class，而不是自己寫的啟動來，這個class是在之前注冊的BootstrapApplicationListener的監聽方法中注入的 Set<Object> sources = getAllSources(); Assert.notEmpty(sources, "Sources must not be empty"); load(context, sources.toArray(new Object[0]));//加載sources 到上下文中 listeners.contextLoaded(context);//發布ApplicationPreparedEvent事件 } 回到run方法，在實例化上下文並完成相關配置后，會刷新上下文。
refreshContext(context);
...
AbstractApplicationContext
public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { //記錄啟動時間、狀態，web容器初始化其property，復制listener prepareRefresh(); //這里返回的是context的BeanFactory ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); //beanFactory注入一些標准組件，例如ApplicationContextAwareProcessor，ClassLoader等 prepareBeanFactory(beanFactory); try { //給實現類留的一個鈎子，例如注入BeanPostProcessors，這里是個空方法 postProcessBeanFactory(beanFactory); // 調用切面方法 invokeBeanFactoryPostProcessors(beanFactory); // 注冊切面bean registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // bean工廠注冊一個key為applicationEventMulticaster的廣播器 initApplicationEventMulticaster(); // 給實現類留的一鈎子，可以執行其他refresh的工作，這里是個空方法 onRefresh(); // 將listener注冊到廣播器中 registerListeners(); // 實例化未實例化的bean finishBeanFactoryInitialization(beanFactory); // 清理緩存，注入DefaultLifecycleProcessor，發布ContextRefreshedEvent finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } } 回到run方法，最后的邏輯就是發布啟動完成的事件，並調用監聽者的方法。
... afterRefresh(context, applicationArguments);//給實現類留的鈎子，這里是一個空方法。 stopWatch.stop(); if (this.logStartupInfo) { new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch); } listeners.started(context);//發布ApplicationStartedEvent事件 callRunners(context, applicationArguments); } catch (Throwable ex) { handleRunFailure(context, ex, exceptionReporters, listeners); throw new IllegalStateException(ex); } try { listeners.running(context);//發布ApplicationReadyEvent事件 } catch (Throwable ex) { handleRunFailure(context, ex, exceptionReporters, null); throw new IllegalStateException(ex); } return context;作者：看不見的BUG
鏈接：https://www.jianshu.com/p/603d125f21b3
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。