八股文背多了，相信大家都聽(tīng)說(shuō)過(guò)一個(gè)詞，SPI 擴(kuò)展 。

有的面試官就很喜歡問(wèn)這個(gè)問(wèn)題，SpringBoot 的自動(dòng)裝配是如何實(shí)現(xiàn)的？

基本上，你一說(shuō)是基于 spring 的 SPI 擴(kuò)展機(jī)制，再把spring.factories文件和EnableAutoConfiguration提一下，那么這個(gè)問(wèn)題就答的八九不離十了。

就像四五年前，我去面試的時(shí)候被問(wèn)到這個(gè)問(wèn)題，SPI 動(dòng)態(tài)擴(kuò)展機(jī)制 這幾個(gè)詞從嘴里一說(shuō)出來(lái)，就把面試官唬的一愣一愣的。可能他們也沒(méi)見(jiàn)過(guò)這么能裝逼的，一句話(huà)能簡(jiǎn)簡(jiǎn)單單說(shuō)明白，非要拽一個(gè)聽(tīng)上去很高大上的詞。

話(huà)說(shuō)回來(lái)，被唬住的可不止是面試官，其實(shí)還有我自己。至于 SPI 擴(kuò)展究竟是個(gè)啥，是怎么實(shí)現(xiàn)的，我當(dāng)時(shí)也根本不明白。

不過(guò)現(xiàn)在的面試就是這樣，對(duì)線(xiàn)八股文，要想唬住面試官，就得先唬住自己。

那么我們今天暫且不提 spring 的 SPI 擴(kuò)展，先來(lái)看看 java 本身自帶的 SPI 擴(kuò)展機(jī)制是怎么一回事。

1、簡(jiǎn)介

SPI 的全稱(chēng)是Service Provider Interface，翻譯過(guò)來(lái)就是服務(wù)提供者的接口 ，它所實(shí)現(xiàn)的其實(shí)是一種服務(wù)的發(fā)現(xiàn)機(jī)制。

這么說(shuō)起來(lái)可能還是有點(diǎn)不好理解，我舉個(gè)例子來(lái)類(lèi)比一下。

在 spring 項(xiàng)目中，寫(xiě) service 層代碼前，會(huì)約定俗成的會(huì)添加一個(gè)接口層。然后通過(guò) spring 中的依賴(lài)注入，可以借助@Autowired等方式注入這個(gè)接口的實(shí)現(xiàn)類(lèi)的實(shí)例對(duì)象，之后對(duì)于 service 的調(diào)用一般也基于接口操作。

簡(jiǎn)單形容就是這樣的：

如圖所示，接口、實(shí)現(xiàn)類(lèi)都是由服務(wù)提供方提供，我們可以把 controller 看作服務(wù)調(diào)用者，調(diào)用方只管調(diào)用接口就可以了。

雖然也有聲音認(rèn)為，大部分情況下 service 只有一個(gè)實(shí)現(xiàn)類(lèi)，接口層顯得有些多余。但是在《Head First Design Patterns》這本書(shū)中，大佬們還是建議過(guò)：

Program to an interface, not an implementation.

沒(méi)錯(cuò)，就是常說(shuō)的要面向接口編程 。至于好處，也不外乎是降低耦合度、方便日后擴(kuò)展、提高了代碼的靈活性和可維護(hù)性等等。

在上面這個(gè)例子里，這個(gè)接口層和其中的方法我們可以稱(chēng)之為API ，而我們要討論的SPI 和它相比，有類(lèi)似也有差異，還是先看圖：

簡(jiǎn)單來(lái)說(shuō)，就是服務(wù)的調(diào)用方定義一個(gè)接口規(guī)范，可以由不同的服務(wù)提供者實(shí)現(xiàn)。并且，調(diào)用方能夠通過(guò)某種機(jī)制來(lái)發(fā)現(xiàn)服務(wù)提供方，并通過(guò)接口調(diào)用它的能力。

通過(guò)對(duì)比，我們可以看出它們雖然都有著接口 這一層面，但還是有很大的不同：

API 中的接口是服務(wù)提供者給服務(wù)調(diào)用者的一個(gè)功能列表，而 SPI 中更多強(qiáng)調(diào)的是，服務(wù)調(diào)用者對(duì)服務(wù)實(shí)現(xiàn)的一種約束，服務(wù)提供者根據(jù)這種約束實(shí)現(xiàn)的服務(wù)，可以被服務(wù)調(diào)用者發(fā)現(xiàn)。

