什么是SPI
SPI全稱Service Provider Interface，是Java提供的一套用來被第三方實現或者擴展的API，它可以用來啟用框架擴展和替換組件。 SPI的作用就是為這些被擴展的API尋找服務實現。
- API （Application Programming Interface）在大多數情況下，都是實現方制定接口並完成對接口的實現，調用方僅僅依賴接口調用，且無權選擇不同實現。 從使用人員上來說，API 直接被應用開發人員使用。
- SPI （Service Provider Interface）是調用方來制定接口規范，提供給外部來實現，調用方在調用時則選擇自己需要的外部實現。 從使用人員上來說，SPI 被框架擴展人員使用。
整體機制圖如下：
Java SPI 實際上是“基於接口的編程＋策略模式＋配置文件”組合實現的動態加載機制。
系統設計的各個抽象，往往有很多不同的實現方案，在面向的對象的設計里，一般推薦模塊之間基於接口編程，模塊之間不對實現類進行硬編碼。一旦代碼里涉及具體的實現類，就違反了可拔插的原則，如果需要替換一種實現，就需要修改代碼。為了實現在模塊裝配的時候能不在程序里動態指明，這就需要一種服務發現機制。
Java SPI就是提供這樣的一個機制：為某個接口尋找服務實現的機制。有點類似IOC的思想，就是將裝配的控制權移到程序之外，在模塊化設計中這個機制尤其重要。所以SPI的核心思想就是解耦。
使用場景
概括地說，適用於：調用者根據實際使用需要，啟用、擴展、或者替換框架的實現策略
比較常見的例子：
- 數據庫驅動加載接口實現類的加載，JDBC加載不同類型數據庫的驅動
- 日志門面接口實現類加載，SLF4J加載不同提供商的日志實現類
- Spring，Spring中大量使用了SPI,比如：對servlet3.0規范對ServletContainerInitializer的實現、自動類型轉換Type Conversion SPI(Converter SPI、Formatter SPI)等
- Dubbo，Dubbo中也大量使用SPI的方式實現框架的擴展, 不過它對Java提供的原生SPI做了封裝，允許用戶擴展實現Filter接口
使用介紹
要使用Java SPI，需要遵循如下約定：
- 當服務提供者提供了接口的一種具體實現后，在jar包的META-INF/services目錄下創建一個以“接口全限定名”為命名的文件，內容為實現類的全限定名；
- 接口實現類所在的jar包放在主程序的classpath中；
- 主程序通過java.util.ServiceLoder動態裝載實現模塊，它通過掃描META-INF/services目錄下的配置文件找到實現類的全限定名，把類加載到JVM；
- SPI的實現類必須攜帶一個不帶參數的構造方法；
示例代碼
step1. 定義接口
package org.ray.spi; public interface Human { public void speak(); }
step2. 定義實現類
package org.ray.spi; public class Chinese implements Human{ @Override public void speak() { System.out.println("哈嘍 我的"); } }
package org.ray.spi; public class English implements Human{ @Override public void speak() { System.out.println("hello world"); } }
step3. 定義配置文件
在classpath（src/main/resources）下創建META-INF/resources目錄，創建以接口名字org.ray.spi.Human命名的文件，內容寫入接口實現類的全限定類名，如果有多個需換行
org.ray.spi.English
org.ray.spi.Chinese
step4. 執行ServiceLoader
public static void main(String[] args) throws IOException { ServiceLoader<Human> load = ServiceLoader.load(Human.class); for (Human human : load) { human.speak(); } }
step5. 查看輸出
hello world
哈嘍 我的
源碼分析
ServiceLoader在這里沒有核心操作，主要負責對外提供load()方法用於獲取SPI接口和實例化懶加載迭代器LazyIterator
public final class ServiceLoader<S> implements Iterable<S>{ #SPI規則固定加載文件地址前綴 private static final String PREFIX = "META-INF/services/"; #SPI的接口 private final Class<S> service; #類加載器,使用的是當前線程的類加載器(Thread.currentThread().getContextClassLoader()) private final ClassLoader loader; #默認是null, 創建ServiceLoader時采用的訪問控制上下文 private final AccessControlContext acc; #緩存加載成功的類 private LinkedHashMap<String,S> providers = new LinkedHashMap<>(); #當前的迭代器,默認初始化為LazyIterator，注意這里是懶加載的,只有使用的時候才去迭代加載SPI文件 private LazyIterator lookupIterator; #SPI執行使用方法，不指定ClassLoader public static <S> ServiceLoader<S> load(Class<S> service) { ClassLoader cl = Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); } #SPI執行使用方法，指定ClassLoader public static <S> ServiceLoader<S> load(Class<S> service,ClassLoader loader){ return new ServiceLoader<>(service, loader); } #構造方法中保存SPI接口，初始化懶加載迭代器 private ServiceLoader(Class<S> svc, ClassLoader cl) { service = Objects.requireNonNull(svc, "Service interface cannot be null"); loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl; acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null; reload(); } #初始化懶加載迭代器 public void reload() { providers.clear(); lookupIterator = new LazyIterator(service, loader); } }
LazyIterator是懶加載，實例化后什么也不干，只保存了SPI接口
private class LazyIterator implements Iterator<S> { private LazyIterator(Class<S> service, ClassLoader loader) { this.service = service; this.loader = loader; } }
ServiceLoader的iterator()方法被調用，開始執行核心邏輯LazyIterator懶加載SPI文件
- hasNextService()：用於加載META-INF/services/下SPI文件
- nextService()：用於根據SPI文件中指定的實現類的全限定類名通過反射實例化對象，放入緩存
private class LazyIterator implements Iterator<S> { private boolean hasNextService() { if (nextName != null) { return true; } if (configs == null) { try { #拼裝SPI文件完整地址META-INF/services+SPI全限定類名 String fullName = PREFIX + service.getName(); if (loader == null) configs = ClassLoader.getSystemResources(fullName); else #加載SPI文件 configs = loader.getResources(fullName); } catch (IOException x) { fail(service, "Error locating configuration files", x); } } while ((pending == null) || !pending.hasNext()) { if (!configs.hasMoreElements()) { return false; } #解析SPI文件，獲取實現類全限定類名 pending = parse(service, configs.nextElement()); } #賦值實現類全限定類名 nextName = pending.next(); return true; } private S nextService() { if (!hasNextService()) throw new NoSuchElementException(); String cn = nextName; nextName = null; Class<?> c = null; try { #根據全限定類名獲取Class描述文件 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 { #根據Class文件使用反射創建對象 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 } }
總結
優點：
使用Java SPI機制的優勢是實現解耦，使得第三方服務模塊的裝配控制的邏輯與調用者的業務代碼分離，而不是耦合在一起。應用程序可以根據實際業務情況啟用框架擴展或替換框架組件。
相比使用提供接口jar包，供第三方服務模塊實現接口的方式，SPI的方式使得源框架不必關心接口的實現類的路徑，可以不用通過下面的方式獲取接口實現類：
代碼硬編碼import 導入實現類
指定類全路徑反射獲取：例如在JDBC4.0之前，JDBC中獲取數據庫驅動類需要通過Class.forName(“com.mysql.jdbc.Driver”)，類似語句先動態加載數據庫相關的驅動，然后再進行獲取連接等的操作
第三方服務模塊把接口實現類實例注冊到指定地方，源框架從該處訪問實例
通過SPI的方式，第三方服務模塊實現接口后，在第三方的項目代碼的META-INF/services目錄下的配置文件指定實現類的全路徑名，源碼框架即可找到實現類
缺點：
雖然ServiceLoader也算是使用的延遲加載，但是基本只能通過遍歷全部獲取，也就是接口的實現類全部加載並實例化一遍。如果你並不想用某些實現類，它也被加載並實例化了，這就造成了浪費。獲取某個實現類的方式不夠靈活，只能通過Iterator形式獲取，不能根據某個參數來獲取對應的實現類。
多個並發多線程使用ServiceLoader類的實例是不安全的。
轉載：https://blog.csdn.net/dcr782195101/article/details/122004685
