點選上方“Java基基”，選擇“設為星标”
做積極的人，而不是積極廢人！
源碼精品專欄
- 原創 | Java 2020 超神之路，很肝~
- 中文詳細注釋的開源項目
- RPC 架構 Dubbo 源碼解析
- 消息中間件 RocketMQ 源碼解析
- 資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
- 作業排程中間件 Elastic-Job 源碼解析
- 分布式事務中間件 TCC-Transaction 源碼解析
- Eureka 和 Hystrix 源碼解析
- Java 并發源碼
來源： jianshu.com/p/83693d3d0a65
- 一、抛磚引玉：探索Spring IoC容器
-
- 1.1、Spring IoC容器
- 1.2、Spring容器擴充機制
- 二、夯實基礎：JavaConfig與常見Annotation
- 三、削鐵如泥：SpringFactoriesLoader詳解
- 四、另一件武器：Spring容器的事件監聽機制
- 五、出神入化：揭秘自動配置原理
- 六、啟動引導：Spring Boot應用啟動的秘密
- 參考資料
- 預警：本文非常長，建議先mark後看，也許是最後一次寫這麼長的文章
- 說明：前面有4個小節關于Spring的基礎知識，分别是：IOC容器、JavaConfig、事件監聽、SpringFactoriesLoader詳解，它們占據了本文的大部分内容，雖然它們之間可能沒有太多的聯系，但這些知識對于了解Spring Boot的核心原理至關重要，如果你對Spring架構爛熟于心，完全可以跳過這4個小節。正是因為這個系列的文章是由這些看似不相關的知識點組成，是以取名知識清單。
在過去兩三年的Spring生态圈，最讓人興奮的莫過于Spring Boot架構。或許從命名上就能看出這個架構的設計初衷：快速的啟動Spring應用。因而Spring Boot應用本質上就是一個基于Spring架構的應用，它是Spring對“約定優先于配置”理念的最佳實踐産物，它能夠幫助開發者更快速高效地建構基于Spring生态圈的應用。
那Spring Boot有何魔法？自動配置、起步依賴、Actuator、指令行界面(CLI) 是Spring Boot最重要的4大核心特性，其中CLI是Spring Boot的可選特性，雖然它功能強大，但也引入了一套不太正常的開發模型，因而這個系列的文章僅關注其它3種特性。如文章标題，本文是這個系列的第一部分，将為你打開Spring Boot的大門，重點為你剖析其啟動流程以及自動配置實作原理。要掌握這部分核心内容，了解一些Spring架構的基礎知識，将會讓你事半功倍。
一、抛磚引玉：探索Spring IoC容器
如果有看過
SpringApplication.run()
方法的源碼，Spring Boot冗長無比的啟動流程一定會讓你抓狂，透過現象看本質，SpringApplication隻是将一個典型的Spring應用的啟動流程進行了擴充，是以，透徹了解Spring容器是打開Spring Boot大門的一把鑰匙。
1.1、Spring IoC容器
可以把Spring IoC容器比作一間餐館，當你來到餐館，通常會直接招呼服務員：點菜！至于菜的原料是什麼？如何用原料把菜做出來？可能你根本就不關心。IoC容器也是一樣，你隻需要告訴它需要某個bean，它就把對應的執行個體（instance）扔給你，至于這個bean是否依賴其他元件，怎樣完成它的初始化，根本就不需要你關心。
作為餐館，想要做出菜肴，得知道菜的原料和菜單，同樣地，IoC容器想要管理各個業務對象以及它們之間的依賴關系，需要通過某種途徑來記錄和管理這些資訊。
BeanDefinition
對象就承擔了這個責任：容器中的每一個bean都會有一個對應的BeanDefinition執行個體，該執行個體負責儲存bean對象的所有必要資訊，包括bean對象的class類型、是否是抽象類、構造方法和參數、其它屬性等等。當用戶端向容器請求相應對象時，容器就會通過這些資訊為用戶端傳回一個完整可用的bean執行個體。
原材料已經準備好（把BeanDefinition看着原料），開始做菜吧，等等，你還需要一份菜單，
BeanDefinitionRegistry
和
BeanFactory
就是這份菜單，BeanDefinitionRegistry抽象出bean的注冊邏輯，而BeanFactory則抽象出了bean的管理邏輯，而各個BeanFactory的實作類就具體承擔了bean的注冊以及管理工作。它們之間的關系就如下圖：
BeanFactory、BeanDefinitionRegistry關系圖（來自：Spring揭秘）
DefaultListableBeanFactory
作為一個比較通用的BeanFactory實作，它同時也實作了BeanDefinitionRegistry接口，是以它就承擔了Bean的注冊管理工作。從圖中也可以看出，BeanFactory接口中主要包含getBean、containBean、getType、getAliases等管理bean的方法，而BeanDefinitionRegistry接口則包含registerBeanDefinition、removeBeanDefinition、getBeanDefinition等注冊管理BeanDefinition的方法。
下面通過一段簡單的代碼來模拟BeanFactory底層是如何工作的：
// 預設容器實作
DefaultListableBeanFactory beanRegistry = new DefaultListableBeanFactory();
// 根據業務對象構造相應的BeanDefinition
AbstractBeanDefinition definition = new RootBeanDefinition(Business.class,true);
// 将bean定義注冊到容器中
beanRegistry.registerBeanDefinition("beanName",definition);
// 如果有多個bean，還可以指定各個bean之間的依賴關系
// ........
// 然後可以從容器中擷取這個bean的執行個體
// 注意：這裡的beanRegistry其實實作了BeanFactory接口，是以可以強轉，
// 單純的BeanDefinitionRegistry是無法強制轉換到BeanFactory類型的
BeanFactory container = (BeanFactory)beanRegistry;
Business business = (Business)container.getBean("beanName");
這段代碼僅為了說明BeanFactory底層的大緻工作流程，實際情況會更加複雜，比如bean之間的依賴關系可能定義在外部配置檔案(XML/Properties)中、也可能是注解方式。Spring IoC容器的整個工作流程大緻可以分為兩個階段：
①、容器啟動階段
容器啟動時，會通過某種途徑加載
Configuration MetaData
。除了代碼方式比較直接外，在大部分情況下，容器需要依賴某些工具類，比如：
BeanDefinitionReader
，BeanDefinitionReader會對加載的
Configuration MetaData
進行解析和分析，并将分析後的資訊組裝為相應的BeanDefinition，最後把這些儲存了bean定義的BeanDefinition，注冊到相應的BeanDefinitionRegistry，這樣容器的啟動工作就完成了。這個階段主要完成一些準備性工作，更側重于bean對象管理資訊的收集，當然一些驗證性或者輔助性的工作也在這一階段完成。
來看一個簡單的例子吧，過往，所有的bean都定義在XML配置檔案中，下面的代碼将模拟BeanFactory如何從配置檔案中加載bean的定義以及依賴關系：
// 通常為BeanDefinitionRegistry的實作類，這裡以DeFaultListabeBeanFactory為例
BeanDefinitionRegistry beanRegistry = new DefaultListableBeanFactory();
// XmlBeanDefinitionReader實作了BeanDefinitionReader接口，用于解析XML檔案
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReaderImpl(beanRegistry);
// 加載配置檔案
beanDefinitionReader.loadBeanDefinitions("classpath:spring-bean.xml");
// 從容器中擷取bean執行個體
BeanFactory container = (BeanFactory)beanRegistry;
Business business = (Business)container.getBean("beanName");
②、Bean的執行個體化階段
經過第一階段，所有bean定義都通過BeanDefinition的方式注冊到BeanDefinitionRegistry中，當某個請求通過容器的getBean方法請求某個對象，或者因為依賴關系容器需要隐式的調用getBean時，就會觸發第二階段的活動：容器會首先檢查所請求的對象之前是否已經執行個體化完成。如果沒有，則會根據注冊的BeanDefinition所提供的資訊執行個體化被請求對象，并為其注入依賴。當該對象裝配完畢後，容器會立即将其傳回給請求方法使用。
BeanFactory隻是Spring IoC容器的一種實作，如果沒有特殊指定，它采用采用延遲初始化政策：隻有當通路容器中的某個對象時，才對該對象進行初始化和依賴注入操作。而在實際場景下，我們更多的使用另外一種類型的容器：
ApplicationContext
，它建構在BeanFactory之上，屬于更進階的容器，除了具有BeanFactory的所有能力之外，還提供對事件監聽機制以及國際化的支援等。它管理的bean，在容器啟動時全部完成初始化和依賴注入操作。
1.2、Spring容器擴充機制
IoC容器負責管理容器中所有bean的生命周期，而在bean生命周期的不同階段，Spring提供了不同的擴充點來改變bean的命運。在容器的啟動階段，
BeanFactoryPostProcessor
允許我們在容器執行個體化相應對象之前，對注冊到容器的BeanDefinition所儲存的資訊做一些額外的操作，比如修改bean定義的某些屬性或者增加其他資訊等。
如果要自定義擴充類，通常需要實作
org.springframework.beans.factory.config.BeanFactoryPostProcessor
接口，與此同時，因為容器中可能有多個BeanFactoryPostProcessor，可能還需要實作
org.springframework.core.Ordered
接口，以保證BeanFactoryPostProcessor按照順序執行。Spring提供了為數不多的BeanFactoryPostProcessor實作，我們以
PropertyPlaceholderConfigurer
來說明其大緻的工作流程。
在Spring項目的XML配置檔案中，經常可以看到許多配置項的值使用占位符，而将占位符所代表的值單獨配置到獨立的properties檔案，這樣可以将散落在不同XML檔案中的配置集中管理，而且也友善運維根據不同的環境進行配置不同的值。這個非常實用的功能就是由PropertyPlaceholderConfigurer負責實作的。
根據前文，當BeanFactory在第一階段加載完所有配置資訊時，BeanFactory中儲存的對象的屬性還是以占位符方式存在的，比如
${jdbc.mysql.url}
。當PropertyPlaceholderConfigurer作為BeanFactoryPostProcessor被應用時，它會使用properties配置檔案中的值來替換相應的BeanDefinition中占位符所表示的屬性值。當需要執行個體化bean時，bean定義中的屬性值就已經被替換成我們配置的值。當然其實作比上面描述的要複雜一些，這裡僅說明其大緻工作原理，更詳細的實作可以參考其源碼。
與之相似的，還有
BeanPostProcessor
，其存在于對象執行個體化階段。跟BeanFactoryPostProcessor類似，它會處理容器内所有符合條件并且已經執行個體化後的對象。簡單的對比，BeanFactoryPostProcessor處理bean的定義，而BeanPostProcessor則處理bean完成執行個體化後的對象。BeanPostProcessor定義了兩個接口：
public interface BeanPostProcessor {
// 前置處理
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
// 後置處理
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
為了了解這兩個方法執行的時機，簡單的了解下bean的整個生命周期：
Bean的執行個體化過程（來自：Spring揭秘）
postProcessBeforeInitialization()
方法與
postProcessAfterInitialization()
分别對應圖中前置處理和後置處理兩個步驟将執行的方法。這兩個方法中都傳入了bean對象執行個體的引用，為擴充容器的對象執行個體化過程提供了很大便利，在這兒幾乎可以對傳入的執行個體執行任何操作。注解、AOP等功能的實作均大量使用了
BeanPostProcessor
，比如有一個自定義注解，你完全可以實作BeanPostProcessor的接口，在其中判斷bean對象的腦袋上是否有該注解，如果有，你可以對這個bean執行個體執行任何操作，想想是不是非常的簡單？
再來看一個更常見的例子，在Spring中經常能夠看到各種各樣的Aware接口，其作用就是在對象執行個體化完成以後将Aware接口定義中規定的依賴注入到目前執行個體中。比如最常見的
ApplicationContextAware
接口，實作了這個接口的類都可以擷取到一個ApplicationContext對象。當容器中每個對象的執行個體化過程走到BeanPostProcessor前置處理這一步時，容器會檢測到之前注冊到容器的ApplicationContextAwareProcessor，然後就會調用其postProcessBeforeInitialization()方法，檢查并設定Aware相關依賴。看看代碼吧，是不是很簡單：
// 代碼來自：org.springframework.context.support.ApplicationContextAwareProcessor
// 其postProcessBeforeInitialization方法調用了invokeAwareInterfaces方法
private void invokeAwareInterfaces(Object bean) {
if (bean instanceof EnvironmentAware) {
((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
}
if (bean instanceof ApplicationContextAware) {
((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
}
// ......
}
最後總結一下，本小節内容和你一起回顧了Spring容器的部分核心内容，限于篇幅不能寫更多，但了解這部分内容，足以讓您輕松了解Spring Boot的啟動原理，如果在後續的學習過程中遇到一些晦澀難懂的知識，再回過頭來看看Spring的核心知識，也許有意想不到的效果。也許Spring Boot的中文資料很少，但Spring的中文資料和書籍有太多太多，總有東西能給你啟發。
二、夯實基礎：JavaConfig與常見Annotation
2.1、JavaConfig
我們知道
bean
是Spring IOC中非常核心的概念，Spring容器負責bean的生命周期的管理。在最初，Spring使用XML配置檔案的方式來描述bean的定義以及互相間的依賴關系，但随着Spring的發展，越來越多的人對這種方式表示不滿，因為Spring項目的所有業務類均以bean的形式配置在XML檔案中，造成了大量的XML檔案，使項目變得複雜且難以管理。
後來，基于純Java Annotation依賴注入架構
Guice
出世，其性能明顯優于采用XML方式的Spring，甚至有部分人認為，
Guice
可以完全取代Spring（
Guice
僅是一個輕量級IOC架構，取代Spring還差的挺遠）。正是這樣的危機感，促使Spring及社群推出并持續完善了
JavaConfig
子項目，它基于Java代碼和Annotation注解來描述bean之間的依賴綁定關系。比如，下面是使用XML配置方式來描述bean的定義：
<bean id="bookService" class="cn.moondev.service.BookServiceImpl"></bean>
而基于JavaConfig的配置形式是這樣的：
@Configuration
public class MoonBookConfiguration {
// 任何标志了@Bean的方法，其傳回值将作為一個bean注冊到Spring的IOC容器中
// 方法名預設成為該bean定義的id
@Bean
public BookService bookService() {
return new BookServiceImpl();
}
}
如果兩個bean之間有依賴關系的話，在XML配置中應該是這樣：
<bean id="bookService" class="cn.moondev.service.BookServiceImpl">
<property name="dependencyService" ref="dependencyService"/>
</bean>
<bean id="otherService" class="cn.moondev.service.OtherServiceImpl">
<property name="dependencyService" ref="dependencyService"/>
</bean>
<bean id="dependencyService" class="DependencyServiceImpl"/>
而在JavaConfig中則是這樣：
@Configuration
public class MoonBookConfiguration {
// 如果一個bean依賴另一個bean，則直接調用對應JavaConfig類中依賴bean的建立方法即可
// 這裡直接調用dependencyService()
@Bean
public BookService bookService() {
return new BookServiceImpl(dependencyService());
}
@Bean
public OtherService otherService() {
return new OtherServiceImpl(dependencyService());
}
@Bean
public DependencyService dependencyService() {
return new DependencyServiceImpl();
}
}
你可能注意到這個示例中，有兩個bean都依賴于dependencyService，也就是說當初始化bookService時會調用
dependencyService()
，在初始化otherService時也會調用
dependencyService()
，那麼問題來了？這時候IOC容器中是有一個dependencyService執行個體還是兩個？這個問題留着大家思考吧，這裡不再贅述。
2.2、@ComponentScan
@ComponentScan
注解對應XML配置形式中的
<context:component-scan>
元素，表示啟用元件掃描，Spring會自動掃描所有通過注解配置的bean，然後将其注冊到IOC容器中。我們可以通過
basePackages
等屬性來指定
@ComponentScan
自動掃描的範圍，如果不指定，預設從聲明
@ComponentScan
所在類的
package
進行掃描。正因為如此，SpringBoot的啟動類都預設在
src/main/java
下。
2.3、@Import
@Import
注解用于導入配置類，舉個簡單的例子：
@Configuration
public class MoonBookConfiguration {
@Bean
public BookService bookService() {
return new BookServiceImpl();
}
}
現在有另外一個配置類，比如：
MoonUserConfiguration
，這個配置類中有一個bean依賴于
MoonBookConfiguration
中的bookService，如何将這兩個bean組合在一起？借助
@Import
即可：
@Configuration
// 可以同時導入多個配置類，比如：@Import({A.class,B.class})
@Import(MoonBookConfiguration.class)
public class MoonUserConfiguration {
@Bean
public UserService userService(BookService bookService) {
return new BookServiceImpl(bookService);
}
}
需要注意的是，在4.2之前，
@Import
注解隻支援導入配置類，但是在4.2之後，它支援導入普通類，并将這個類作為一個bean的定義注冊到IOC容器中。
2.4、@Conditional
@Conditional
注解表示在滿足某種條件後才初始化一個bean或者啟用某些配置。它一般用在由
@Component
、
@Service
、
@Configuration
等注解辨別的類上面，或者由
@Bean
标記的方法上。如果一個
@Configuration
類标記了
@Conditional
，則該類中所有辨別了
@Bean
的方法和
@Import
注解導入的相關類将遵從這些條件。
在Spring裡可以很友善的編寫你自己的條件類，所要做的就是實作
Condition
接口，并覆寫它的
matches()
方法。舉個例子，下面的簡單條件類表示隻有在
Classpath
裡存在
JdbcTemplate
類時才生效：
public class JdbcTemplateCondition implements Condition {
@Override
public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {
try {
conditionContext.getClassLoader().loadClass("org.springframework.jdbc.core.JdbcTemplate");
return true;
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return false;
}
}
當你用Java來聲明bean的時候，可以使用這個自定義條件類：
@Conditional(JdbcTemplateCondition.class)
@Service
public MyService service() {
......
}
這個例子中隻有當
JdbcTemplateCondition
類的條件成立時才會建立MyService這個bean。也就是說MyService這bean的建立條件是
classpath
裡面包含
JdbcTemplate
，否則這個bean的聲明就會被忽略掉。
Spring Boot
定義了很多有趣的條件，并把他們運用到了配置類上，這些配置類構成了
Spring Boot
的自動配置的基礎。
Spring Boot
運用條件化配置的方法是：定義多個特殊的條件化注解，并将它們用到配置類上。下面列出了
Spring Boot
提供的部分條件化注解：
| 條件化注解 | 配置生效條件 |
|---|---|
| @ConditionalOnBean | 配置了某個特定bean |
| @ConditionalOnMissingBean | 沒有配置特定的bean |
| @ConditionalOnClass | Classpath裡有指定的類 |
| @ConditionalOnMissingClass | Classpath裡沒有指定的類 |
| @ConditionalOnExpression | 給定的Spring Expression Language表達式計算結果為true |
| @ConditionalOnJava | Java的版本比對特定指或者一個範圍值 |
| @ConditionalOnProperty | 指定的配置屬性要有一個明确的值 |
| @ConditionalOnResource | Classpath裡有指定的資源 |
| @ConditionalOnWebApplication | 這是一個Web應用程式 |
| @ConditionalOnNotWebApplication | 這不是一個Web應用程式 |
2.5、@ConfigurationProperties與@EnableConfigurationProperties
當某些屬性的值需要配置的時候，我們一般會在
application.properties
檔案中建立配置項，然後在bean中使用
@Value
注解來擷取配置的值，比如下面配置資料源的代碼。
// jdbc config
jdbc.mysql.url=jdbc:mysql://localhost:3306/sampledb
jdbc.mysql.username=root
jdbc.mysql.password=123456
......
// 配置資料源
@Configuration
public class HikariDataSourceConfiguration {
@Value("jdbc.mysql.url")
public String url;
@Value("jdbc.mysql.username")
public String user;
@Value("jdbc.mysql.password")
public String password;
@Bean
public HikariDataSource dataSource() {
HikariConfig hikariConfig = new HikariConfig();
hikariConfig.setJdbcUrl(url);
hikariConfig.setUsername(user);
hikariConfig.setPassword(password);
// 省略部分代碼
return new HikariDataSource(hikariConfig);
}
}
使用
@Value
注解注入的屬性通常都比較簡單，如果同一個配置在多個地方使用，也存在不友善維護的問題（考慮下，如果有幾十個地方在使用某個配置，而現在你想改下名字，你改怎麼做？）。對于更為複雜的配置，Spring Boot提供了更優雅的實作方式，那就是
@ConfigurationProperties
注解。我們可以通過下面的方式來改寫上面的代碼：
@Component
// 還可以通過@PropertySource("classpath:jdbc.properties")來指定配置檔案
@ConfigurationProperties("jdbc.mysql")
// 字首=jdbc.mysql，會在配置檔案中尋找jdbc.mysql.*的配置項
pulic class JdbcConfig {
public String url;
public String username;
public String password;
}
@Configuration
public class HikariDataSourceConfiguration {
@AutoWired
public JdbcConfig config;
@Bean
public HikariDataSource dataSource() {
HikariConfig hikariConfig = new HikariConfig();
hikariConfig.setJdbcUrl(config.url);
hikariConfig.setUsername(config.username);
hikariConfig.setPassword(config.password);
// 省略部分代碼
return new HikariDataSource(hikariConfig);
}
}
@ConfigurationProperties
對于更為複雜的配置，處理起來也是得心應手，比如有如下配置檔案：
#App
app.menus[0].title=Home
app.menus[0].name=Home
app.menus[0].path=/
app.menus[1].title=Login
app.menus[1].name=Login
app.menus[1].path=/login
app.compiler.timeout=5
app.compiler.output-folder=/temp/
app.error=/error/
可以定義如下配置類來接收這些屬性
@Component
@ConfigurationProperties("app")
public class AppProperties {
public String error;
public List<Menu> menus = new ArrayList<>();
public Compiler compiler = new Compiler();
public static class Menu {
public String name;
public String path;
public String title;
}
public static class Compiler {
public String timeout;
public String outputFolder;
}
}
@EnableConfigurationProperties
注解表示對
@ConfigurationProperties
的内嵌支援，預設會将對應Properties Class作為bean注入的IOC容器中，即在相應的Properties類上不用加
@Component
注解。
三、削鐵如泥：SpringFactoriesLoader詳解
JVM提供了3種類加載器：
BootstrapClassLoader
、
ExtClassLoader
、
AppClassLoader
分别加載Java核心類庫、擴充類庫以及應用的類路徑(
CLASSPATH
)下的類庫。JVM通過雙親委派模型進行類的加載，我們也可以通過繼承
java.lang.classloader
實作自己的類加載器。
何為雙親委派模型？當一個類加載器收到類加載任務時，會先交給自己的父加載器去完成，是以最終加載任務都會傳遞到最頂層的BootstrapClassLoader，隻有當父加載器無法完成加載任務時，才會嘗試自己來加載。
采用雙親委派模型的一個好處是保證使用不同類加載器最終得到的都是同一個對象，這樣就可以保證Java 核心庫的類型安全，比如，加載位于rt.jar包中的
java.lang.Object
類，不管是哪個加載器加載這個類，最終都是委托給頂層的BootstrapClassLoader來加載的，這樣就可以保證任何的類加載器最終得到的都是同樣一個Object對象。檢視ClassLoader的源碼，對雙親委派模型會有更直覺的認識：
protected Class<?> loadClass(String name, boolean resolve) {
synchronized (getClassLoadingLock(name)) {
// 首先，檢查該類是否已經被加載，如果從JVM緩存中找到該類，則直接傳回
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
// 遵循雙親委派的模型，首先會通過遞歸從父加載器開始找，
// 直到父類加載器是BootstrapClassLoader為止
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {}
if (c == null) {
// 如果還找不到，嘗試通過findClass方法去尋找
// findClass是留給開發者自己實作的，也就是說
// 自定義類加載器時，重寫此方法即可
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
但雙親委派模型并不能解決所有的類加載器問題，比如，Java 提供了很多服務提供者接口(
Service Provider Interface
，SPI)，允許第三方為這些接口提供實作。常見的 SPI 有 JDBC、JNDI、JAXP 等，這些SPI的接口由核心類庫提供，卻由第三方實作，這樣就存在一個問題：SPI 的接口是 Java 核心庫的一部分，是由BootstrapClassLoader加載的；SPI實作的Java類一般是由AppClassLoader來加載的。BootstrapClassLoader是無法找到 SPI 的實作類的，因為它隻加載Java的核心庫。它也不能代理給AppClassLoader，因為它是最頂層的類加載器。也就是說，雙親委派模型并不能解決這個問題。
線程上下文類加載器(
ContextClassLoader
)正好解決了這個問題。從名稱上看，可能會誤解為它是一種新的類加載器，實際上，它僅僅是Thread類的一個變量而已，可以通過
setContextClassLoader(ClassLoader cl)
和
getContextClassLoader()
來設定和擷取該對象。如果不做任何的設定，Java應用的線程的上下文類加載器預設就是AppClassLoader。在核心類庫使用SPI接口時，傳遞的類加載器使用線程上下文類加載器，就可以成功的加載到SPI實作的類。線程上下文類加載器在很多SPI的實作中都會用到。但在JDBC中，你可能會看到一種更直接的實作方式，比如，JDBC驅動管理
java.sql.Driver
中的
loadInitialDrivers()
方法中，你可以直接看到JDK是如何加載驅動的：
for (String aDriver : driversList) {
try {
// 直接使用AppClassLoader
Class.forName(aDriver, true, ClassLoader.getSystemClassLoader());
} catch (Exception ex) {
println("DriverManager.Initialize: load failed: " + ex);
}
}
其實講解線程上下文類加載器，最主要是讓大家在看到
Thread.currentThread().getClassLoader()
和
Thread.currentThread().getContextClassLoader()
時不會一臉懵逼，這兩者除了在許多底層架構中取得的ClassLoader可能會有所不同外，其他大多數業務場景下都是一樣的，大家隻要知道它是為了解決什麼問題而存在的即可。
類加載器除了加載class外，還有一個非常重要功能，就是加載資源，它可以從jar包中讀取任何資源檔案，比如，
ClassLoader.getResources(String name)
方法就是用于讀取jar包中的資源檔案，其代碼如下：
public Enumeration<URL> getResources(String name) throws IOException {
Enumeration<URL>[] tmp = (Enumeration<URL>[]) new Enumeration<?>[2];
if (parent != null) {
tmp[0] = parent.getResources(name);
} else {
tmp[0] = getBootstrapResources(name);
}
tmp[1] = findResources(name);
return new CompoundEnumeration<>(tmp);
}
是不是覺得有點眼熟，不錯，它的邏輯其實跟類加載的邏輯是一樣的，首先判斷父類加載器是否為空，不為空則委托父類加載器執行資源查找任務，直到BootstrapClassLoader，最後才輪到自己查找。而不同的類加載器負責掃描不同路徑下的jar包，就如同加載class一樣，最後會掃描所有的jar包，找到符合條件的資源檔案。
類加載器的
findResources(name)
方法會周遊其負責加載的所有jar包，找到jar包中名稱為name的資源檔案，這裡的資源可以是任何檔案，甚至是.class檔案，比如下面的示例，用于查找Array.class檔案：
// 尋找Array.class檔案
public static void main(String[] args) throws Exception{
// Array.class的完整路徑
String name = "java/sql/Array.class";
Enumeration<URL> urls = Thread.currentThread().getContextClassLoader().getResources(name);
while (urls.hasMoreElements()) {
URL url = urls.nextElement();
System.out.println(url.toString());
}
}
運作後可以得到如下結果：
$JAVA_HOME/jre/lib/rt.jar!/java/sql/Array.class
根據資源檔案的URL，可以構造相應的檔案來讀取資源内容。
看到這裡，你可能會感到挺奇怪的，你不是要詳解
SpringFactoriesLoader
嗎？上來講了一堆ClassLoader是幾個意思？看下它的源碼你就知道了：
public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";
// spring.factories檔案的格式為：key=value1,value2,value3
// 從所有的jar包中找到META-INF/spring.factories檔案
// 然後從檔案中解析出key=factoryClass類名稱的所有value值
public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
String factoryClassName = factoryClass.getName();
// 取得資源檔案的URL
Enumeration<URL> urls = (classLoader != null ? classLoader.getResources(FACTORIES_RESOURCE_LOCATION) : ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
List<String> result = new ArrayList<String>();
// 周遊所有的URL
while (urls.hasMoreElements()) {
URL url = urls.nextElement();
// 根據資源檔案URL解析properties檔案
Properties properties = PropertiesLoaderUtils.loadProperties(new UrlResource(url));
String factoryClassNames = properties.getProperty(factoryClassName);
// 組裝資料，并傳回
result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));
}
return result;
}
有了前面關于ClassLoader的知識，再來了解這段代碼，是不是感覺豁然開朗：從
CLASSPATH
下的每個Jar包中搜尋所有
META-INF/spring.factories
配置檔案，然後将解析properties檔案，找到指定名稱的配置後傳回。需要注意的是，其實這裡不僅僅是會去ClassPath路徑下查找，會掃描所有路徑下的Jar包，隻不過這個檔案隻會在Classpath下的jar包中。來簡單看下
spring.factories
檔案的内容吧：
// 來自 org.springframework.boot.autoconfigure下的META-INF/spring.factories
// EnableAutoConfiguration後文會講到，它用于開啟Spring Boot自動配置功能
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration\
執行
loadFactoryNames(EnableAutoConfiguration.class, classLoader)
後，得到對應的一組
@Configuration
類， 我們就可以通過反射執行個體化這些類然後注入到IOC容器中，最後容器裡就有了一系列标注了
@Configuration
的JavaConfig形式的配置類。
這就是
SpringFactoriesLoader
，它本質上屬于Spring架構私有的一種擴充方案，類似于SPI，Spring Boot在Spring基礎上的很多核心功能都是基于此，希望大家可以了解。
四、另一件武器：Spring容器的事件監聽機制
過去，事件監聽機制多用于圖形界面程式設計，比如：點選按鈕、在文本框輸入内容等操作被稱為事件，而當事件觸發時，應用程式作出一定的響應則表示應用監聽了這個事件，而在伺服器端，事件的監聽機制更多的用于異步通知以及監控和異常處理。Java提供了實作事件監聽機制的兩個基礎類：自定義事件類型擴充自
java.util.EventObject
、事件的監聽器擴充自
java.util.EventListener
。來看一個簡單的執行個體：簡單的監控一個方法的耗時。
首先定義事件類型，通常的做法是擴充EventObject，随着事件的發生，相應的狀态通常都封裝在此類中：
public class MethodMonitorEvent extends EventObject {
// 時間戳，用于記錄方法開始執行的時間
public long timestamp;
public MethodMonitorEvent(Object source) {
super(source);
}
}
事件釋出之後，相應的監聽器即可對該類型的事件進行處理，我們可以在方法開始執行之前釋出一個begin事件，在方法執行結束之後釋出一個end事件，相應地，事件監聽器需要提供方法對這兩種情況下接收到的事件進行處理：
// 1、定義事件監聽接口
public interface MethodMonitorEventListener extends EventListener {
// 處理方法執行之前釋出的事件
public void onMethodBegin(MethodMonitorEvent event);
// 處理方法結束時釋出的事件
public void onMethodEnd(MethodMonitorEvent event);
}
// 2、事件監聽接口的實作：如何處理
public class AbstractMethodMonitorEventListener implements MethodMonitorEventListener {
@Override
public void onMethodBegin(MethodMonitorEvent event) {
// 記錄方法開始執行時的時間
event.timestamp = System.currentTimeMillis();
}
@Override
public void onMethodEnd(MethodMonitorEvent event) {
// 計算方法耗時
long duration = System.currentTimeMillis() - event.timestamp;
System.out.println("耗時：" + duration);
}
}
事件監聽器接口針對不同的事件釋出實際提供相應的處理方法定義，最重要的是，其方法隻接收MethodMonitorEvent參數，說明這個監聽器類隻負責監聽器對應的事件并進行處理。有了事件和監聽器，剩下的就是釋出事件，然後讓相應的監聽器監聽并處理。通常情況，我們會有一個事件釋出者，它本身作為事件源，在合适的時機，将相應的事件釋出給對應的事件監聽器：
public class MethodMonitorEventPublisher {
private List<MethodMonitorEventListener> listeners = new ArrayList<MethodMonitorEventListener>();
public void methodMonitor() {
MethodMonitorEvent eventObject = new MethodMonitorEvent(this);
publishEvent("begin",eventObject);
// 模拟方法執行：休眠5秒鐘
TimeUnit.SECONDS.sleep(5);
publishEvent("end",eventObject);
}
private void publishEvent(String status,MethodMonitorEvent event) {
// 避免在事件處理期間，監聽器被移除，這裡為了安全做一個複制操作
List<MethodMonitorEventListener> copyListeners = ➥ new ArrayList<MethodMonitorEventListener>(listeners);
for (MethodMonitorEventListener listener : copyListeners) {
if ("begin".equals(status)) {
listener.onMethodBegin(event);
} else {
listener.onMethodEnd(event);
}
}
}
public static void main(String[] args) {
MethodMonitorEventPublisher publisher = new MethodMonitorEventPublisher();
publisher.addEventListener(new AbstractMethodMonitorEventListener());
publisher.methodMonitor();
}
// 省略實作
public void addEventListener(MethodMonitorEventListener listener) {}
public void removeEventListener(MethodMonitorEventListener listener) {}
public void removeAllListeners() {}
對于事件釋出者（事件源）通常需要關注兩點：
- 在合适的時機釋出事件。此例中的methodMonitor()方法是事件釋出的源頭，其在方法執行之前和結束之後兩個時間點釋出MethodMonitorEvent事件，每個時間點釋出的事件都會傳給相應的監聽器進行處理。在具體實作時需要注意的是，事件釋出是順序執行，為了不影響處理性能，事件監聽器的處理邏輯應盡量簡單。
- 事件監聽器的管理。publisher類中提供了事件監聽器的注冊與移除方法，這樣用戶端可以根據實際情況決定是否需要注冊新的監聽器或者移除某個監聽器。如果這裡沒有提供remove方法，那麼注冊的監聽器示例将一直被MethodMonitorEventPublisher引用，即使已經廢棄不用了，也依然在釋出者的監聽器清單中，這會導緻隐性的記憶體洩漏。
Spring容器内的事件監聽機制
Spring的ApplicationContext容器内部中的所有事件類型均繼承自
org.springframework.context.AppliationEvent
，容器中的所有監聽器都實作
org.springframework.context.ApplicationListener
接口，并且以bean的形式注冊在容器中。一旦在容器内釋出ApplicationEvent及其子類型的事件，注冊到容器的ApplicationListener就會對這些事件進行處理。
你應該已經猜到是怎麼回事了。
ApplicationEvent繼承自EventObject，Spring提供了一些預設的實作，比如：
ContextClosedEvent
表示容器在即将關閉時釋出的事件類型，
ContextRefreshedEvent
表示容器在初始化或者重新整理的時候釋出的事件類型......
容器内部使用ApplicationListener作為事件監聽器接口定義，它繼承自EventListener。ApplicationContext容器在啟動時，會自動識别并加載EventListener類型的bean，一旦容器内有事件釋出，将通知這些注冊到容器的EventListener。
ApplicationContext接口繼承了ApplicationEventPublisher接口，該接口提供了
void publishEvent(ApplicationEvent event)
方法定義，不難看出，ApplicationContext容器擔當的就是事件釋出者的角色。如果有興趣可以檢視
AbstractApplicationContext.publishEvent(ApplicationEvent event)
方法的源碼：ApplicationContext将事件的釋出以及監聽器的管理工作委托給
ApplicationEventMulticaster
接口的實作類。在容器啟動時，會檢查容器内是否存在名為applicationEventMulticaster的ApplicationEventMulticaster對象執行個體。如果有就使用其提供的實作，沒有就預設初始化一個SimpleApplicationEventMulticaster作為實作。
最後，如果我們業務需要在容器内部釋出事件，隻需要為其注入ApplicationEventPublisher依賴即可：實作ApplicationEventPublisherAware接口或者ApplicationContextAware接口(Aware接口相關内容請回顧上文)。
五、出神入化：揭秘自動配置原理
典型的Spring Boot應用的啟動類一般均位于
src/main/java
根路徑下，比如
MoonApplication
類：
@SpringBootApplication
public class MoonApplication {
public static void main(String[] args) {
SpringApplication.run(MoonApplication.class, args);
}
}
其中
@SpringBootApplication
開啟元件掃描和自動配置，而
SpringApplication.run
則負責啟動引導應用程式。
@SpringBootApplication
是一個複合
Annotation
，它将三個有用的注解組合在一起：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = {
@Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
// ......
}
@SpringBootConfiguration
就是
@Configuration
，它是Spring架構的注解，标明該類是一個
JavaConfig
配置類。而
@ComponentScan
啟用元件掃描，前文已經詳細講解過，這裡着重關注
@EnableAutoConfiguration
。
@EnableAutoConfiguration
注解表示開啟Spring Boot自動配置功能，Spring Boot會根據應用的依賴、自定義的bean、classpath下有沒有某個類 等等因素來猜測你需要的bean，然後注冊到IOC容器中。那
@EnableAutoConfiguration
是如何推算出你的需求？首先看下它的定義：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(EnableAutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
// ......
}
你的關注點應該在
@Import(EnableAutoConfigurationImportSelector.class)
上了，前文說過，
@Import
注解用于導入類，并将這個類作為一個bean的定義注冊到容器中，這裡它将把
EnableAutoConfigurationImportSelector
作為bean注入到容器中，而這個類會将所有符合條件的@Configuration配置都加載到容器中，看看它的代碼：
public String[] selectImports(AnnotationMetadata annotationMetadata) {
// 省略了大部分代碼，保留一句核心代碼
// 注意：SpringBoot最近版本中，這句代碼被封裝在一個單獨的方法中
// SpringFactoriesLoader相關知識請參考前文
List<String> factories = new ArrayList<String>(new LinkedHashSet<String>(
SpringFactoriesLoader.loadFactoryNames(EnableAutoConfiguration.class, this.beanClassLoader)));
}
這個類會掃描所有的jar包，将所有符合條件的@Configuration配置類注入的容器中，何為符合條件，看看
META-INF/spring.factories
的檔案内容：
// 來自 org.springframework.boot.autoconfigure下的META-INF/spring.factories
// 配置的key = EnableAutoConfiguration，與代碼中一緻
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration\
.....
以
DataSourceAutoConfiguration
為例，看看Spring Boot是如何自動配置的：
@Configuration
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
@EnableConfigurationProperties(DataSourceProperties.class)
@Import({ Registrar.class, DataSourcePoolMetadataProvidersConfiguration.class })
public class DataSourceAutoConfiguration {
}
分别說一說：
-
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
-
@EnableConfigurationProperties(DataSourceProperties.class)
// 提供對datasource配置資訊的支援，所有的配置字首為：spring.datasource
@ConfigurationProperties(prefix = "spring.datasource")
public class DataSourceProperties {
private ClassLoader classLoader;
private Environment environment;
private String name = "testdb";
......
}
-
@Import({ Registrar.class, DataSourcePoolMetadataProvidersConfiguration.class })
DataSourcePoolMetadataProvidersConfiguration
@Configuration
public class DataSourcePoolMetadataProvidersConfiguration {
@Configuration
@ConditionalOnClass(org.apache.tomcat.jdbc.pool.DataSource.class)
static class TomcatDataSourcePoolMetadataProviderConfiguration {
@Bean
public DataSourcePoolMetadataProvider tomcatPoolDataSourceMetadataProvider() {
.....
}
}
......
}
DataSourcePoolMetadataProvidersConfiguration是資料庫連接配接池提供者的一個配置類，即Classpath中存在
org.apache.tomcat.jdbc.pool.DataSource.class
，則使用tomcat-jdbc連接配接池，如果Classpath中存在
HikariDataSource.class
則使用Hikari連接配接池。
這裡僅描述了DataSourceAutoConfiguration的冰山一角，但足以說明Spring Boot如何利用條件話配置來實作自動配置的。回顧一下，
@EnableAutoConfiguration
中導入了EnableAutoConfigurationImportSelector類，而這個類的
selectImports()
通過SpringFactoriesLoader得到了大量的配置類，而每一個配置類則根據條件化配置來做出決策，以實作自動配置。
整個流程很清晰，但漏了一個大問題：
EnableAutoConfigurationImportSelector.selectImports()
是何時執行的？其實這個方法會在容器啟動過程中執行：
AbstractApplicationContext.refresh()
，更多的細節在下一小節中說明。
六、啟動引導：Spring Boot應用啟動的秘密
6.1 SpringApplication初始化
SpringBoot整個啟動流程分為兩個步驟：初始化一個SpringApplication對象、執行該對象的run方法。看下SpringApplication的初始化流程，SpringApplication的構造方法中調用initialize(Object[] sources)方法，其代碼如下：
private void initialize(Object[] sources) {
if (sources != null && sources.length > 0) {
this.sources.addAll(Arrays.asList(sources));
}
// 判斷是否是Web項目
this.webEnvironment = deduceWebEnvironment();
setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));
setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
// 找到入口類
this.mainApplicationClass = deduceMainApplicationClass();
}
初始化流程中最重要的就是通過SpringFactoriesLoader找到
spring.factories
檔案中配置的
ApplicationContextInitializer
和
ApplicationListener
兩個接口的實作類名稱，以便後期構造相應的執行個體。
ApplicationContextInitializer
的主要目的是在
ConfigurableApplicationContext
做refresh之前，對ConfigurableApplicationContext執行個體做進一步的設定或處理。ConfigurableApplicationContext繼承自ApplicationContext，其主要提供了對ApplicationContext進行設定的能力。
實作一個ApplicationContextInitializer非常簡單，因為它隻有一個方法，但大多數情況下我們沒有必要自定義一個ApplicationContextInitializer，即便是Spring Boot架構，它預設也隻是注冊了兩個實作，畢竟Spring的容器已經非常成熟和穩定，你沒有必要來改變它。
而
ApplicationListener
的目的就沒什麼好說的了，它是Spring架構對Java事件監聽機制的一種架構實作，具體内容在前文Spring事件監聽機制這個小節有詳細講解。這裡主要說說，如果你想為Spring Boot應用添加監聽器，該如何實作？
Spring Boot提供兩種方式來添加自定義監聽器：
- 通過
SpringApplication.addListeners(ApplicationListener<?>... listeners)
SpringApplication.setListeners(Collection<? extends ApplicationListener<?>> listeners)
- 既然SpringApplication的初始化流程中已經從
spring.factories
ApplicationListener
META-INF/spring.factories
org.springframework.context.ApplicationListener=\
cn.moondev.listeners.xxxxListener\
關于SpringApplication的初始化，我們就說這麼多。
6.2 Spring Boot啟動流程
Spring Boot應用的整個啟動流程都封裝在SpringApplication.run方法中，其整個流程真的是太長太長了，但本質上就是在Spring容器啟動的基礎上做了大量的擴充，按照這個思路來看看源碼：
public ConfigurableApplicationContext run(String... args) {
StopWatch stopWatch = new StopWatch();
stopWatch.start();
ConfigurableApplicationContext context = null;
FailureAnalyzers analyzers = null;
configureHeadlessProperty();
// ①
SpringApplicationRunListeners listeners = getRunListeners(args);
listeners.starting();
try {
// ②
ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
ConfigurableEnvironment environment = prepareEnvironment(listeners,applicationArguments);
// ③
Banner printedBanner = printBanner(environment);
// ④
context = createApplicationContext();
// ⑤
analyzers = new FailureAnalyzers(context);
// ⑥
prepareContext(context, environment, listeners, applicationArguments,printedBanner);
// ⑦
refreshContext(context);
// ⑧
afterRefresh(context, applicationArguments);
// ⑨
listeners.finished(context, null);
stopWatch.stop();
return context;
}
catch (Throwable ex) {
handleRunFailure(context, listeners, analyzers, ex);
throw new IllegalStateException(ex);
}
}
① 通過SpringFactoriesLoader查找并加載所有的
SpringApplicationRunListeners
，通過調用starting()方法通知所有的SpringApplicationRunListeners：應用開始啟動了。SpringApplicationRunListeners其本質上就是一個事件釋出者，它在SpringBoot應用啟動的不同時間點釋出不同應用事件類型(ApplicationEvent)，如果有哪些事件監聽者(ApplicationListener)對這些事件感興趣，則可以接收并且處理。還記得初始化流程中，SpringApplication加載了一系列ApplicationListener嗎？這個啟動流程中沒有發現有釋出事件的代碼，其實都已經在SpringApplicationRunListeners這兒實作了。
簡單的分析一下其實作流程，首先看下SpringApplicationRunListener的源碼：
public interface SpringApplicationRunListener {
// 運作run方法時立即調用此方法，可以使用者非常早期的初始化工作
void starting();
// Environment準備好後，并且ApplicationContext建立之前調用
void environmentPrepared(ConfigurableEnvironment environment);
// ApplicationContext建立好後立即調用
void contextPrepared(ConfigurableApplicationContext context);
// ApplicationContext加載完成，在refresh之前調用
void contextLoaded(ConfigurableApplicationContext context);
// 當run方法結束之前調用
void finished(ConfigurableApplicationContext context, Throwable exception);
}
SpringApplicationRunListener隻有一個實作類：
EventPublishingRunListener
。①處的代碼隻會擷取到一個EventPublishingRunListener的執行個體，我們來看看starting()方法的内容：
public void starting() {
// 釋出一個ApplicationStartedEvent
this.initialMulticaster.multicastEvent(new ApplicationStartedEvent(this.application, this.args));
}
順着這個邏輯，你可以在②處的
prepareEnvironment()
方法的源碼中找到
listeners.environmentPrepared(environment);
即SpringApplicationRunListener接口的第二個方法，那不出你所料，
environmentPrepared()
又釋出了另外一個事件
ApplicationEnvironmentPreparedEvent
。接下來會發生什麼，就不用我多說了吧。
② 建立并配置目前應用将要使用的
Environment
，Environment用于描述應用程式目前的運作環境，其抽象了兩個方面的内容：配置檔案(profile)和屬性(properties)，開發經驗豐富的同學對這兩個東西一定不會陌生：不同的環境(eg：生産環境、預釋出環境)可以使用不同的配置檔案，而屬性則可以從配置檔案、環境變量、指令行參數等來源擷取。是以，當Environment準備好後，在整個應用的任何時候，都可以從Environment中擷取資源。
總結起來，②處的兩句代碼，主要完成以下幾件事：
- 判斷Environment是否存在，不存在就建立（如果是web項目就建立
StandardServletEnvironment
StandardEnvironment
- 配置Environment：配置profile以及properties
- 調用SpringApplicationRunListener的
environmentPrepared()
③、SpringBoot應用在啟動時會輸出這樣的東西：
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.5.6.RELEASE)
如果想把這個東西改成自己的塗鴉，你可以研究以下Banner的實作，這個任務就留給你們吧。
④、根據是否是web項目，來建立不同的ApplicationContext容器。
⑤、建立一系列
FailureAnalyzer
，建立流程依然是通過SpringFactoriesLoader擷取到所有實作FailureAnalyzer接口的class，然後在建立對應的執行個體。FailureAnalyzer用于分析故障并提供相關診斷資訊。
⑥、初始化ApplicationContext，主要完成以下工作：
- 将準備好的Environment設定給ApplicationContext
- 周遊調用所有的ApplicationContextInitializer的
initialize()
- 調用SpringApplicationRunListener的
contextPrepared()
- 将所有的bean加載到容器中
- 調用SpringApplicationRunListener的
contextLoaded()
⑦、調用ApplicationContext的
refresh()
方法，完成IoC容器可用的最後一道工序。從名字上了解為重新整理容器，那何為重新整理？就是插手容器的啟動，聯系一下第一小節的内容。那如何重新整理呢？且看下面代碼：
// 摘自refresh()方法中一句代碼
invokeBeanFactoryPostProcessors(beanFactory);
看看這個方法的實作：
protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
......
}
擷取到所有的
BeanFactoryPostProcessor
來對容器做一些額外的操作。BeanFactoryPostProcessor允許我們在容器執行個體化相應對象之前，對注冊到容器的BeanDefinition所儲存的資訊做一些額外的操作。這裡的getBeanFactoryPostProcessors()方法可以擷取到3個Processor：
ConfigurationWarningsApplicationContextInitializer$ConfigurationWarningsPostProcessor
SharedMetadataReaderFactoryContextInitializer$CachingMetadataReaderFactoryPostProcessor
ConfigFileApplicationListener$PropertySourceOrderingPostProcessor
不是有那麼多BeanFactoryPostProcessor的實作類，為什麼這兒隻有這3個？因為在初始化流程擷取到的各種ApplicationContextInitializer和ApplicationListener中，隻有上文3個做了類似于如下操作：
public void initialize(ConfigurableApplicationContext context) {
context.addBeanFactoryPostProcessor(new ConfigurationWarningsPostProcessor(getChecks()));
}
然後你就可以進入到
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors()
方法了，這個方法除了會周遊上面的3個BeanFactoryPostProcessor處理外，還會擷取類型為
BeanDefinitionRegistryPostProcessor
的bean：
org.springframework.context.annotation.internalConfigurationAnnotationProcessor
，對應的Class為
ConfigurationClassPostProcessor
。
ConfigurationClassPostProcessor
用于解析處理各種注解，包括：@Configuration、@ComponentScan、@Import、@PropertySource、@ImportResource、@Bean。當處理
@import
注解的時候，就會調用<自動配置>這一小節中的
EnableAutoConfigurationImportSelector.selectImports()
來完成自動配置功能。其他的這裡不再多講，如果你有興趣，可以查閱參考資料6。
⑧、查找目前context中是否注冊有CommandLineRunner和ApplicationRunner，如果有則周遊執行它們。
⑨、執行所有SpringApplicationRunListener的finished()方法。
這就是Spring Boot的整個啟動流程，其核心就是在Spring容器初始化并啟動的基礎上加入各種擴充點，這些擴充點包括：ApplicationContextInitializer、ApplicationListener以及各種BeanFactoryPostProcessor等等。你對整個流程的細節不必太過關注，甚至沒弄明白也沒有關系，你隻要了解這些擴充點是在何時如何工作的，能讓它們為你所用即可。
整個啟動流程确實非常複雜，可以查詢參考資料中的部分章節和内容，對照着源碼，多看看，我想最終你都能弄清楚的。言而總之，Spring才是核心，了解清楚Spring容器的啟動流程，那Spring Boot啟動流程就不在話下了。
歡迎加入我的知識星球，一起探讨架構，交流源碼。加入方式，長按下方二維碼噢：
已在知識星球更新源碼解析如下：
最近更新《芋道 SpringBoot 2.X 入門》系列，已經 20 餘篇，覆寫了 MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等内容。
提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。
擷取方式：點“在看”，關注公衆号并回複 666 領取，更多内容陸續奉上。