說(shuō)白了，Java 中的 SPI 實(shí)現(xiàn)的就是，你按我的接口規(guī)范實(shí)現(xiàn)服務(wù)，我就能通過(guò)某種機(jī)制為這個(gè)接口尋找到這個(gè)服務(wù)。

這么說(shuō)起來(lái)可能還有些抽象，下面我們舉一個(gè)例子，類(lèi)比具體描述一下這個(gè)過(guò)程。

2、定義接口

說(shuō)起智能家居系統(tǒng)，大家現(xiàn)在都比較熟悉了，只要是相同品牌下的產(chǎn)品，連上 wifi 就能夠通過(guò)手機(jī) app 控制了，非常方便。

雖然產(chǎn)品不斷更新?lián)Q代，型號(hào)更新層出不窮，但是同種家電在 app 上操作起來(lái)，功能一般都是一樣的。就拿空調(diào)來(lái)說(shuō)，我們?cè)?app 上操作起來(lái)一般也就三個(gè)主要功能：開(kāi)關(guān) ，選模式 ，調(diào)節(jié)溫度 。

假設(shè)我現(xiàn)在在客廳、臥室、書(shū)房安裝了 3 款不同型號(hào)的空調(diào)，并把它們都接入到了我 app 中，那么之后的操作都是相同的幾個(gè)按鍵，簡(jiǎn)單粗暴。

思考一下，無(wú)論是開(kāi)關(guān)還是調(diào)溫，都是通過(guò) app 去調(diào)用設(shè)備的接口罷了，那么如果不同型號(hào)的空調(diào)各寫(xiě)各的接口，后端 app 在開(kāi)發(fā)的時(shí)候光對(duì)接接口都麻煩的要死。

解決方法也很簡(jiǎn)單，我先定義一套接口規(guī)范，不管你以后什么型號(hào)的空調(diào)，都按我的規(guī)范來(lái)實(shí)現(xiàn)接口。以后只要我能發(fā)現(xiàn)你的設(shè)備，那么都可以按相同的方法來(lái)調(diào)用接口。

那么下面就先來(lái)定義這么一套接口規(guī)范，如果你以后想要接入智能家居系統(tǒng)，那么就要遵循這個(gè)規(guī)范來(lái)開(kāi)發(fā)接口。

新建一個(gè)項(xiàng)目作為標(biāo)準(zhǔn)，就叫aircondition-standard好了，然后創(chuàng)建一個(gè)接口。除了 3 個(gè)操作以外，我們?cè)偬砑右粋€(gè)獲取空調(diào)型號(hào)的方法。

publicinterfaceIAircondition{
//獲取型號(hào)
StringgetType();

//開(kāi)關(guān)
voidturnOnOff();

//調(diào)節(jié)溫度
voidadjustTemperature(inttemperature);

//模式變更
voidchangeModel(intmodelId);
}

這個(gè)接口后面要給服務(wù)的實(shí)現(xiàn)方來(lái)使用，用 maven 把它打成 jar 包：

mvncleaninstall

之后服務(wù)提供者在項(xiàng)目中就可以引入這個(gè) jar 包了，有了這套規(guī)范，就保證了產(chǎn)品后期不管怎么更新?lián)Q代，都能接入到系統(tǒng)來(lái)。

3、服務(wù)實(shí)現(xiàn)

制定并發(fā)布完規(guī)則后，掛式空調(diào) 作為第一個(gè)服務(wù)提供者就來(lái)了，新建一個(gè)項(xiàng)目aircondition-hanging-type，并引入剛才打好的 jar 包：

com.cn.hydra
aircondition-standard
1.0-SNAPSHOT

創(chuàng)建服務(wù)類(lèi)，并實(shí)現(xiàn)前面定義的接口：

publicclassHangingTypeAircondition
implementsIAircondition{
publicStringgetType(){
return"HangingType";
}

publicvoidturnOnOff(){
System.out.println("掛式空調(diào)開(kāi)關(guān)");
}

publicvoidadjustTemperature(inti){
System.out.println("掛式空調(diào)調(diào)節(jié)溫度");
}

publicvoidchangeModel(inti){
System.out.println("掛式空調(diào)更換模式");
}
}

