SPI 機制，全稱為 Service Provider Interface，是一種服務發現機制。它通過在 ClassPath 路徑下的 META-INF/services 資料夾查詢檔案，自動載入檔案裡所定義的類。這一機制為很多框架擴充套件提供了可能，比如在 Dubbo、JDBC 中都使用到了 SPI 機制。本文介紹了 Java SPI 機制以及在模組化和非模組話專案中的實現方式(此處的模組化指 Java9 引入的模組化)

SPI 機制介紹

SPI 全稱 Service Provider Interface，是 Java 提供的一套用來被第三方實現或者擴充套件的介面，它可以用來啟用框架擴充套件和替換元件。 SPI 的作用就是為這些被擴充套件的 API 尋找服務實現。

SPI 和 API 的區別

API （Application Programming Interface）在大多數情況下，都是實現方制定介面並完成對介面的實現，呼叫方僅僅依賴介面呼叫，且無權選擇不同實現。 從使用人員上來說，API 直接被應用開發人員使用。如下圖所示，其中模組 A 為介面制定方和實現方，而模組 B 為介面的使用放。

維基百科關於 API 的描述：In building applications, an API (application programming interface) simplifies programming by abstracting the underlying implementation and only exposing objects or actions the developer needs. While a graphical interface for an email client might provide a user with a button that performs all the steps for fetching and highlighting new emails, an API for file input/output might give the developer a function that copies a file from one location to another without requiring that the developer understand the file system operations occurring behind the scenes.

SPI （Service Provider Interface）是呼叫方來制定介面規範，提供給外部來實現，呼叫方在呼叫時則選擇自己需要的外部實現，可用於啟用框架擴充套件和可替換元件。 從使用人員上來說，SPI 被框架擴充套件人員使用。如下圖所示，A 模組是介面的定義方和使用方，而 B 模組則是介面實現方。

SPI 維基百科定義：Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party. It can be used to enable framework extension and replaceable components

SPI java 官方定義：A service is a well-known set of interfaces and (usually abstract) classes. A service provider(SPI) is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers can be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers can also be made available by adding them to the application's class path or by some other platform-specific means.

SPI 的優點

使用 Java SPI 機制的優勢是實現解耦，使得介面的定義與具體業務實現分離，而不是耦合在一起。應用程序可以根據實際業務情況啟用或替換具體元件。以 java 中的 JDBC 資料庫驅動為例，java 官方在核心庫制定了 java.sql.Driver 資料庫驅動介面，使用該介面實現了資料庫連結等邏輯，但是並沒有具體實現資料庫驅動介面，而是交給 MySql 等廠商去實現具體的資料庫介面。

引用自部落格：Java SPI 主要是應用於廠商自定義元件或外掛中。在 java.util.ServiceLoader 的文件裡有比較詳細的介紹。簡單的總結下 java SPI 機制的思想：我們系統裡抽象的各個模組，往往有很多不同的實現方案，比如日誌模組、xml 解析模組、jdbc 模組等方案。面向的物件的設計裡，我們一般推薦模組之間基於介面程式設計，模組之間不對實現類進行硬編碼。一旦程式碼裡涉及具體的實現類，就違反了可拔插的原則，如果需要替換一種實現，就需要修改程式碼。為了實現在模組裝配的時候能不在程式裡動態指明，這就需要一種服務發現機制。 Java SPI 就是提供這樣的一個機制：為某個介面尋找服務實現的機制。有點類似 IOC 的思想，就是將裝配的控制權移到程式之外，在模組化設計中這個機制尤其重要。

SPI 的約定

服務提供方需要通過一些約定告訴系統自己所提供的服務的位置，java9 之後一共有兩種約定方式：

