我們今天暫且不提spring的SPI擴展，先來看看JAVA本身自帶的SPI擴展機制是怎么一回事。
八股文背多了，相信大家都聽說過一個詞，SPI擴展。
有的面試官就很喜歡問這個問題，SpringBoot的自動裝配是如何實現的？
基本上，你一說是基于spring的SPI擴展機制，再把spring.factories文件和EnableAutoConfiguration提一下，那么這個問題就答的八九不離十了。
就像四五年前，我去面試的時候被問到這個問題，SPI動態擴展機制這幾個詞從嘴里一說出來，就把面試官唬的一愣一愣的?？赡芩麄円矝]見過這么能裝逼的，一句話能簡簡單單說明白，非要拽一個聽上去很高大上的詞。
話說回來，被唬住的可不止是面試官，其實還有我自己。至于SPI擴展究竟是個啥，是怎么實現的，我當時也根本不明白。
不過現在的面試就是這樣，對線八股文，要想唬住面試官，就得先唬住自己。
那么我們今天暫且不提spring的SPI擴展，先來看看java本身自帶的SPI擴展機制是怎么一回事。
1、簡介
SPI的全稱是Service Provider Interface，翻譯過來就是服務提供者的接口，它所實現的其實是一種服務的發現機制。
這么說起來可能還是有點不好理解，我舉個例子來類比一下。
在spring項目中，寫service層代碼前，會約定俗成的會添加一個接口層。然后通過spring中的依賴注入，可以借助@Autowired等方式注入這個接口的實現類的實例對象，之后對于service的調用一般也基于接口操作。
簡單形容就是這樣的：
如圖所示，接口、實現類都是由服務提供方提供，我們可以把controller看作服務調用者，調用方只管調用接口就可以了。
雖然也有聲音認為，大部分情況下service只有一個實現類，接口層顯得有些多余。但是在《Head First Design Patterns》這本書中，大佬們還是建議過：
Program to an interface, not an implementation.
沒錯，就是常說的要面向接口編程。至于好處，也不外乎是降低耦合度、方便日后擴展、提高了代碼的靈活性和可維護性等等。
在上面這個例子里，這個接口層和其中的方法我們可以稱之為API，而我們要討論的SPI和它相比，有類似也有差異，還是先看圖：
簡單來說，就是服務的調用方定義一個接口規范，可以由不同的服務提供者實現。并且，調用方能夠通過某種機制來發現服務提供方，并通過接口調用它的能力。
通過對比，我們可以看出它們雖然都有著接口這一層面，但還是有很大的不同：
API中的接口是服務提供者給服務調用者的一個功能列表，而SPI中更多強調的是，服務調用者對服務實現的一種約束，服務提供者根據這種約束實現的服務，可以被服務調用者發現。
說白了，Java中的SPI實現的就是，你按我的接口規范實現服務，我就能通過某種機制為這個接口尋找到這個服務。
這么說起來可能還有些抽象，下面我們舉一個例子，類比具體描述一下這個過程。
2、定義接口
說起智能家居系統，大家現在都比較熟悉了，只要是相同品牌下的產品，連上wifi就能夠通過手機App控制了，非常方便。
雖然產品不斷更新換代，型號更新層出不窮，但是同種家電在app上操作起來，功能一般都是一樣的。就拿空調來說，我們在app上操作起來一般也就三個主要功能：開關，選模式，調節溫度。
假設我現在在客廳、臥室、書房安裝了3款不同型號的空調，并把它們都接入到了我app中，那么之后的操作都是相同的幾個按鍵，簡單粗暴。
思考一下，無論是開關還是調溫，都是通過app去調用設備的接口罷了，那么如果不同型號的空調各寫各的接口，后端app在開發的時候光對接接口都麻煩的要死。
解決方法也很簡單，我先定義一套接口規范，不管你以后什么型號的空調，都按我的規范來實現接口。以后只要我能發現你的設備，那么都可以按相同的方法來調用接口。
那么下面就先來定義這么一套接口規范，如果你以后想要接入智能家居系統，那么就要遵循這個規范來開發接口。
新建一個項目作為標準，就叫aircondition-standard好了，然后創建一個接口。除了3個操作以外，我們再添加一個獲取空調型號的方法。
public interface IAircondition {
// 獲取型號
String getType();
// 開關
void turnOnOff();
// 調節溫度
void adjustTemperature(int temperature);
// 模式變更
void changeModel(int modelId);
}
這個接口后面要給服務的實現方來使用，用maven把它打成jar包：
mvn clean install
之后服務提供者在項目中就可以引入這個jar包了，有了這套規范，就保證了產品后期不管怎么更新換代，都能接入到系統來。
3、服務實現
制定并發布完規則后，掛式空調作為第一個服務提供者就來了，新建一個項目aircondition-hanging-type，并引入剛才打好的jar包：
<dependency>
<groupId>com.cn.hydra</groupId>
<artifactId>aircondition-standard</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
創建服務類，并實現前面定義的接口：
public class HangingTypeAircondition
implements IAircondition{
public String getType() {
return "HangingType";
}
public void turnOnOff() {
System.out.println("掛式空調開關");
}
public void adjustTemperature(int i) {
System.out.println("掛式空調調節溫度");
}
public void changeModel(int i) {
System.out.println("掛式空調更換模式");
}
}
在項目的resources的目錄下，創建META-INF/services目錄，然后以前面定義的接口名com.cn.hydra.IAircondition創建文件，并在文件中寫入實現類的全限定名。
com.cn.hydra.HangingTypeAircondition
整個項目結構非常簡單：
這樣，一個服務方的簡單實現就搞定了，用maven打成jar包，之后就可以提供給調用方使用了。
同理，我們可以再創建一個立式空調的項目aircondition-vertical-type，也只創建一個服務類：
public class VerticalTypeAircondition
implements IAircondition{
public String getType() {
return "VerticalType";
}
public void turnOnOff() {
System.out.println("立式空調開關");
}
public void adjustTemperature(int i) {
System.out.println("立式空調調節溫度");
}
public void changeModel(int i) {
System.out.println("立式空調更換模式");
}
}
還是按上面的命名規則，創建一個配置文件：
com.cn.hydra.VerticalTypeAircondition
同樣，打成jar包就完事了，至于服務調用者如何去發現和調用這兩個服務，下面詳細再說。
4、服務發現
現在兩個服務提供方都實現了接口，下面關鍵的一步就是服務發現，這一步java中的spi發現機制已經幫我們實現好了。
創建一個新項目aircondition-app，引入上面打好的兩個jar包。
<dependencies>
<dependency>
<groupId>com.cn.hydra</groupId>
<artifactId>aircondition-hanging-type</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.cn.hydra</groupId>
<artifactId>aircondition-vertical-type</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
按照上面的說法，雖然每個服務提供者對于接口都有不同的實現，但是作為調用者來說，它并不需要關心具體的實現類，我們要做的是通過接口來調用服務提供者實現的方法。
下面，就是關鍵的服務發現環節，我們寫一個方法，根據型號去調用對應空調的開關方法。
public class AirconditionApp {
public static void main(String[] args) {
new AirconditionApp().turnOn("VerticalType");
}
public void turnOn(String type){
ServiceLoader<IAircondition> load = ServiceLoader
.load(IAircondition.class);
for (IAircondition iAircondition : load) {
System.out.println("檢測到:"+iAircondition.getClass().getSimpleName());
if (type.equals(iAircondition.getType())){
iAircondition.turnOnOff();
}
}
}
}
測試結果：
可以看到，測試過程中，通過定義的接口IAircondition發現了兩個實現類，并通過參數，調用了特定實現類的某個方法。整段代碼中沒有出現過具體的服務實現類，操作都是通過接口調用。
5、原理
了解了spi的工作流程，我們再來看看它的實現，其實最關鍵的就是上面代碼中出現的ServiceLoader這個類。
上面的示例代碼中，對于ServiceLoader的load()方法的結果，我們用for循環進行了遍歷，這一點我們看一下源碼就能明白，因為ServiceLoader實現了Iterable這一接口，而整個服務發現的核心，就在它的iterator()方法中。
注意這里面有兩個關鍵的東西，找一下在源碼中定義的地方：
注釋寫的非常明白，providers就是一個緩存，在迭代器中如果先從這里面進行查找，如果里面有就繼續往下找，沒有了的話就用這個懶加載的lookupIterator查找。
那么就簡單了，接著往下看LazyIterator，看看它里面的hasNext()和next()兩個方法是怎么實現的。
這個acc是一個安全管理器，在前面通過System.getSecurityManager()判斷并賦值，debug看一下這里都是null，所以直接看hasNextService()和nextService()方法就可以了。
在hasNextService()方法中，會取出接口取出實現類的類名放到nextName中：
接下來，在nextService()方法中，則會先加載這個實現類，然后實例化對象，最終放入緩存中去。
在迭代器的迭代過程中，會完成所有實現類的實例化，其實歸根結底，還是基于java反射去實現的。
6、應用
要說spi的實際應用，大家最常見的應該就是日志框架slf4j了，它利用spi實現了插槽式接入其他具體的日志框架。
說白了，slf4j本身就是個日志門面，并不提供具體的實現，需要綁定其他具體實現才能真正的引入日志功能。
例如我們可使用log4j2作為具體的綁定器，只需要在pom中引入slf4j-log4j12，就可以使用具體功能。
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.3</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>2.0.3</version>
</dependency>
引入項目后，點開它的jar包看一下具體結構：
有沒有發現一個彩蛋，先說為什么我們pom中引入的明明是slf4j-log4j12，實際上引入的是slf4j-reload4j？翻一下官網的文檔：
大意就是在2015年和2022年，log4j1.x就已經宣布end of life終止了，原因也不難猜，估計是因為頻繁爆出的漏洞。在那之后，slf4j-log4j在構建階段就會自動重定向到slf4j-reload4j了，并且官方也強烈建議使用slf4j-reload4j作為替代。
再回頭看一下jar包的META-INF.services里面，通過spi注入了Reload4jServiceProvider這個實現類，它實現了SLF4JServiceProvider這一接口，在它的初始化方法initialize()中，會完成初始化等工作，后續可以繼續獲取到LoggerFactory和Logger等具體日志對象。
7、總結
Java中的SPI提供了一種比較特別的服務發現和調用機制，通過接口靈活的將服務調用與服務提供者分離，用于提供給第三方實現擴展時還是很方便的。但是也有缺點，比方說一旦加載一個接口，就會把所有實現類都加載進來，可能會加載到不需要的冗余服務。不過站在整體角度上，還是給我們提供了一種非常不錯的框架擴展、集成的思路。