在項(xiàng)目的resources的目錄下，創(chuàng)建META-INF/services目錄，然后以前面定義的接口名com.cn.hydra.IAircondition創(chuàng)建文件，并在文件中寫(xiě)入實(shí)現(xiàn)類(lèi)的全限定名。

com.cn.hydra.HangingTypeAircondition

整個(gè)項(xiàng)目結(jié)構(gòu)非常簡(jiǎn)單：

這樣，一個(gè)服務(wù)方的簡(jiǎn)單實(shí)現(xiàn)就搞定了，用 maven 打成 jar 包，之后就可以提供給調(diào)用方使用了。

同理，我們可以再創(chuàng)建一個(gè)立式空調(diào) 的項(xiàng)目aircondition-vertical-type，也只創(chuàng)建一個(gè)服務(wù)類(lèi)：

publicclassVerticalTypeAircondition
implementsIAircondition{
publicStringgetType(){
return"VerticalType";
}

publicvoidturnOnOff(){
System.out.println("立式空調(diào)開(kāi)關(guān)");
}

publicvoidadjustTemperature(inti){
System.out.println("立式空調(diào)調(diào)節(jié)溫度");
}

publicvoidchangeModel(inti){
System.out.println("立式空調(diào)更換模式");
}
}

還是按上面的命名規(guī)則，創(chuàng)建一個(gè)配置文件：

com.cn.hydra.VerticalTypeAircondition

同樣，打成 jar 包就完事了，至于服務(wù)調(diào)用者如何去發(fā)現(xiàn)和調(diào)用這兩個(gè)服務(wù)，下面詳細(xì)再說(shuō)。

4、服務(wù)發(fā)現(xiàn)

現(xiàn)在兩個(gè)服務(wù)提供方都實(shí)現(xiàn)了接口，下面關(guān)鍵的一步就是服務(wù)發(fā)現(xiàn)，這一步 java 中的 spi 發(fā)現(xiàn)機(jī)制已經(jīng)幫我們實(shí)現(xiàn)好了。

創(chuàng)建一個(gè)新項(xiàng)目aircondition-app，引入上面打好的兩個(gè) jar 包。

com.cn.hydra
aircondition-hanging-type
1.0-SNAPSHOT



com.cn.hydra
aircondition-vertical-type
1.0-SNAPSHOT

按照上面的說(shuō)法，雖然每個(gè)服務(wù)提供者對(duì)于接口都有不同的實(shí)現(xiàn)，但是作為調(diào)用者來(lái)說(shuō)，它并不需要關(guān)心具體的實(shí)現(xiàn)類(lèi)，我們要做的是通過(guò)接口來(lái)調(diào)用服務(wù)提供者實(shí)現(xiàn)的方法。

下面，就是關(guān)鍵的服務(wù)發(fā)現(xiàn)環(huán)節(jié)，我們寫(xiě)一個(gè)方法，根據(jù)型號(hào)去調(diào)用對(duì)應(yīng)空調(diào)的開(kāi)關(guān)方法。

publicclassAirconditionApp{
publicstaticvoidmain(String[]args){
newAirconditionApp().turnOn("VerticalType");
}

publicvoidturnOn(Stringtype){
ServiceLoaderload=ServiceLoader
.load(IAircondition.class);

for(IAirconditioniAircondition:load){
System.out.println("檢測(cè)到:"+iAircondition.getClass().getSimpleName());
if(type.equals(iAircondition.getType())){
iAircondition.turnOnOff();
}
}
}
}

測(cè)試結(jié)果：

可以看到，測(cè)試過(guò)程中，通過(guò)定義的接口IAircondition發(fā)現(xiàn)了兩個(gè)實(shí)現(xiàn)類(lèi)，并通過(guò)參數(shù)，調(diào)用了特定實(shí)現(xiàn)類(lèi)的某個(gè)方法。整段代碼中沒(méi)有出現(xiàn)過(guò)具體的服務(wù)實(shí)現(xiàn)類(lèi)，操作都是通過(guò)接口調(diào)用。

5、原理

了解了 spi 的工作流程，我們?cè)賮?lái)看看它的實(shí)現(xiàn)，其實(shí)最關(guān)鍵的就是上面代碼中出現(xiàn)的ServiceLoader這個(gè)類(lèi)。

