Java基础之SPI机制
一、概述
SPI(Service Provider Interface)，是JDK内置的一种服务注册与发现的机制，通过解耦服务提供者与服务使用者，实现了服务创建 & 服务使用的关注点分离。用来启用框架扩展和替换组件，这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制。
Java中SPI机制主要思想是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是解耦。
工作原理：
当服务的提供者提供了一种接口的实现之后，需要在classpath下的META-INF/services/目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体的实现类。
当其他的程序需要这个服务的时候，就可以通过查找这个jar包(一般都是以jar包做依赖)的META-INF/services/中的配置文件，配置文件中有接口的具体实现类名，可以根据这个类名进行加载实例化，就可以使用该服务了。
JDK中查找服务的实现的工具类是：java.util.ServiceLoader。
服务提供模式可以为我们带来以下好处：
- 在外部注入或配置依赖项，因此我们可以重用这些组件。当我们需要修改依赖项的实现时，不需要大量修改很多处代码，只需要修改一小部分代码；
- 可以注入依赖项的模拟实现，让代码测试更加容易。
二、案例
首先，我们需要定义一个接口SPIService。
package com.viewscenes.netsupervisor.spi;
public interface SPIService {
void execute();
}
然后，定义两个实现类。
package com.viewscenes.netsupervisor.spi;
public class SpiImpl1 implements SPIService {
public void execute() {
System.out.println("SpiImpl1.execute()");
}
}
public class SpiImpl2 implements SPIService {
public void execute() {
System.out.println("SpiImpl2.execute()");
}
}
最后要在ClassPath路径下配置添加一个文件。文件名字是接口的全限定类名，内容是实现类的全限定类名，多个实现类用换行符分隔。
文件路径如下：
内容就是实现类的全限定类名：
com.viewscenes.netsupervisor.spi.SpiImpl1
com.viewscenes.netsupervisor.spi.SpiImpl2
测试
然后我们就可以通过ServiceLoader.load或者Service.providers方法获得实现类的实例。
import sun.misc.Service;
import java.util.ServiceLoader;
public class Test {
public static void main(String[] args) {
Iterator<SPIService> providers = Service.providers(SPIService.class);
ServiceLoader<SPIService> load = ServiceLoader.load(SPIService.class);
while(providers.hasNext()) {
SPIService ser = providers.next();
ser.execute();
}
System.out.println("--------------------------------");
Iterator<SPIService> iterator = load.iterator();
while(iterator.hasNext()) {
SPIService ser = iterator.next();
ser.execute();
}
}
}
两种方式的输出结果是一致的：
SpiImpl1.execute()
SpiImpl2.execute()
--------------------------------
SpiImpl1.execute()
SpiImpl2.execute()
三、源码分析
我们看到一个位于sun.misc包，一个位于java.util包，sun包下的源码看不到。我们就以ServiceLoader.load为例，通过源码看看它里面到底怎么做的。
3.1 ServiceLoader
首先，我们先来了解下ServiceLoader，看看它的类结构。
public final class ServiceLoader<S> implements Iterable<S> {
//配置文件的路径
private static final String PREFIX = "META-INF/services/";
//加载的服务类或接口
private final Class<S> service;
//已加载的服务类集合
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
//类加载器
private final ClassLoader loader;
//内部类，真正加载服务类
private LazyIterator lookupIterator;
//...
}
3.2 Load
load方法创建了一些属性，重要的是实例化了内部类LazyIterator。最后返回ServiceLoader的实例。
public final class ServiceLoader<S> implements Iterable<S> {
//...
public static <S> ServiceLoader<S> load(Class<S> service) {
// 获取当前线程的类加载器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader) {
// 创建ServiceLoader对象
return new ServiceLoader<>(service, loader);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
// 断一下传入的接口class对象是否合法
service = Objects.requireNonNull(svc, "Service interface cannot be null");
// 类加载器，如果线程的classLoad没有，默认采用SystemClassLoader
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
// 权限访问控制
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
public void reload() {
// 先把之前的缓存清了
providers.clear();
// 创建懒迭代器对象。
lookupIterator = new LazyIterator(service, loader);
}
//...
}
reload方法，先是将缓存清了，又创建懒迭代器对象。这个懒加载迭代器是ServiceLoader的一个内部类。
3.3 LazyIterator
查找实现类和创建实现类的过程，都在LazyIterator完成。
3.3.1 创建
当我们调用iterator.hasNext和iterator.next方法的时候，实际上调用的都是LazyIterator的相应方法。所以，我们重点关注lookupIterator.hasNext()方法，它最终会调用到hasNextService。当然，调用next方法的时候，实际调用到的是lookupIterator.nextService。它通过反射的方式，创建实现类的实例并返回。
private class LazyIterator implements Iterator<S> {
Class<S> service;
ClassLoader loader;
Enumeration<URL> configs = null;
Iterator<String> pending = null;
String nextName = null;
private LazyIterator(Class<S> service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
private boolean hasNextService() {
// 第二次调用的时候，已经解析完成了，直接返回
if (nextName != null) {
return true;
}
if (configs == null) {
try {
// META-INF/services/ 加上接口的全限定类名，就是文件服务类的文件
// META-INF/services/com.viewscenes.netsupervisor.spi.SPIService
String fullName = PREFIX + service.getName();
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
// 将文件路径转成URL对象
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}
}
while ((pending == null) || !pending.hasNext()) {
if (!configs.hasMoreElements()) {
return false;
}
// 解析URL文件对象，读取内容，最后返回
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 {
// 通过newInstance实例化
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
}
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public S next() {
if (acc == null) {
return nextService();
} else {
PrivilegedAction<S> action = new PrivilegedAction<S>() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public void remove() {
throw new UnsupportedOperationException();
}
}
ServiceLoader.load核心是清除缓存，创建lazyIterator，其用来类加载，遍历SPI实现类。
3.3.2 加载
加载是在LazyIterator中完成的，而且是在当我们判断获取的时候才加载。
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
private boolean hasNextService() {
if (nextName != null) {
return true;
}
if (configs == null) {
try {
// 拼接路径 META-INF/services/spi接口名称
String fullName = PREFIX + service.getName();
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
// 获取spi接口实现类url
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}
}
// 第一次的时候 或者 pending没有 下一个元素的时候
while ((pending == null) || !pending.hasNext()) {
if (!configs.hasMoreElements()) {
return false;
}
// 获得一个 迭代器。
pending = parse(service, configs.nextElement());
}
nextName = pending.next();
return true;
}
在hasNextService方法中，先是判断一下下一个的元素名有没有，有的话直接返回true。判断config == null这个第一次的时候会进入，拼接默认spi接口实现类存放的路径，形成一个url。接着就会解析这个文件，获得一个迭代器对象。这个url实际上就是spi接口文件地址。
说白了，上述操作，就是想获取到要加载的指定SPI实现类文件，获取到文件，读取配置项，也即获取SPI接口实现类列表。
private Iterator<String> parse(Class<?> service, URL u)
throws ServiceConfigurationError {
InputStream in = null;
BufferedReader r = null;
// 存储 扩展实现类的接口的全类名
ArrayList<String> names = new ArrayList<>();
try {
in = u.openStream();
// 通过BufferedReader来一行一行的读取
r = new BufferedReader(new InputStreamReader(in, "utf-8"));
int lc = 1;
// 通过BufferedReader来一行一行的读取
while ((lc = parseLine(service, u, r, lc, names)) >= 0);
} catch (IOException x) {
fail(service, "Error reading configuration file", x);
} finally {
try {
if (r != null) r.close();
if (in != null) in.close();
} catch (IOException y) {
fail(service, "Error closing configuration file", y);
}
}
// 最后返回 集合的迭代器
return names.iterator();
}
parse(service, configs.nextElement())方法。可以看出parse方法通过BufferedReader一行行读取配置文件存入List中，最后返回List的迭代器。
加载的过程，就是找到SPI接口位置，读取SPI接口配置文件，获取其中的实现类。
3.3.3 获取
public S next() {
if (acc == null) {
return nextService();
} else {
PrivilegedAction<S> action = new PrivilegedAction<S>() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
//保存副本
String cn = nextName;
// 设置null
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 {
// 创建对象
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
}
获取SPI实现类对象，本质上通过Class.forName进行类加载获取的，然后放入缓存。
public Iterator<S> iterator() {
return new Iterator<S>() {
Iterator<Map.Entry<String, S>> knownProviders = providers.entrySet().iterator();
public boolean hasNext() {
if (knownProviders.hasNext())
return true;
return lookupIterator.hasNext();
}
public S next() {
if (knownProviders.hasNext())
return knownProviders.next().getValue();
return lookupIterator.next();
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
经过第一次SPI类加载之后，后续所有遍历操作都直接从缓存中拿，除非重新进行ServiceLoader.load重新读取SPI接口文件配置项，进行类加载。
四、JDBC中的SPI机制
我们开头说，SPI机制为很多框架的扩展提供了可能，其实JDBC就应用到了这一机制。回忆一下JDBC获取数据库连接的过程。在早期版本中，需要先设置数据库驱动的连接，再通过DriverManager.getConnection获取一个Connection。
String url = "jdbc:mysql:///consult?serverTimezone=UTC";
String user = "root";
String password = "root";
Class.forName("com.mysql.jdbc.Driver");
Connection connection = DriverManager.getConnection(url, user, password);
在JDBC4.0版本之前需要Class.forName("com.mysql.jdbc.Driver")先加载数据库相关的驱动，然后再进行获取连接等的操作。
JDBC4.0以后，开始支持使用SPI的方式来注册这个Driver。
4.1 加载
我们把目光回到DriverManager类，它在静态代码块里面做了一件比较重要的事。很明显，它已经通过SPI机制，把数据库驱动连接初始化了。
public class DriverManager {
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
}
具体过程还得看loadInitialDrivers，它在里面查找的是Driver接口的服务类，所以它的文件路径就是：META-INF/services/java.sql.Driver。
public class DriverManager {
private static void loadInitialDrivers() {
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
// 很明显，它要加载Driver接口的服务类，Driver接口的包为:java.sql.Driver
// 所以它要找的就是META-INF/services/java.sql.Driver文件
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
try {
// 查到之后创建对象
while (driversIterator.hasNext()) {
driversIterator.next();
}
} catch (Throwable t) {
// Do nothing
}
return null;
}
});
}
}
那么，这个文件哪里有呢？我们来看MySQL的jar包，就是这个文件，文件内容为：com.mysql.cj.jdbc.Driver。
4.2 创建实例
上一步已经找到了MySQL中的com.mysql.cj.jdbc.Driver全限定类名，当调用next方法时，就会创建这个类的实例。它就完成了一件事，向DriverManager注册自身的实例。
public class Driver extends NonRegisteringDriver implements java.sql.Driver {
static {
try {
// 注册
// 调用DriverManager类的注册方法
// 往registeredDrivers集合中加入实例
java.sql.DriverManager.registerDriver(new Driver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
}
public Driver() throws SQLException {
// Required for Class.forName().newInstance()
}
}
4.3 创建Connection
在DriverManager.getConnection()方法就是创建连接的地方，它通过循环已注册的数据库驱动程序，调用其connect方法，获取连接并返回。
private static Connection getConnection(String url, java.util.Properties info,
Class<?> caller) throws SQLException {
// registeredDrivers中就包含com.mysql.cj.jdbc.Driver实例
for (DriverInfo aDriver : registeredDrivers) {
if (isDriverAllowed(aDriver.driver, callerCL)) {
try {
//调用connect方法创建连接
Connection con = aDriver.driver.connect(url, info);
if (con != null) {
return (con);
}
} catch (SQLException ex) {
if (reason == null) {
reason = ex;
}
}
} else {
println("skipping: " + aDriver.getClass().getName());
}
}
}
4.4 再扩展
既然我们知道JDBC是这样创建数据库连接的，我们能不能再扩展一下呢？如果我们自己也创建一个java.sql.Driver文件，自定义实现类MyDriver，那么，在获取连接的前后就可以动态修改一些信息。
还是先在项目ClassPath下创建文件，文件内容为自定义驱动类com.viewscenes.netsupervisor.spi.MyDriver
我们的MyDriver实现类，继承自MySQL中的NonRegisteringDriver，还要实现java.sql.Driver接口。这样，在调用connect方法的时候，就会调用到此类，但实际创建的过程还靠MySQL完成。
package com.viewscenes.netsupervisor.spi;
public class MyDriver extends NonRegisteringDriver implements Driver {
static {
try {
java.sql.DriverManager.registerDriver(new MyDriver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
}
public MyDriver () throws SQLException { }
public Connection connect(String url, Properties info) throws SQLException {
System.out.println("准备创建数据库连接.url:" + url);
System.out.println("JDBC配置信息：" + info);
info.setProperty("user", "root");
Connection connection = super.connect(url, info);
System.out.println("数据库连接创建完成!" + connection.toString());
return connection;
}
}
输出结果
准备创建数据库连接.url:jdbc:mysql:///consult?serverTimezone=UTC
JDBC配置信息：{user=root, password=root}
数据库连接创建完成!com.mysql.cj.jdbc.ConnectionImpl@7cf10a6f
4.5 小结
DriverManager.Class静态初始化内的SPI机制所使用的是：线程上下文类加载器，默认为系统类加载器AppClassLoader。Class.forName()为main方法所在的类的类加载器：系统类加载器AppClassLoader。
所以这里默认是同一个类加载器来加载classpath下面的com.mysql.jdbc.Driver。所以在使用SPI后，不需要显示调用Class.forName()了。
五、Spring中SPI机制
在springboot的自动装配过程中，最终会加载META-INF/spring.factories文件，而加载的过程是由SpringFactoriesLoader加载的。从CLASSPATH下的每个Jar包中搜寻所有META-INF/spring.factories配置文件，然后将解析properties文件，找到指定名称的配置后返回。
需要注意的是，其实这里不仅仅是会去ClassPath路径下查找，会扫描所有路径下的Jar包，只不过这个文件只会在Classpath下的jar包中。
public static final String FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories";
// spring.factories文件的格式为：key=value1,value2,value3
// 从所有的jar包中找到META-INF/spring.factories文件
// 然后从文件中解析出key=factoryClass类名称的所有value值
public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
String factoryClassName = factoryClass.getName();
// 取得资源文件的URL
Enumeration<URL> urls = (classLoader != null
? classLoader.getResources(FACTORIES_RESOURCE_LOCATION)
: ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
List<String> result = new ArrayList<String>();
// 遍历所有的URL
while (urls.hasMoreElements()) {
URL url = urls.nextElement();
// 根据资源文件URL解析properties文件，得到对应的一组@Configuration类
Properties properties = PropertiesLoaderUtils.loadProperties(new UrlResource(url));
String factoryClassNames = properties.getProperty(factoryClassName);
// 组装数据，并返回
result.addAll(Arrays.asList(StringUtils.commaDelimitedListToStringArray(factoryClassNames)));
}
return result;
}
六、总结
SPI机制是java提供的扩展机制，主要用来为第三方应用进行扩展用的，自身服务只需要提供SPI接口，第三方应用自己实现SPI接口即可。
SPI原理无非是内部通过LazyIterator进行处理，先找到SPI配置文件地址，逐一读取配置项，进行类加载获取class。当然内部维护一套缓存机制provider，不需要每次都读取SPI配置文件。
SPI机制优势就是解耦。将接口的定义以及具体业务实现分离，而不是和业务端全部耦合在一端。可以实现运行时根据业务实际场景启用或者替换具体组件。SPI机制的场景就是没有统一实现标准的业务场景。一般就是，服务端有标准的接口，但是没有统一的实现，需要业务方提供其具体实现。比如JDBC的java.sql.Driver接口和不同云厂商提供的数据库实现包。
七、拓展
7.1 SPI和API的区别
SPI - “接口”位于“调用方”所在的“包”中
- 概念上更依赖调用方。
- 组织上位于调用方所在的包中。
- 实现位于独立的包中。
- 常见的例子是：插件模式的插件。
API - “接口”位于“实现方”所在的“包”中
- 概念上更接近实现方。
- 组织上位于实现方所在的包中。
- 实现和接口在一个包中。
7.2 SPI机制的优缺点
优点：
使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，而不是耦合在一起。应用程序可以根据实际业务情况启用框架扩展或替换框架组件。
缺点：
- 不能按需加载，需要遍历所有的实现，并实例化，然后在循环中才能找到我们需要的实现。如果不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
- 获取某个实现类的方式不够灵活，只能通过
Iterator形式获取，不能根据某个参数来获取对应的实现类。 - 多个并发多线程使用
ServiceLoader类的实例不安全。
7.3 双亲委派机制的破坏
在介绍类加载机制的时候我们提到了双亲委派机制，这里还是以sql.Driver为例，调用者DriverManager是在rt.jar中的，ClassLoader是启动类加载器，而com.mysql.jdbc.Driver肯定不在<JAVA_HOME>/lib下，所以肯定是无法加载mysql中的这个类的。这就是双亲委派模型的局限性了，父级加载器无法加载子级类加载器路径中的类。
于是我们使用了ContextClassLoader(上下文类加载器)来解决这个问题，通过在SPI类里面调用getContextClassLoader来获取第三方实现类的类加载器。由第三方实现类通过调用setContextClassLoader来传入自己实现的类加载器, 这样就变相地解决了双亲委派模式遇到的问题。
本例中获取上下文类加载器的地方就在ServiceLoader.load()。
public static <S> ServiceLoader<S> load(Class<S> service) {
//获得线程上下文类加载器，然后构造了一个ServiceLoader，后续的具体查找过程
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader) {
return new ServiceLoader<>(service, loader);
}
