Java SPI機制探究

1 SPI是什麼

SPI全稱Service Provider Interface,是Java提供的一套用來被第三方實現或者擴展的API,它可以用來啓用框架擴展和替換組件。

整體機制圖如下:

 

 

Java SPI 實際上是“基於接口的編程+策略模式+配置文件”組合實現的動態加載機制。

系統設計的各個抽象,往往有很多不同的實現方案,在面向的對象的設計裏,一般推薦模塊之間基於接口編程,模塊之間不對實現類進行硬編碼。一旦代碼裏涉及具體的實現類,就違反了可拔插的原則,如果需要替換一種實現,就需要修改代碼。爲了實現在模塊裝配的時候能不在程序裏動態指明,這就需要一種服務發現機制。 Java SPI就是提供這樣的一個機制:爲某個接口尋找服務實現的機制。有點類似IOC的思想,就是將裝配的控制權移到程序之外,在模塊化設計中這個機制尤其重要。所以SPI的核心思想就是解耦

2 使用場景

概括地說,適用於:調用者根據實際使用需要,啓用、擴展、或者替換框架的實現策略

比較常見的例子:

  • 數據庫驅動加載接口實現類的加載 JDBC加載不同類型數據庫的驅動
  • 日誌門面接口實現類加載 SLF4J加載不同提供商的日誌實現類
  • Spring Spring中大量使用了SPI,比如:對servlet3.0規範對ServletContainerInitializer的實現、自動類型轉換Type Conversion SPI(Converter SPI、Formatter SPI)等
  • Dubbo Dubbo中也大量使用SPI的方式實現框架的擴展, 不過它對Java提供的原生SPI做了封裝,允許用戶擴展實現Filter接口

3 使用介紹

要使用Java SPI,需要遵循如下約定:

  • 1、當服務提供者提供了接口的一種具體實現後,在jar包的META-INF/services目錄下創建一個以“接口全限定名”爲命名的文件,內容爲實現類的全限定名;
  • 2、接口實現類所在的jar包放在主程序的classpath中;
  • 3、主程序通過java.util.ServiceLoder動態裝載實現模塊,它通過掃描META-INF/services目錄下的配置文件找到實現類的全限定名,把類加載到JVM;
  • 4、SPI的實現類必須攜帶一個不帶參數的構造方法;

示例代碼

步驟1、定義一組接口 (假設是org.foo.demo.IShout),並寫出接口的一個或多個實現,(假設是org.foo.demo.animal.Dog、org.foo.demo.animal.Cat)。

public interface IShout {
    void shout();
}
public class Cat implements IShout {
    @Override
    public void shout() {
        System.out.println("miao miao");
    }
}
public class Dog implements IShout {
    @Override
    public void shout() {
        System.out.println("wang wang");
    }
}
複製代碼

步驟2、在 src/main/resources/ 下建立 /META-INF/services 目錄, 新增一個以接口命名的文件 (org.foo.demo.IShout文件),內容是要應用的實現類(這裏是org.foo.demo.animal.Dog和org.foo.demo.animal.Cat,每行一個類)。

文件位置

- src
    -main
        -resources
            - META-INF
                - services
                    - org.foo.demo.IShout
複製代碼

文件內容

org.foo.demo.animal.Dog
org.foo.demo.animal.Cat
複製代碼

步驟3、使用 ServiceLoader 來加載配置文件中指定的實現。

public class SPIMain {
    public static void main(String[] args) {
        ServiceLoader<IShout> shouts = ServiceLoader.load(IShout.class);
        for (IShout s : shouts) {
            s.shout();
        }
    }
}
複製代碼

代碼輸出:

wang wang
miao miao
複製代碼

4 原理解析

首先看ServiceLoader類的簽名類的成員變量:

public final class ServiceLoader<S> implements Iterable<S>{
private static final String PREFIX = "META-INF/services/";

    // 代表被加載的類或者接口
    private final Class<S> service;

    // 用於定位,加載和實例化providers的類加載器
    private final ClassLoader loader;

    // 創建ServiceLoader時採用的訪問控制上下文
    private final AccessControlContext acc;

    // 緩存providers,按實例化的順序排列
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();

    // 懶查找迭代器
    private LazyIterator lookupIterator;
  
    ......
}
複製代碼

參考具體ServiceLoader具體源碼,代碼量不多,加上註釋一共587行,梳理了一下,實現的流程如下:

  • 1 應用程序調用ServiceLoader.load方法 ServiceLoader.load方法內先創建一個新的ServiceLoader,並實例化該類中的成員變量,包括:

    • loader(ClassLoader類型,類加載器)
    • acc(AccessControlContext類型,訪問控制器)
    • providers(LinkedHashMap<String,S>類型,用於緩存加載成功的類)
    • lookupIterator(實現迭代器功能)
  • 2 應用程序通過迭代器接口獲取對象實例 ServiceLoader先判斷成員變量providers對象中(LinkedHashMap<String,S>類型)是否有緩存實例對象,如果有緩存,直接返回。 如果沒有緩存,執行類的裝載,實現如下:

  • (1) 讀取META-INF/services/下的配置文件,獲得所有能被實例化的類的名稱,值得注意的是,ServiceLoader可以跨越jar包獲取META-INF下的配置文件,具體加載配置的實現代碼如下:

        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);
        }
複製代碼
  • (2) 通過反射方法Class.forName()加載類對象,並用instance()方法將類實例化。
  • (3) 把實例化後的類緩存到providers對象中,(LinkedHashMap<String,S>類型) 然後返回實例對象。

5 總結

優點: 使用Java SPI機制的優勢是實現解耦,使得第三方服務模塊的裝配控制的邏輯與調用者的業務代碼分離,而不是耦合在一起。應用程序可以根據實際業務情況啓用框架擴展或替換框架組件。

缺點

  • 雖然ServiceLoader也算是使用的延遲加載,但是基本只能通過遍歷全部獲取,也就是接口的實現類全部加載並實例化一遍。如果你並不想用某些實現類,它也被加載並實例化了,這就造成了浪費。獲取某個實現類的方式不夠靈活,只能通過Iterator形式獲取,不能根據某個參數來獲取對應的實現類。
  • 多個併發多線程使用ServiceLoader類的實例是不安全的。

轉自:https://juejin.im/post/5b9b1c115188255c5e66d18c

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章