JAVA SPI 机制解析
目录
导语
什么是 JAVA SPI 机制?
SPI 机制功能演示
1.服务接口约定
2.服务实现
3.服务注册
4.服务发现与使用
5. 对 SPI 简单演示后，我发现了哪些问题?
SPI 机制的原理是什么?
1. 使用 SPI 的约定规范
2.从ServiceLoader类的源码 浅谈 SPI 原理
SPI 机制的优缺点
导语
你是否在学习以下技术框架的过程中，邂逅 Java SPI 机制?
①数据库驱动加载接口实现类：
JDBC加载不同类型数据库的驱动
②Spring或者Spring Boot开发框架:
Spring中大量使用了SPI，比如：对servlet3.0规范对ServletContainerInitializer的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
③日志门面接口实现类加载：
SLF4J加载不同提供商的日志实现类
什么是 JAVA SPI 机制?
SPI，全称Service Provider Interfaces，服务提供接口。是Java提供的一套供第三方实现或扩展使用的技术体系。主要通过解耦服务具体实现以及服务使用，使得程序的可扩展性大大增强，甚至可插拔。
基于服务的注册与发现机制，服务提供者向系统注册服务，服务使用者通过查找发现服务，可以达到服务的提供与使用的分离，甚至完成对服务的管理。
JDK中，基于SPI的思想，提供了默认具体的实现，ServiceLoader。利用JDK自带的ServiceLoader，可以轻松实现面向服务的注册与发现，完成服务提供与使用的解耦。
完成分离后的服务，使得服务提供方的修改或替换，不会给服务使用方带来代码上的修改，基于面向接口的服务约定，提供方和使用方各自直接面向接口编程，而不用关注对方的具体实现。同时，服务使用方使用到服务时，也才会真正意义上去发现服务，以完成服务的初始化，形成了服务的动态加载。
Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。所以SPI的核心思想就是解耦。
当服务的提供者提供了一种接口的实现之后，需要在classpath下的META-INF/services/目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体的实现类。当其他的程序需要这个服务的时候，就可以通过查找这个jar包（一般都是以jar包做依赖）的META-INF/services/中的配置文件，配置文件中有接口的具体实现类名，可以根据这个类名进行加载实例化，就可以使用该服务了。JDK中查zhao服务的实现的工具类是：java.util.ServiceLoader。
SPI 机制功能演示
新建maven工程，项目的文件目录如下:
1.服务接口约定
MyServiceProvider接口定义了服务接口约定:
public interface MyServiceProvider {
String say();
}
2.服务实现
MyServiceProviderImpl_1 MyServiceProviderImpl_2 MyServiceProviderImpl_3
这三个类是服务的实现类:
public class MyServiceProviderImpl_1 implements MyServiceProvider {
@Override
public String say() {
return "服务提供接口的第一个实现类";
}
}public class MyServiceProviderImpl_2 implements MyServiceProvider{
@Override
public String say() {
return "服务提供接口的第二个实现类";
}
}
public class MyServiceProviderImpl_3 implements MyServiceProvider {
@Override
public String say() {
return "服务提供接口的第三个实现类";
}
}3.服务注册
服务注册:实际上向系统登记服务提供者与服务接口之间的映射关系，以便使用方的服务发现
/META-INF/services/目录下创建文件 com.hpu.MyServiceProvider 文件内容为:
com.hpu.MyServiceProviderImpl_1
com.hpu.MyServiceProviderImpl_24.服务发现与使用
ServiceLoaderDemo 类为服务使用方package com.hpu;
import java.util.Iterator;
import java.util.ServiceLoader;
/**
* @author zhou'en'xian
* @date 2020/8/13 17:47
*/
public class ServiceLoaderDemo {
public static void main(String[] args) {
ServiceLoader serviceLoader = ServiceLoader.load(MyServiceProvider.class);
Iterator iterator = serviceLoader.iterator();
while (iterator.hasNext()){
MyServiceProvider next = iterator.next();
System.out.println(next.say()+"\t"+next.hashCode());
}
}
}
程序输出结果:
5. 对 SPI 简单演示后，我发现了哪些问题?
- 没有显式地创建MyServiceProviderImpl_1；MyServiceProviderImpl_2 这两个类对象，为什么里面的代码执行了？
- MyServiceProviderImpl_3与前两个类一样，同为MyServiceProvider接口实现类，为何它没有被加载执行?
为探讨以上两个疑问，不得不探讨 SPI 的原理。
SPI 机制的原理是什么?
JDK中，基于SPI的思想，提供了默认具体的实现，ServiceLoader。下面查看 ServiceLoader的源码:
//ServiceLoader实现了Iterable接口，可以遍历所有的服务实现者
public final class ServiceLoader
implements Iterable
{
//查找配置文件的目录
private static final String PREFIX = "META-INF/services/";
//表示要被加载的服务的类或接口
private final Class service;
//这个ClassLoader用来定位，加载，实例化服务提供者
private final ClassLoader loader;
// 访问控制上下文
private final AccessControlContext acc;
// 缓存已经被实例化的服务提供者，按照实例化的顺序存储
private LinkedHashMap providers = new LinkedHashMap<>();
// 迭代器
private LazyIterator lookupIterator;
//重新加载，就相当于重新创建ServiceLoader了，用于新的服务提供者安装到正在运行的Java虚拟机中的情况。
public void reload() {
//清空缓存中所有已实例化的服务提供者
providers.clear();
//新建一个迭代器，该迭代器会从头查找和实例化服务提供者
lookupIterator = new LazyIterator(service, loader);
}
//私有构造器
//使用指定的类加载器和服务创建服务加载器
//如果没有指定类加载器，使用系统类加载器，就是应用类加载器。
private ServiceLoader(Class 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();
}
//解析失败处理的方法
private static void fail(Class service, String msg, Throwable cause)
throws ServiceConfigurationError
{
throw new ServiceConfigurationError(service.getName() + ": " + msg,
cause);
}
private static void fail(Class service, String msg)
throws ServiceConfigurationError
{
throw new ServiceConfigurationError(service.getName() + ": " + msg);
}
private static void fail(Class service, URL u, int line, String msg)
throws ServiceConfigurationError
{
fail(service, u + ":" + line + ": " + msg);
}
//解析服务提供者配置文件中的一行
//首先去掉注释校验，然后保存
//返回下一行行号
//重复的配置项和已经被实例化的配置项不会被保存
private int parseLine(Class service, URL u, BufferedReader r, int lc,
List names)
throws IOException, ServiceConfigurationError
{
//读取一行
String ln = r.readLine();
if (ln == null) {
return -1;
}
//#号代表注释行
int ci = ln.indexOf('#');
if (ci >= 0) ln = ln.substring(0, ci);
ln = ln.trim();
int n = ln.length();
if (n != 0) {
if ((ln.indexOf(' ') >= 0) || (ln.indexOf('\t') >= 0))
fail(service, u, lc, "Illegal configuration-file syntax");
int cp = ln.codePointAt(0);
if (!Character.isJavaIdentifierStart(cp))
fail(service, u, lc, "Illegal provider-class name: " + ln);
for (int i = Character.charCount(cp); i < n; i += Character.charCount(cp)) {
cp = ln.codePointAt(i);
if (!Character.isJavaIdentifierPart(cp) && (cp != '.'))
fail(service, u, lc, "Illegal provider-class name: " + ln);
}
if (!providers.containsKey(ln) && !names.contains(ln))
names.add(ln);
}
return lc + 1;
}
//解析配置文件，解析指定的url配置文件
//使用parseLine方法进行解析，未被实例化的服务提供者会被保存到缓存中去
private Iterator parse(Class service, URL u)
throws ServiceConfigurationError
{
InputStream in = null;
BufferedReader r = null;
ArrayList names = new ArrayList<>();
try {
in = u.openStream();
r = new BufferedReader(new InputStreamReader(in, "utf-8"));
int lc = 1;
while ((lc = parseLine(service, u, r, lc, names)) >= 0);
}
return names.iterator();
}
//服务提供者查找的迭代器
private class LazyIterator
implements Iterator
{
Class service;//服务提供者接口
ClassLoader loader;//类加载器
Enumeration configs = null;//保存实现类的url
Iterator pending = null;//保存实现类的全名
String nextName = null;//迭代器中下一个实现类的全名
private LazyIterator(Class service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
private boolean hasNextService() {
if (nextName != null) {
return true;
}
if (configs == null) {
try {
String fullName = PREFIX + service.getName();
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
configs = loader.getResources(fullName);
}
}
while ((pending == null) || !pending.hasNext()) {
if (!configs.hasMoreElements()) {
return false;
}
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 {
c = Class.forName(cn, false, loader);
}
if (!service.isAssignableFrom(c)) {
fail(service, "Provider " + cn + " not a subtype");
}
try {
S p = service.cast(c.newInstance());
providers.put(cn, p);
return p;
}
}
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
PrivilegedAction action = new PrivilegedAction() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public S next() {
if (acc == null) {
return nextService();
} else {
PrivilegedAction action = new PrivilegedAction() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public void remove() {
throw new UnsupportedOperationException();
}
}
//获取迭代器
//返回遍历服务提供者的迭代器
//以懒加载的方式加载可用的服务提供者
//懒加载的实现是：解析配置文件和实例化服务提供者的工作由迭代器本身完成
public Iterator iterator() {
return new Iterator() {
//按照实例化顺序返回已经缓存的服务提供者实例
Iterator> 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();
}
};
}
//为指定的服务使用指定的类加载器来创建一个ServiceLoader
public static ServiceLoader load(Class service,
ClassLoader loader)
{
return new ServiceLoader<>(service, loader);
}
//使用线程上下文的类加载器来创建ServiceLoader
public static ServiceLoader load(Class service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
//使用扩展类加载器为指定的服务创建ServiceLoader
//只能找到并加载已经安装到当前Java虚拟机中的服务提供者，应用程序类路径中的服务提供者将被忽略
public static ServiceLoader loadInstalled(Class service) {
ClassLoader cl = ClassLoader.getSystemClassLoader();
ClassLoader prev = null;
while (cl != null) {
prev = cl;
cl = cl.getParent();
}
return ServiceLoader.load(service, prev);
}
public String toString() {
return "java.util.ServiceLoader[" + service.getName() + "]";
}
} 源码的注释已经做中文化处理，其实源码英文版的注释透露了许多 SPI 的重要信息：
1. 使用 SPI 的约定规范
要使用Java SPI，需要遵循如下约定：
- 1、当服务提供者提供了接口的一种具体实现后，在jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
- 2、接口实现类所在的jar包放在主程序的classpath中；
- 3、主程序通过java.util.ServiceLoder动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；
- 4、SPI的实现类必须携带一个不带参数的构造方法；
2.从ServiceLoader类的源码 浅谈 SPI 原理
（1）从类的局部方法来看
①调用ServiceLoader.load方法创建ServiceLoader
ServiceLoader.load方法内先创建一个新的ServiceLoader，并实例化该类中的成员变量，包括：
⑴loader(ClassLoader类型，类加载器)
⑵acc(AccessControlContext类型，访问控制器)
⑶providers(LinkedHashMap
⑷lookupIterator(实现迭代器功能)
②应用程序通过迭代器接口获取对象实例
ServiceLoader先判断成员变量providers对象中(LinkedHashMap
如果没有缓存，执行类的装载，实现如下：
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);
}(1) 读取META-INF/services/下的配置文件，获得所有能被实例化的类的名称，值得注意的是，ServiceLoader可以跨越jar包获取META-INF下的配置文件，具体加载配置的实现代码如下：
(2) 通过反射方法Class.forName()加载类对象，并用instance()方法将类实例化。
(3) 把实例化后的类缓存到providers对象中，(LinkedHashMap
然后返回实例对象
（2）从类的整个逻辑来看
外部使用时，往往通过load(Class service, ClassLoader loader)或load(Class service)调用，最后都是在reload方法中创建了LazyIterator对象，LazyIterator是ServiceLoader的内部类，实现了Iterator接口，其作用是一个懒加载的迭代器，在hasNextService方法中，完成了对位于META-INF/services/目录下的配置文件的解析，并在nextService方法中，完成了对具体实现类的实例化。
META-INF/services/，是ServiceLoader中约定的接口与实现类的关系配置目录，文件名是接口全限定类名，内容是接口对应的具体实现类，如果有多个实现类，分别将不同的实现类都分别作为每一行去配置。解析过程中，通过LinkedHashMap
SPI 机制的优缺点
(1)缺点
1.不能按需加载，需要遍历所有的实现，并实例化，然后在循环中才能找到我们需要的实现。如果不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
2.获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
3.多个并发多线程使用 ServiceLoader 类的实例是不安全的。
（2）优点
基于服务提供与发现的思想，系统自带的ServiceLoader以及基于此思想基础上的演化形式，被广泛的使用到实际的项目中。本质上，通过服务接口约定、服务注册与服务发现，完成将服务提供方与服务使用方的解耦，大大扩展了系统的可扩展性。服务注册的本质，是将服务接口与具体服务实现的映射关系注册到系统或特定实现中。服务发现的过程，本质上是向系统或特定实现去匹配对应的具体实现类，但在写法上是基于接口的编程方式，因为服务使用方和服务提供方彼此都是透明与未感知的。基于SPI思想的ServiceLoader实现及演化，在项目的组件化，或实现扩展性功能，甚至完成具有可插拔能力的插件化模块时，往往都被广泛使用到。