前言
如果我們想要使用傳統意義上的 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 自動裝配機制的奧妙。