前言
如果我們想要使用傳統意義上的 Spring 應用，那麼需要配置大量的 xml 文件纔可以啓動，而且隨着項目的越來越龐大，配置文件也會越來越繁瑣，這在一定程度上也給開發者帶來了困擾，於是 SpringBoot 就應運而生了。
什麼是 SpringBoot
2012 年 10 月，一個叫 Mike Youngstrom 的人在 Spring Jira 中創建了一個功能請求，要求在 Spring Framework 中支持無容器 Web 應用程序體系結構，提出了在主容器引導 Spring 容器內配置 Web 容器服務。這件事情對 SpringBoot 的誕生應該說是起到了一定的推動作用。
SpringBoot 的誕生就是爲了簡化 Spring 中繁瑣的 XML 配置，其本質依然是 Spring 框架，使用 SpringBoot 之後可以不使用任何 XML 配置來啓動一個服務，使得我們在使用微服務架構時可以更加快速的建立一個應用。
SpringBoot 具有以下特點：
- 創建獨立的 Spring 應用。
- 直接嵌入了 Tomcat、Jetty 或 Undertow（不需要部署 WAR 文件）。
- 提供了固定的配置來簡化配置。
- 儘可能地自動配置 Spring 和第三方庫。
- 提供可用於生產的特性，如度量、運行狀況檢查和外部化配置。
- 完全不需要生成代碼，也不需要 XML 配置。
SpringBoot 這些特點中最重要的兩條就是約定優於配置和自動裝配。
約定優於配置
SpringBoot 的約定由於配置主要體現在以下方面：
maven 項目的配置文件存放在 resources 資源目錄下。
maven 項目默認編譯後的文件放於 target 目錄。
maven 項目默認打包成 jar 格式。
配置文件默認爲 application.yml 或者 application.yaml 或者 application.properties。
默認通過配置文件 spring.profiles.active 來激活配置。
自動裝配
自動裝配則是 SpringBoot 的核心，自動裝配是如何實現的呢？爲什麼我們只要引入一個 starter 組件依賴就能實現自動裝配呢，接下來就讓我們一起來探討下 SpringBoot 的自動裝配機制。
相比較於傳統的 Spring 應用，搭建一個 SpringBoot 應用，我們只需要引入一個註解 @SpringBootApplication，就可以成功運行。
我們就從 SpringBoot 的這個註解開始入手，看看這個註解到底替我們做了什麼。
前面四個不用說，是定義一個註解所必須的，關鍵就在於後面三個註解：@SpringBootConfiguration，@EnableAutoConfiguration，@ComponentScan。也就是說我們如果不用 @SpringBootApplication 這個複合註解，而是直接使用最下面這三個註解，也能啓動一個 SpringBoot 應用。
@SpringBootConfiguration 註解
這個註解我們點進去就可以發現，它實際上就是一個 @Configuration 註解，這個註解大家應該很熟悉了，加上這個註解就是爲了讓當前類作爲一個配置類交由 Spring 的 IOC 容器進行管理，因爲前面我們說了，SpringBoot 本質上還是 Spring，所以原屬於 Spring 的註解 @Configuration 在 SpringBoot 中也可以直接應用。
@ComponentScan 註解
這個註解也很熟悉，用於定義 Spring 的掃描路徑，等價於在 xml 文件中配置 context:component-scan，假如不配置掃描路徑，那麼 Spring 就會默認掃描當前類所在的包及其子包中的所有標註了 @Component，@Service，@Controller 等註解的類。
@EnableAutoConfiguration
這個註解纔是實現自動裝配的關鍵，點進去之後發現，它是一個由@AutoConfigurationPackage 和 @Import 註解組成的複合註解。
@EnableXXX 註解也並不是 SpringBoot 中的新註解，這種註解在 Spring 3.1 版本就開始出現了，比如開啓定時任務的註解 @EnableScheduling 等。
@Import 註解
這個註解比較關鍵，我們通過一個例子來說明一下。
定義一個普通類 TestImport，不加任何註解，我們知道這個時候這個類並不會被 Spring 掃描到，也就是無法直接注入這個類：
public class TestImport {
}
現實開發中，假如就有這種情況，定義好了一個類，即使加上了註解，也不能保證這個類一定被 Spring 掃描到，這個時候該怎麼做呢？
這時候我們可以再定義一個類 MyConfiguration，保證這個類可以被 Spring 掃描到，然後通過加上 @Import 註解來導入 TestImport 類，這時候就可以直接注入 TestImport 了：
@Configuration
@Import(TestImport.class)
public class MyConfiguration {
}
所以這裏的 @Import 註解其實就是爲了去導入一個類 AutoConfigurationImportSelector，接下來我們需要分析一下這個類。
AutoConfigurationImportSelector 類
進入這個類之後，有一個方法，這個方法很好理解，首先就是看一下 AnnotationMetadata（註解的元信息），有沒有數據，沒有就說明沒導入直接返回一個空數組，否則就調用 getAutoConfigurationEntry 方法：
進入 getAutoConfigurationEntry 方法：
這個方法裏面就是通過調用 getCandidateConfigurations 來獲取候選的 Bean，並將其存爲一個集合，最後經過去重，校驗等一系列操作之後，被封裝成 AutoConfigurationEntry 對象返回。
繼續進入 getCandidateConfigurations 方法，這時候就幾乎看到曙光了：
這裏面再繼續點擊去就沒必要了，看錯誤提示大概就知道了，loadFactoryNames 方法會去 META-INF/spring.factories 文件中根據 EnableAutoConfiguration 的全限定類名獲取到我們需要導入的類，而 EnableAutoConfiguration 類的全限定類名爲 org.springframework.boot.autoconfigure.EnableAutoConfiguration，那麼就讓我們打開這個文件看一下：
可以看到，這個文件中配置了大量的需要自動裝配的類，當我們啓動 SpringBoot 項目的時候，SpringBoot 會掃描所有 jar 包下面的 META-INF/spring.factories 文件，並根據 key 值進行讀取，最後在經過去重等一些列操作得到了需要自動裝配的類。
需要注意的是：上圖中的 spring.factories 文件是在 spring-boot-autoconfigure 包下面，這個包記錄了官方提供的 stater 中幾乎所有需要的自動裝配類，所以並不是每一個官方的 starter 下都會有 spring.factories 文件。
談談 SPI 機制
通過 SpringFactoriesLoader 來讀取配置文件 spring.factories 中的配置文件的這種方式是一種 SPI 的思想。那麼什麼是 SPI 呢？
SPI，Service Provider Interface。即：接口服務的提供者。就是說我們應該面向接口（抽象）編程，而不是面向具體的實現來編程，這樣一旦我們需要切換到當前接口的其他實現就無需修改代碼。
在 Java 中，數據庫驅動就使用到了 SPI 技術，每次我們只需要引入數據庫驅動就能被加載的原因就是因爲使用了 SPI 技術。
打開 DriverManager 類，其初始化驅動的代碼如下：
進入 ServiceLoader 方法，發現其內部定義了一個變量：
private static final String PREFIX = "META-INF/services/";
這個變量在下面加載驅動的時候有用到，下圖中的 service 即 java.sql.Driver：
所以就是說，在數據庫驅動的 jar 包下面的 META-INF/services/ 下有一個文件 java.sql.Driver，裏面記錄了當前需要加載的驅動，我們打開這個文件可以看到裏面記錄的就是驅動的全限定類名：
@AutoConfigurationPackage 註解
從這個註解繼續點進去之後可以發現，它最終還是一個 @Import 註解：
這個時候它導入了一個 AutoConfigurationPackages 的內部類 Registrar， 而這個類其實作用就是讀取到我們在最外層的 @SpringBootApplication 註解中配置的掃描路徑（沒有配置則默認當前包下），然後把掃描路徑下面的類都加到數組中返回。
手寫一個 stater 組件
瞭解完自動裝配的原理，接下來就可以動手寫一個自己的 starter 組件了。
starter 組件命名規則
SpringBoot 官方的建議是，如果是我們開發者自己開發的 starter 組件（即屬於第三方組件），那麼命名規範是{name}-spring-boot-starter，而如果是 SpringBoot 官方自己開發的組件，則命名爲 spring-boot-starter-{name}。
當然，這只是一個建議，如果非不按這個規則也沒什麼問題，但是爲了更好的識別區分，還是建議按照這個規則來命名。
手寫 starter
寫一個非常簡單的組件，這個組件只做一件事，那就是實現 fastjson 序列化。
- 新建一個
SpringBoot應用lonelyWolf-spring-boot-starter。 - 修改
pom文件，並新增fastjson依賴（省略了部分屬性）。
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.0</version>
<relativePath/>
</parent>
<groupId>com.lonely.wolf.note</groupId>
<artifactId>lonelyWolf-spring-boot-starter</artifactId>
<version>1.0.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.72</version>
</dependency>
</dependencies>
- 新建一個序列化類
JsonSerial類來實現fastjson序列化。
public class JsonSerial {
public <T> String serial(T t){
return JSONObject.toJSONString(t);
}
}
- 新建一個自動裝配類
MyAutoConfiguration來生成JsonSerial。
@Configuration
public class MyAutoConfiguration {
@Bean
public JsonSerial jsonSerial(){
return new JsonSerial();
}
}
- 完成之後將其打成一個
jar包，然後再另一個SpringBoot中引入依賴：
<dependency>
<groupId>com.lonely.wolf.note</groupId>
<artifactId>lonelyWolf-spring-boot-starter</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
- 這時候在這個
SpringBoot應用中直接注入JsonSerial對象會直接提示找不到這個對象：
這是因爲 MyAutoConfiguration 這個類是在外部 jar 包之中，並沒有被掃描到（需要注意的是，假如剛好 jar 包的路徑和掃描的路徑相同，那麼是可以被掃描到的，但是在實際項目中，我們不可能確保引入的 jar 包能被掃描到，所以才需要通過配置的方式來導入），所以我們還需要導入這個外部配置類。
- 在
resources目錄下新建一個文件META-INF/spring.factories文件，文件內新增一個如下配置：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.lonely.wolf.note.MyAutoConfiguration
這樣，SpringBoot 就會將 MyAutoConfiguration 進行管理，從而得到 JsonSerial 對象，這樣就可以直接注入使用了。
總結
本文從爲什麼要有 SpringBoot，以及 SpringBoot 到底方便在哪裏開始入手，逐步分析了 SpringBoot 自動裝配的原理，最後手寫了一個簡單的 start 組件，通過實戰來體會了 SpringBoot 自動裝配機制的奧妙。