1. 通過在 META-INF/services/ 目錄下配置相關檔案實現。
2. 通過 java9 jigsaw 的匯出語句指定服務位置。

   A service provider is a single type, usually a concrete class. An interface or abstract class is permitted because it may declare a static provider method, discussed later. The type must be public and must not be an inner class.
   A service provider and its supporting code may be developed in a module, which is then deployed on the application module path or in a modular image. Alternatively, a service provider and its supporting code may be packaged as a JAR file and deployed on the application class path. The advantage of developing a service provider in a module is that the provider can be fully encapsulated to hide all details of its implementation.
   An application that obtains a service loader for a given service is indifferent to whether providers of the service are deployed in modules or packaged as JAR files. The application instantiates service providers via the service loader's iterator, or via Provider objects in the service loader's stream, without knowledge of the service providers' locations.

模組化語句約定

模組化語句約定適用於專案已經模組化的情況，以 java.sql.Driver 為例，在模組化檔案 module-info.java 中新增如下語句，就可以嚮應用提供指定的服務：

provides java.sql.Driver with com.wangzemin.learning.provider.TestDriverProvider;

下文以一個自定義的 java.sql.Driver 服務提供者（也可以自己隨意再另外一個模組定義一個介面）為例，展示 SPI 在 java 模組化情況下約定的使用方式。

1. 示例專案目錄結構：
本文提供了一個完整的例子用於測試主要包含三個檔案，TestDriverProvider(自定義的 Driver 服務提供者)，module-info.java（java 模組化檔案），Main（用於除錯以及輸出結果）

2. 示例檔案內容
TestDriverProvider.java

public class TestDriverProvider implements Driver {
    // Override 的方法都為空。
}

模組化檔案 module-info.java：

module provider {
    uses java.sql.Driver;
    requires java.sql;
    // 指定自定義的TestDriverProvider為Driver服務的提供者
    provides java.sql.Driver with com.wangzemin.learning.provider.TestDriverProvider;
}

主函式（ServiceLoader 用於查詢合適的服務提供者，下文會詳細介紹）：

public class Main {
    public static void main(String[] args) {
        ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class);
        for (Driver item : loader) {
            System.out.println("Get class:" + item.getClass().descriptorString());
        }
    }
}

3. 示例的輸出

Get class:Lcom/wangzemin/learning/provider/TestDriverProvider;

由輸出可以看到，ServiceLoader 可以成功定位到 TestDriverProvider。

模組化約定官方原文：
A service provider that is developed in a module must be specified in a provides directive in the module declaration. The provides directive specifies both the service and the service provider; this helps to locate the provider when another module, with a uses directive for the service, obtains a service loader for the service. It is strongly recommended that the module does not export the package containing the service provider. There is no support for a module specifying, in a provides directive, a service provider in another module.
A service provider that is developed in a module has no control over when it is instantiated, since that occurs at the behest of the application, but it does have control over how it is instantiated:
If the service provider declares a provider method, then the service loader invokes that method to obtain an instance of the service provider. A provider method is a public static method named "provider" with no formal parameters and a return type that is assignable to the service's interface or class.
In this case, the service provider itself need not be assignable to the service's interface or class.
If the service provider does not declare a provider method, then the service provider is instantiated directly, via its provider constructor. A provider constructor is a public constructor with no formal parameters.
In this case, the service provider must be assignable to the service's interface or class
A service provider that is deployed as an automatic module on the application module path must have a provider constructor. There is no support for a provider method in this case.
As an example, suppose a module specifies the following directives:

 provides com.example.CodecFactory with com.example.impl.StandardCodecs;
 provides com.example.CodecFactory with com.example.impl.ExtendedCodecsFactory;

where
com.example.CodecFactory is the two-method service from earlier.
com.example.impl.StandardCodecs is a public class that implements CodecFactory and has a public no-args constructor.
com.example.impl.ExtendedCodecsFactory is a public class that does not implement CodecFactory, but it declares a public static no-args method named "provider" with a return type of CodecFactory.
A service loader will instantiate StandardCodecs via its constructor, and will instantiate ExtendedCodecsFactory by invoking its provider method. The requirement that the provider constructor or provider method is public helps to document the intent that the class (that is, the service provider) will be instantiated by an entity (that is, a service loader) which is outside the class's package.