上面的示例代碼中，對(duì)于ServiceLoader的load()方法的結(jié)果，我們用for循環(huán)進(jìn)行了遍歷，這一點(diǎn)我們看一下源碼就能明白，因?yàn)镾erviceLoader實(shí)現(xiàn)了Iterable這一接口，而整個(gè)服務(wù)發(fā)現(xiàn)的核心，就在它的iterator()方法中。

注意這里面有兩個(gè)關(guān)鍵的東西，找一下在源碼中定義的地方：

注釋寫(xiě)的非常明白，providers就是一個(gè)緩存，在迭代器中如果先從這里面進(jìn)行查找，如果里面有就繼續(xù)往下找，沒(méi)有了的話(huà)就用這個(gè)懶加載的lookupIterator查找。

那么就簡(jiǎn)單了，接著往下看LazyIterator，看看它里面的hasNext()和next()兩個(gè)方法是怎么實(shí)現(xiàn)的。

這個(gè)acc是一個(gè)安全管理器，在前面通過(guò)System.getSecurityManager()判斷并賦值，debug 看一下這里都是null，所以直接看hasNextService()和nextService()方法就可以了。

在hasNextService()方法中，會(huì)取出接口取出實(shí)現(xiàn)類(lèi)的類(lèi)名放到nextName中：

接下來(lái)，在nextService()方法中，則會(huì)先加載這個(gè)實(shí)現(xiàn)類(lèi)，然后實(shí)例化對(duì)象，最終放入緩存中去。

在迭代器的迭代過(guò)程中，會(huì)完成所有實(shí)現(xiàn)類(lèi)的實(shí)例化，其實(shí)歸根結(jié)底，還是基于 java 反射去實(shí)現(xiàn)的。

6、應(yīng)用

要說(shuō) spi 的實(shí)際應(yīng)用，大家最常見(jiàn)的應(yīng)該就是日志框架slf4j了，它利用 spi 實(shí)現(xiàn)了插槽式接入其他具體的日志框架。

說(shuō)白了，slf4j本身就是個(gè)日志門(mén)面，并不提供具體的實(shí)現(xiàn)，需要綁定其他具體實(shí)現(xiàn)才能真正的引入日志功能。

例如我們可使用log4j2作為具體的綁定器，只需要在 pom 中引入slf4j-log4j12，就可以使用具體功能。

org.slf4j
slf4j-api
2.0.3


org.slf4j
slf4j-log4j12
2.0.3

引入項(xiàng)目后，點(diǎn)開(kāi)它的 jar 包看一下具體結(jié)構(gòu)：

有沒(méi)有發(fā)現(xiàn)一個(gè)彩蛋，先說(shuō)為什么我們 pom 中引入的明明是slf4j-log4j12，實(shí)際上引入的是slf4j-reload4j？翻一下官網(wǎng)的文檔：

大意就是在 2015 年和 2022 年，log4j1.x就已經(jīng)宣布end of life終止了，原因也不難猜，估計(jì)是因?yàn)轭l繁爆出的漏洞。在那之后，slf4j-log4j在構(gòu)建階段就會(huì)自動(dòng)重定向到slf4j-reload4j了，并且官方也強(qiáng)烈建議使用slf4j-reload4j作為替代。

再回頭看一下 jar 包的META-INF.services里面，通過(guò) spi 注入了Reload4jServiceProvider這個(gè)實(shí)現(xiàn)類(lèi)，它實(shí)現(xiàn)了SLF4JServiceProvider這一接口，在它的初始化方法initialize()中，會(huì)完成初始化等工作，后續(xù)可以繼續(xù)獲取到LoggerFactory和Logger等具體日志對(duì)象。

7、總結(jié)

Java 中的 SPI 提供了一種比較特別的服務(wù)發(fā)現(xiàn)和調(diào)用機(jī)制，通過(guò)接口靈活的將服務(wù)調(diào)用與服務(wù)提供者分離，用于提供給第三方實(shí)現(xiàn)擴(kuò)展時(shí)還是很方便的。但是也有缺點(diǎn)，比方說(shuō)一旦加載一個(gè)接口，就會(huì)把所有實(shí)現(xiàn)類(lèi)都加載進(jìn)來(lái)，可能會(huì)加載到不需要的冗余服務(wù)。不過(guò)站在整體角度上，還是給我們提供了一種非常不錯(cuò)的框架擴(kuò)展、集成的思路。

審核編輯：劉清