什麼是SPI
SPI的全稱是Service Provider Interface，顧名思義即服務提供者介面，相比API Application Programming Interface他們的不同之處在於API是應用提供給外部的功能，而SPI則更傾向於是規定好規範，具體實現由使用方自行實現。
為什麼要使用SPI
SPI提供方提供介面定義，使用方負責實現，這種方式更有利於解藕程式碼。在有統一標準，但是不確定使用場景的場合非常適用。
怎麼使用SPI
接下來我會用一個簡單的例子來介紹如何使用SPI：
首先我們在二方包中定義一個介面Plugin：
public interface Plugin {
String getName();
void execute();
}然後將二方包編譯打包後在自己的應用專案中引入，之後實現二方包中的介面Plugin，下面我寫了三個不同的實現：
public class DBPlugin implements Plugin {
@Override
public String getName() {
return "database";
}
@Override
public void execute() {
System.out.println("execute database plugin");
}
}public class MqPlugin implements Plugin {
@Override
public String getName() {
return "mq";
}
@Override
public void execute() {
System.out.println("execute mq plugin");
}
}public class RedisPlugin implements Plugin {
@Override
public String getName() {
return "redis";
}
@Override
public void execute() {
System.out.println("execute redis plugin");
}
}之後在resources目錄下的META-INF.services目錄中新增以介面全限定名命名的檔案。最後在這個檔案中新增上述三個實現的全限定名就完成了配置。
com.example.springprovider.spi.impl.DBPlugin
com.example.springprovider.spi.impl.MqPlugin
com.example.springprovider.spi.impl.RedisPlugin然後我們編寫一段程式碼來看下我們的幾個SPI的實現是否已經裝載成功了。
public void spiTest() {
ServiceLoader<Plugin> serviceLoader = ServiceLoader.load(Plugin.class);
for (Plugin plugin : serviceLoader) {
System.out.println(plugin.getName());
plugin.execute();
}
}執行程式碼，結果已經正常輸出，上述配置成功！
SPI的原理
上述的例子是成功的執行起來了，但是大家應該還是會有問題，為什麼這麼配置就可以執行了？檔名或者路徑一定就需要按照上述的規定來配置嗎？
要了解這些問題，我們就需要從原始碼的角度來深入的看一下。
此處使用JDK8的原始碼來進行講解，JDK9之後引入了module機制導致這部分程式碼為了相容module也進行了大改，變得更為複雜不利於理解，因此如果有興趣可以自行了解
要了解SPI的實現，最主要的就是ServiceLoader，這個類是SPI的主要實現。
private static final String PREFIX = "META-INF/services/";
// The class or interface representing the service being loaded
private final Class<S> service;
// The class loader used to locate, load, and instantiate providers
private final ClassLoader loader;
// The access control context taken when the ServiceLoader is created
private final AccessControlContext acc;
// Cached providers, in instantiation order
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// The current lazy-lookup iterator
private LazyIterator lookupIterator;ServiceLoader定義了一系列成員變數，其中最重要的兩個，providers是一個快取搜尋結果的map，lookupIterator是用來搜尋指定類的自定義迭代器。除此之外我們還可以看到定義了一個固定的PREFIX值META-INF/services/，這個就是SPI預設的搜尋路徑。
在自定義迭代器LazyIterator中定義了nextService和hasNextService，這兩個就是SPI搜尋實現類的核心方法。
hasNextService邏輯很簡單，主要是讀取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());
}
nextName = pending.next();
return true;
}nextService主要是裝載類，然後經過判斷後放置入快取的map中
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
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
}接下來在parse函式中呼叫parseLine，在parseLine中解析最終的實現類並返回。至此完整的解析邏輯我們都已經清晰的看到了，回過頭再來看開始的問題應該也都能夠引刃而解了！
AutoService
很多人會覺得SPI的使用上會有一些麻煩，需要建立目錄並且配置相關的檔案，後續SPI產生變動還需要額外維護這個檔案會很頭疼。那麼我在這裡介紹一個SPI的便捷工具，由Google推出的AutoService工具。
使用方法很簡單，在程式碼中引入依賴：
<dependency>
<groupId>com.google.auto.service</groupId>
<artifactId>auto-service</artifactId>
<version>1.0.1</version>
</dependency>之後直接在實現類上新增註解@AutoService(MyProvider.class)，MyProvider配置為介面類即可。
那麼這裡就又有問題了，為什麼AutoService一個註解就能夠實現了而不用像JDK標準那樣生成檔案呢？想知道答案的話我們就又又又需要來看原始碼了。
找到AutoService關鍵的核心原始碼：
private void generateConfigFiles() {
Filer filer = processingEnv.getFiler();
for (String providerInterface : providers.keySet()) {
String resourceFile = "META-INF/services/" + providerInterface;
log("Working on resource file: " + resourceFile);
try {
SortedSet<String> allServices = Sets.newTreeSet();
try {
FileObject existingFile =
filer.getResource(StandardLocation.CLASS_OUTPUT, "", resourceFile);
log("Looking for existing resource file at " + existingFile.toUri());
Set<String> oldServices = ServicesFiles.readServiceFile(existingFile.openInputStream());
log("Existing service entries: " + oldServices);
allServices.addAll(oldServices);
} catch (IOException e) {
log("Resource file did not already exist.");
}
Set<String> newServices = new HashSet<>(providers.get(providerInterface));
if (!allServices.addAll(newServices)) {
log("No new service entries being added.");
continue;
}
log("New service file contents: " + allServices);
FileObject fileObject =
filer.createResource(StandardLocation.CLASS_OUTPUT, "", resourceFile);
try (OutputStream out = fileObject.openOutputStream()) {
ServicesFiles.writeServiceFile(allServices, out);
}
log("Wrote to: " + fileObject.toUri());
} catch (IOException e) {
fatalError("Unable to create " + resourceFile + ", " + e);
return;
}
}
}我們可以發現AutoService的核心思路其實很簡單，就是透過註解的形式簡化你的配置，然後將對應的資料夾以及檔案內容由AutoService程式碼來自動生成。如此的話就不會有相容性問題和後續的版本迭代的問題。
總結
SPI是一種便捷的可擴充套件方式，在實際的開源專案中也被廣泛運用，在本文中我們深入原始碼瞭解了SPI的原理，弄清楚了SPI使用過程中的一些為什麼。除此之外也找到了更加便捷的工具AutoService以及弄清楚了他的底層便捷的邏輯是什麼。雖然因為內容較多可能為能把所有細節展示出來，但是整體上大家也能夠有一個大致的瞭解。如果還有問題，可以在評論區和我互動哦～