配置檔案約定

配置檔案約定適用於專案沒有模組化的情況，需要在 classpath 下的 META-INF/services/ 目錄裡建立一個以服務介面命名的文件，這個文件裡的內容就是這個介面的具體的實現類。

下文同樣以一個自定義的 java.sql.Driver 服務提供者（也可以自己隨意再另外一個模組定義一個介面）為例，展示 SPI 在 java 配置檔案約定下的使用方式。

1. 示例專案目錄結構：
本文提供了一個完整的例子用於測試主要包含三個檔案，TestDriverProvider(自定義的 Driver 服務提供者，和上文一致)，Main（用於除錯以及輸出結果，和上文一致），META-INF/services/java.sql.Driver 檔案（用於指定服務提供著的位置）

2. 示例檔案內容
TestDriverProvider 和 Main 與上文中均一致，不再次詳述，此處僅僅展示 META-INF/services/java.sql.Driver 檔案的內容，該檔案只包含一行內容：

com.wangzemin.learning.learning.provider.TestDriverProvider

3. 示例的輸出

Get class:Lcom/wangzemin/learning/provider/TestDriverProvider;

由輸出可以看到，ServiceLoader 可以成功定位到 TestDriverProvider。

配置檔案約定官方原文
A service provider that is packaged as a JAR file for the class path is identified by placing a provider-configuration file in the resource directory META-INF/services. The name of the provider-configuration file is the fully qualified binary name of the service. The provider-configuration file contains a list of fully qualified binary names of service providers, one per line.
For example, suppose the service provider com.example.impl.StandardCodecs is packaged in a JAR file for the class path. The JAR file will contain a provider-configuration file named:
META-INF/services/com.example.CodecFactory
that contains the line:
com.example.impl.StandardCodecs # Standard codecs
The provider-configuration file must be encoded in UTF-8. Space and tab characters surrounding each service provider's name, as well as blank lines, are ignored. The comment character is '#' ('\u0023' NUMBER SIGN); on each line all characters following the first comment character are ignored. If a service provider class name is listed more than once in a provider-configuration file then the duplicate is ignored. If a service provider class is named in more than one configuration file then the duplicate is ignored.
A service provider that is mentioned in a provider-configuration file may be located in the same JAR file as the provider-configuration file or in a different JAR file. The service provider must be visible from the class loader that is initially queried to locate the provider-configuration file; this is not necessarily the class loader which ultimately locates the provider-configuration file.

SPI 原理

上文講述了 SPI 的一些約定，那麼有了這些約定之後，SPI 機制是如何定位到對應的服務提供者的類並進行載入的呢？SPI 服務的載入可以分為兩部分：

1. 類全稱限定名的獲取，即知道哪些類是服務提供者。
2. 類載入，把獲取到的類載入到記憶體中，涉及上下文類載入器。

類限定名獲取

模組化情況下

可以參考jigsaw 官方文件，jigsaw 模組化語法本身就支援 SPI 服務，通過 provide xxxx with yyyy，可以為 xxxx 服務指定一個服務提供者 yyyy，這個解析過程由 jigsaw 實現。

官方文件說明：Services allow for loose coupling between service consumers modules and service providers modules.This example has a service consumer module and a service provider module:

1. module com.socket exports an API for network sockets. The API is in package com.socket so this package is exported. The API is pluggable to allow for alternative implementations. The service type is class com.socket.spi.NetworkSocketProvider in the same module and thus package com.socket.spi is also exported.
2. module org.fastsocket is a service provider module. It provides an implementation of com.socket.spi.NetworkSocketProvider. It does not export any packages.

配置的情況下

在指定配置的情況下，ServiceLoader.load 根據傳入的介面類，遍歷 META-INF/services 目錄下的以該類命名的檔案中的所有類，然再用類載入器載入這些服務。

