前言

最近在面試的時候被問到SPI了，沒回答上來，主要也是自己的原因，把自己給帶溝里去了，因為講到了類加載器的雙親委派模型，后面就被問到了有哪些是破壞了雙親委派模型的場景，然后我就說到了SPI，JNDI，以及JDK9的模塊化都破壞了雙親委派。然后就被問，那你說說對Java中的SPI的理解吧。然后我就一臉懵逼了，之前只是知道它會破壞雙親委派，也知道是個怎么回事，但是并沒有深入了解，那么這次我就好好的來總結一下這個知識吧。

什么是SPI

SPI全稱Service Provider Interface，字面意思是提供服務的接口，再解釋詳細一下就是Java提供的一套用來被第三方實現(xiàn)或擴展的接口，實現(xiàn)了接口的動態(tài)擴展，讓第三方的實現(xiàn)類能像插件一樣嵌入到系統(tǒng)中。

咦。。。這個解釋感覺還是有點繞口。那就說一下它的本質。

將接口的實現(xiàn)類的全限定名配置在文件中（文件名是接口的全限定名），由服務加載器讀取配置文件，加載實現(xiàn)類。實現(xiàn)了運行時動態(tài)為接口替換實現(xiàn)類。

SPI示例

還是舉例說明吧。我們創(chuàng)建一個項目，然后創(chuàng)建一個module叫spi-interface。

在這個module中我們定義一個接口：

/** * @author jimoer **/public interface SpiInterfaceService { /** * 打印參數(shù) * @param parameter 參數(shù) */ void printParameter(String parameter);}

再定義一個module，名字叫spi-service-one，pom.xml中依賴spi-interface。在spi-service-one中定義一個實現(xiàn)類，實現(xiàn)SpiInterfaceService 接口。

package com.jimoer.spi.service.one;import com.jimoer.spi.app.SpiInterfaceService;/** * @author jimoer **/public class SpiOneService implements SpiInterfaceService { /** * 打印參數(shù) * * @param parameter 參數(shù) */ @Override public void printParameter(String parameter) { System.out.println('我是SpiOneService:'+parameter); }}

然后再spi-service-one的resources目錄下創(chuàng)建目錄META-INF/services，在此目錄下創(chuàng)建一個文件名稱為SpiInterfaceService接口的全限定名稱，文件內容寫入SpiOneService這個實現(xiàn)類的全限定名稱。效果如下：

再創(chuàng)建一個module，名稱為：spi-service-one，也是依賴spi-interface，并且定義一個實現(xiàn)類SpiTwoService 來實現(xiàn)SpiInterfaceService 接口。

package com.jimoer.spi.service.two;import com.jimoer.spi.app.SpiInterfaceService;/** * @author jimoer **/public class SpiTwoService implements SpiInterfaceService { /** * 打印參數(shù) * * @param parameter 參數(shù) */ @Override public void printParameter(String parameter) { System.out.println('我是SpiTwoService:'+parameter); }}

目錄結構如下：

下面再創(chuàng)建一個用來測試的module，名為：spi-app。

pom.xml中依賴spi-service-one和spi-service-two

<dependencies> <dependency> <groupId>com.jimoer.spi</groupId> <artifactId>spi-service-one</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>com.jimoer.spi</groupId> <artifactId>spi-service-two</artifactId> <version>1.0-SNAPSHOT</version> </dependency></dependencies>

創(chuàng)建測試類

/** * @author jimoer **/public class SpiService { public static void main(String[] args) { ServiceLoader<SpiInterfaceService> spiInterfaceServices = ServiceLoader.load(SpiInterfaceService.class); Iterator<SpiInterfaceService> iterator = spiInterfaceServices.iterator(); while (iterator.hasNext()){ SpiInterfaceService sip = iterator.next(); sip.printParameter('參數(shù)'); } }}

執(zhí)行結果：

我是SpiTwoService:參數(shù)我是SpiOneService:參數(shù)

通過運行結果我們可以看到，已經(jīng)將SpiInterfaceService接口的所有實現(xiàn)都加載到了當前項目中，并且執(zhí)行了調用。

