為什么需要SPI？

思考一個場景，我們封裝了一套服務(wù)，別人通過引入我們寫好的包，就可以使用這些接口API，完成相應(yīng)的操作，這本來沒有什么問題，但是會存在使用該服務(wù)的實體有不相同的業(yè)務(wù)需求，需要進一步的擴展，但是由于api是寫好的，想要擴展并非那么的簡單，如果存在這樣子的場景，我們該怎么辦？

可以使用Java 提供的SPI機制

什么是SPI？SPI和API的區(qū)別

SPI

SPI的全稱是Service Provider Interface，是Java提供的可用于第三方實現(xiàn)和擴展的機制，通過該機制，我們可以實現(xiàn)解耦，SPI接口方負責(zé)定義和提供默認實現(xiàn)，SPI調(diào)用方可以按需擴展

API的全稱是Application Programming Interface，廣義上來看就是接口，負責(zé)程序與程序之間進行協(xié)作的通道，就好比上面給的例子，【我們封裝好了一套服務(wù)，通過API的形式提供給他人使用，別人使用API就能得到想要的】

所以他們倆的區(qū)別就很明顯了，API的調(diào)用方只能依賴使用提供方的實現(xiàn)，SPI就如同可定制化的API一樣，調(diào)用方可以自定義實現(xiàn)替換API提供的默認實現(xiàn)

來人，上點對抗

首先，我們新建一個空的maven項目，里邊有兩個包

spi-provider從名字就可以得知是SPI的提供方

spi-user SPI的使用方

spi-provider

我們簡單定義一個SPI接口，就叫ISpiTest，里邊就一個saySomething方法，再提供一個默認的實現(xiàn)

public interface ISpiTest {
	void saySomething();
}

public class DefaultSpiImplementation implements ISpiTest{
	@Override
	public void saySomething() {
		System.out.println("[默認實現(xiàn)] -> 今天也是充滿希望的一天");
	}
}

然后，模擬走流程，注意步驟4是我們之后要自定義替換的

/**
 * 模擬一套流程
 * @author Amg
 * @date 2021/12/9
 */
public class TestUtils {
	
	public static void workFlow(ISpiTest s) {
		
		System.out.println("1、步驟1.......");
		System.out.println("2、步驟2.......");
		System.out.println("3、步驟3.......");
		System.out.print("4、步驟4：");
		s.saySomething();
		System.out.println("5、步驟5.......");
	}
}

接著，重點來了，我們需要在resources目錄下面創(chuàng)建/META-INF/services文件夾，然后以SPI接口的全限定類名作為名稱創(chuàng)建一個文件

往文件里面填寫實現(xiàn)類的全限定類名，如下

com.amg.spi.DefaultSpiImplementation

到此，spi-provider這個模塊就完成了，至于之后要怎么使用，到spi-user模塊中進一步說明

spi-user

首先，我們在pom文件中，引入spi-provider坐標(biāo)依賴

?然后定義main方法，在main方法中調(diào)用在spi-provider中定義的SPI接口，此時采用的是默認的配置

可以注意到我們使用ServiceLoader這個類的load方法，傳入SPI接口的字節(jié)碼進行構(gòu)造，我們在spi-provider中resources中給出了一個默認實現(xiàn)，但是我們是在spi-user中去調(diào)用的，ServiceLoader會自動讀取META-INF下的配置文件，就算是跨jar包也是可以的

然后現(xiàn)在我們在spi-user中定義一個實現(xiàn)類，以及把他配置到META-INF下（需要注意，這個配置的全限定類名仍然需要是spi-provider中定義SPI接口的路徑），來看看效果

spi-user下META-INF里邊內(nèi)容如下

com.amg.spiuser.service.impl.WantHamburger

可以發(fā)現(xiàn)，我們并沒有改變?nèi)魏蔚目蛻舳舜a，只是把配置文件進行了簡單的修改，即可完成自定義實現(xiàn)，這就是使用SPI的魅力

??思考一下，我們之前的流程是怎么做的

首先定義了一個接口，面向接口編程嘛定義配置文件各個自定義的實現(xiàn)類，只需要按照規(guī)則重寫配置文件即可

總結(jié)

通過這個流程，我們可以歸納為一句話，SPI是策略模式的一種體現(xiàn)，配合面向接口編程的思想以及必要的配置文件，即可完成定義和具體實現(xiàn)的解耦，而且是可定制化的API

SPI的優(yōu)點有以下

定制化實現(xiàn)接口解耦

SPI的缺點有以下

通過觀察ServiceLoader，可以發(fā)現(xiàn)并沒有額外的加鎖機制，所以會存在并發(fā)問題獲取對應(yīng)的實現(xiàn)類不夠靈活，從上面例子可以看出，需要使用迭代器的方式獲取需要知道接口的所有具體實現(xiàn)類，所以每次都要加載和實例化所有的實現(xiàn)類

實際中，SPI的使用還是很常見的，例如Dubbo和Spring Boot都為我們提供了一套SPI機制，只不過此SPI是在Java提供的SPI機制基礎(chǔ)上進行改造而來，有興趣的同學(xué)也可以去查下資料，增長增長

到此這篇關(guān)于Java SPI機制詳細介紹的文章就介紹到這了,更多相關(guān)Java SPI機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！