類載入器載入

獲取到 SPI 服務實現類的檔案之後，就可以使用類載入器將對應的類載入到記憶體中， 問題在於，SPI 的介面是 Java 核心庫的一部分，是由引導類載入器來載入的；SPI 實現的 Java 類一般是由系統類載入器來載入的。引導類載入器是無法找到 SPI 的實現類的，因為它只加載 Java 的核心庫。它也不能代理給系統類載入器，因為它是系統類載入器的祖先類載入器。也就是說，類載入器的雙親委派模型無法解決這個問題。所以 java 採用了執行緒上下文類載入器。破壞了“雙親委派模型”，可以在執行執行緒中拋棄雙親委派載入鏈模式，使程式可以逆向使用類載入器，從而實現 SPI 服務的載入。執行緒上下文類載入器的實現如下：

1. 在 ThreaLocal 中通過 setContextClassLoader​(ClassLoader cl)儲存當前執行緒中的類載入器，預設為 AppClassLoader。
2. Java 核心庫中的程式在需要載入 SPI 實現類的時候，會首先通過 ThreaLocal 中的 getContextClassLoader​(ClassLoader cl)方法獲取上下文類載入器，然後通過該類載入器載入 SPI 的實現類。

ServiceLoader

參考官方文件。ServiceLoader 是用於載入 SPI 服務實現類的工具，可以處理 0 個、1 個或者多個服務提供商的情況。

官方說明：A facility to load implementations of a service.A service is a well-known interface or class for which zero, one, or many service providers exist. A service provider (or just provider) is a class that implements or subclasses the well-known interface or class. A ServiceLoader is an object that locates and loads service providers deployed in the run time environment at a time of an application’s choosing. Application code refers only to the service, not to service providers, and is assumed to be capable of differentiating between multiple service providers as well as handling the possibility that no service providers are located.

其主要方法為 public static ServiceLoader load​(Class service, ClassLoader loader)，該方法根據需要載入的 SPI 介面和類載入器（預設情況為執行緒上下文類載入器），生成一個 ServiceLoader，生成的 ServiceLoader 可以通過迭代器 Iterotor 或 stream 的方式獲取 SPI 的實現類。載入主要分為兩部分：模組化的服務類載入和非模組化的類載入。最後會對所有載入到的實現類排序。
注意：載入的服務類如果包含網路資源，可能會出現一些異常情況。

If the class path of the class loader includes remote network URLs then those URLs may be dereferenced in the process of searching for provider-configuration files.
This activity is normal, although it may cause puzzling entries to be created in web-server logs. If a web server is not configured correctly, however, then this activity may cause the provider-loading algorithm to fail spuriously.
A web server should return an HTTP 404 (Not Found) response when a requested resource does not exist. Sometimes, however, web servers are erroneously configured to return an HTTP 200 (OK) response along with a helpful HTML error page in such cases. This will cause a ServiceConfigurationError to be thrown when this class attempts to parse the HTML page as a provider-configuration file. The best solution to this problem is to fix the misconfigured web server to return the correct response code (HTTP 404) along with the HTML error page.

上文說到，SPI 可能有很多服務提供者，但是隻有其中一些是有用的，這種情況下我們就需要對 ServiceLoader 獲取到的服務實現類進行過濾，比如，我們只需要 PNG 格式的 CodecFactory，那麼我們就可以對對應的服務實現類新增一個自定義的@PNG 註解，然後通過下文過濾得到所需的服務提供者：

 ServiceLoader<CodecFactory> loader = ServiceLoader.load(CodecFactory.class);
 Set<CodecFactory> pngFactories = loader
        .stream()                                              // Note a below
        .filter(p -> p.type().isAnnotationPresent(PNG.class))  // Note b
        .map(Provider::get)                                    // Note c
        .collect(Collectors.toSet());

我是御狐神，歡迎大家關注我的微信公眾號

本文最先發布至微信公眾號，版權所有，禁止轉載！