這整個代碼結構我們可以看出SPI機制將模塊的裝配放到了程序外面，就是說，接口的實現(xiàn)可以在程序外面，只需要在使用的時候指定具體的實現(xiàn)。并且動態(tài)的加載到自己的項目中。SPI機制的主要目的：一是為了解耦，將接口和具體實現(xiàn)分離開來；二是提高框架的擴展性。以前寫程序的時候，接口和實現(xiàn)都寫在一起，調用方在使用的時候依賴接口來進行調用，無權選擇使用具體的實現(xiàn)類。

SPI的實現(xiàn)

那么我們來看一下SPI具體是如何實現(xiàn)的呢？通過上面的例子，我們可以看到，SPI機制的核心代碼是下面這段：

ServiceLoader<SpiInterfaceService> spiInterfaceServices = ServiceLoader.load(SpiInterfaceService.class);

那么我們來看一下ServiceLoader.load()方法的源碼：

public static <S> ServiceLoader<S> load(Class<S> service) { ClassLoader cl = Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl);}

看到Thread.currentThread().getContextClassLoader()；我就明白是怎么回事了，這個就是線程上下文類加載器，因為線程上下文類加載器就是為了做類加載雙親委派模型的逆序而創(chuàng)建的。

使用這個線程上下文類加載器去加載所需的SPI服務代碼，這是一種父類加載器去請求子類加載器完成類加載的行為，這種行為實際上是打通了，雙親委派模型的層次結構來逆向使用類加載器，已經(jīng)違背了雙親委派模型的一般性原則，但也是無可奈何的事情?！渡钊肜斫釰ava虛擬機（第三版）》

雖然知道了它是破壞雙親委派的了，但是具體實現(xiàn)，還是需要具體往下看的。

在ServiceLoader里找到具體實現(xiàn)hasNext()的方法了，那么繼續(xù)來看這個方法的實現(xiàn)。

hasNext()方法又主要調用了hasNextService()方法。

// 固定路徑private static final String PREFIX = 'META-INF/services/';private boolean hasNextService() { if (nextName != null) { return true; } if (configs == null) { try { // 固定路徑+接口全限定名稱 String fullName = PREFIX + service.getName(); // 如果當前線程上下文類加載器為空，會用父類加載器（默認是應用程序類加載器） if (loader == null) configs = ClassLoader.getSystemResources(fullName); else configs = loader.getResources(fullName); } catch (IOException x) { fail(service, 'Error locating configuration files', x); } } while ((pending == null) || !pending.hasNext()) { if (!configs.hasMoreElements()) { return false; } pending = parse(service, configs.nextElement()); } // 后面next()方法中判斷當前類是否已經(jīng)出現(xiàn)化的時候要用 nextName = pending.next(); return true; }

主要就是去加載META-INF/services/路徑下的接口全限定名稱的文件然后去里面找到實現(xiàn)類的類路徑將實現(xiàn)類進行類加載。

繼續(xù)看迭代器是如何取出每一個實現(xiàn)對象的。那就要看ServiceLoader中實現(xiàn)了迭代器的next()方法了。

next()方法主要是nextService()實現(xiàn)的，那么繼續(xù)看nextService()方法。

private S nextService() { if (!hasNextService()) throw new NoSuchElementException(); String cn = nextName; nextName = null; Class<?> c = null; try { // 直接加載類，無需初始化（因為上面hasNext()已經(jīng)初始化了）。 c = Class.forName(cn, false, loader); } catch (ClassNotFoundException x) { fail(service, 'Provider ' + cn + ' not found'); } if (!service.isAssignableFrom(c)) { fail(service, 'Provider ' + cn + ' not a subtype'); } try { // 將加載好的類實例化出對象。 S p = service.cast(c.newInstance()); providers.put(cn, p); return p; } catch (Throwable x) { fail(service, 'Provider ' + cn + ' could not be instantiated', x); } throw new Error(); // This cannot happen }

看到這里就可以明白了，是如何創(chuàng)建出對象的了。先在hasNext()將接口的實現(xiàn)類進行加載并判斷是否存在接口的實現(xiàn)類，然后在next()方法中將實現(xiàn)類進實例化。

Java中使用SPI機制的功能其實有很多，像JDBC、JNDI、以及Spring中也有使用，甚至RPC框架（Dubbo）中也有使用SPI機制來實現(xiàn)功能。

以上就是Java中SPI的一些理解的詳細內容，更多關于Java SPI的資料請關注好吧啦網(wǎng)其它相關文章！