在日常的项目开发中,我们为了提升程序的扩展性,经常使用面向接口的编程思想进行编程。不仅体现了程序设计对于对修改关闭,对于扩展开放的设计原则,同时也实现了程序可插拔。那么今天本文所阐述的SPI
正是这种编程思想的体现。今天就和大家聊聊SPI
到底是个什么鬼。顺便和大家一起看下一些常见的框架中是怎么使用SPI
机制来进行框架扩展的。
我们经常使用的各种sdk
其实就是一种接口以及接口的实现在同一jar
包中的实现方式,通过调用接口完成一次业务调用。但是为了增强程序的扩展属性,可以考虑使用SPI
。
SPI(Service Provider Interface)
,即为服务提供者接口。听上去有点不明觉厉,不知道表达什么意思。按照我的理解,它就是一种服务发现机制。其本质就是将接口与实现进行解偶分离,服务方只定义接口,具体实现由第三方进行实现,从而提升了程序的可扩展性,让服务提供方可以面向接口编程。
我们只需要在jar
包的META-INF/services/
目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候,就能通过该jar
包META-INF/services/
里的配置文件找到具体的实现类名,并装载实例化,完成实现类的的加载注入。
使用方提供规则说明,实际服务提供方完成具体实现。其实这种思想和spring中的组件扫描是类似的,都是先指定好规则,服务提供方更具规范让框架自动进行服务发现。
重点来了,知识点来了,敲黑板了。自此我们可以发现,无论是本文谈到的SPI
,还是SpringBoot
中的自动配置原理,实际都是一种约定大于配置的开发思想,通过事先约定好的内容,进行具体实现,动态的,从而提升程序的扩展性。所以希望大家在看一项技术时,除了关注技术细节,进行纵向了解,也要关注横向技术对比,从而找到这些技术的共通之处,了解其背后的设计思想,我一直觉得这个是非常重要的,毕竟招式一直都是在变化,但是内功修炼更加重要。
1、SPI
使用
Java SPI
约定在 Classpath
下的 META-INF/services/
目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar
包提供的具体实现类的全限定名。大致的过程如下所示:
以Mysql
的驱动加载为例,首先定义好需要进行扩展的模板接口,即为java.sql.Driver
接口。各个数据库厂商可以更具自身数据库的特点进行对应的驱动开发,但是都要遵从这个模板接口。
在Mysql
的驱动二方包中,在其 Classpath
路径下的 META-INF/services/
目录中,创建一个以服务接口完全名称一致的的文件,在这个文件中保存的内容是模板接口具体实现类的完全限定名。
在对应的目录中进行具体的类实现,这些实现类都实现了java.sql.Driver
接口。
具体的代码实现,通过ServiceLoader
加载对应的实现类,完成类的实例化操作。当然这个ServiceLoader
也可以自己定义,像Dubbo
、Seata
这样的框架都自己定义类加载器。
public final class ServiceLoader<S>
implements Iterable<S>
{
private static final String PREFIX = "META-INF/services/";
...
public static <S> ServiceLoader<S> load(Class<S> service,
ClassLoader loader)
{
return new ServiceLoader<>(service, loader);
}
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
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();
}
...
}
我们一起来分析下这个服务加载器的工作流程,首先通过ServiceLoader.load()
进行加载。先获取当前线程绑定的 ClassLoader
,如果当前线程绑定的 ClassLoader
为null
,则使用 SystemClassLoader
进行代替,而后清除一下provider
缓存,最后创建一个 LazyIterator
。 LazyIterator
的部分源码如下:
private class LazyIterator implements Iterator<S>
{
Class<S> service;
ClassLoader loader;
Enumeration<URL> configs = null;
Iterator<String> pending = null;
String nextName = null;
...
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 {
//key:获取完全限定名
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;
}
...
}
key:
通过预定好的目录地址以及类名来指定类的具体地址,类加载器根据这个地址来加载具体的实现类。
大致的SPI
加载过程如下所示:
欢迎关注作者公众号,提供面试指导、技术分享以及各类技术学习资料,别等了,赶紧上车吧。