什么是SPI
SPI ，全称为 Service Provider Interface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。 Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。
使用场景
概括地说，适用于：调用者根据实际使用需要，启用、扩展、或者替换框架的实现策略
比较常见的例子：
数据库驱动加载接口实现类的加载 JDBC加载不同类型数据库的驱动 日志门面接口实现类加载 SLF4J加载不同提供商的日志实现类
Spring
Spring中大量使用了SPI,比如：对servlet3.0规范对ServletContainerInitializer的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
Dubbo
Dubbo中也大量使用SPI的方式实现框架的扩展, 不过它对Java提供的原生SPI做了封装，允许用户扩展实现Filter接口
源码分析
以ServiceLoader.load()为例,仔细观察他是如何自动加载文件里我们定义的类！
ServiceLoader
首先看ServiceLoader类的签名类的成员变量： public final class ServiceLoader implements Iterable
//指定的配置文件的路径
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;
......
}
Load
ServiceLoader.load方法内先创建一个新的ServiceLoader，并实例化该类中的成员变量，主要四大步骤包括：
1、loader(ClassLoader类型，类加载器) 2、acc(AccessControlContext类型，访问控制器) 3、providers(LinkedHashMap<String,S>类型，用于缓存加载成功的类) 4、lookupIterator(实现迭代器功能)
重要源码提炼如下：
public final class ServiceLoader<S> implements Iterable<S>
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;
//先清空
providers.clear();
//实例化内部类
LazyIterator lookupIterator = new LazyIterator(service, loader);
}
}
查找实现类
查找实现类和创建实现类的过程，都在LazyIterator完成。当我们调用iterator.hasNext和iterator.next方法的时候，实际上调用的都是LazyIterator的相应方法。
public Iterator<S> iterator() {
return new Iterator<S>() {
public boolean hasNext() {
return lookupIterator.hasNext();
}
public S next() {
return lookupIterator.next();
}
.......
};
}
重点关注lookupIterator.hasNext()方法，它最终会调用到hasNextService。读取META-INF/services/下的配置文件，获得所有能被实例化的类的名称，值得注意的是，ServiceLoader可以跨越jar包获取META-INF下的配置文件，具体加载配置的实现代码如下：
private class LazyIterator implements Iterator<S>{
Class<S> service;
ClassLoader loader;
Enumeration<URL> configs = null;
Iterator<String> pending = null;
String nextName = null;
private boolean hasNextService() {
//第二次调用的时候，已经解析完成了，直接返回
if (nextName != null) {
return true;
}
if (configs == null) {
//META-INF/services/ 加上接口的全限定类名，就是文件服务类的文件
//META-INF/services/spi.WordParse
String fullName = PREFIX + service.getName();
//将文件路径转成URL对象
configs = loader.getResources(fullName);
}
while ((pending == null) || !pending.hasNext()) {
//解析URL文件对象，读取内容，最后返回
pending = parse(service, configs.nextElement());
}
//拿到第一个实现类的类名
nextName = pending.next();
return true;
}
}
创建实例
当然，调用next方法的时候，实际调用到的是lookupIterator.nextService。它通过反射的方式，创建实现类的实例并返回。
private class LazyIterator implements Iterator<S>{
private S nextService() {
//全限定类名
String cn = nextName;
nextName = null;
//创建类的Class对象
Class<?> c = Class.forName(cn, false, loader);
//通过newInstance实例化
S p = service.cast(c.newInstance());
//放入集合，返回实例
providers.put(cn, p);
return p;
}
}
使用实例
新建一个maven工程
定义接口 MyApi
package api;
public interface MyApi {
void sayHello(String inputStr);
}
实现类 MyApiJerryImpl
package impl;
import api.MyApi;
public class MyApiJerryImpl implements MyApi {
@Override
public void sayHello(String inputStr) {
System.out.println("this is jerry" + " " + inputStr);
}
}
实现类 MyApiTomImpl
package impl;
import api.MyApi;
public class MyApiTomImpl implements MyApi {
@Override
public void sayHello(String inputStr) {
System.out.println("this is tom" + " " + inputStr);
}
}
主类 Test
import api.MyApi;
import java.util.ServiceLoader;
public class Test {
public static void main(String[] args) {
ServiceLoader<MyApi> printers = ServiceLoader.load(MyApi.class);
for (MyApi printer : printers) {
printer.sayHello("SPI");
}
}
}
在 resources 新建META-INF/services 目录
新建文件api.MyApi
impl.MyApiJerryImpl
impl.MyApiTomImpl
整体文件目录
运行结果
this is jerry SPI
this is tom SPI
分析主类代码
1.ServiceLoader<MyApi> printers = ServiceLoader.load(MyApi.class);
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)
{
return new ServiceLoader<>(service, loader);
}
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对象
2.for (MyApi printer : printers) {
public final class ServiceLoader<S>
implements Iterable<S>
{
private static final String PREFIX = "META-INF/services/";
// The class or interface representing the service being loaded
private final Class<S> service;
// The class loader used to locate, load, and instantiate providers
private final ClassLoader loader;
// The access control context taken when the ServiceLoader is created
private final AccessControlContext acc;
// Cached providers, in instantiation order
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// The current lazy-lookup iterator
private LazyIterator lookupIterator;
由于实现了Iterable接口
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();
}
};
}
所以会调用上面的hasNext()方法，调用 return lookupIterator.hasNext();
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);
}
}
调用这行代码 return hasNextService();
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);
} 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;
}
调用到这行代码 String fullName = PREFIX + service.getName();
在ServiceLoader类的第一个成员变量 private static final String PREFIX = “META-INF/services/”; 到了这里就解释了为什么配置文件必须放到META-INF/services 目录下面了
找到配置文件以后，要解析文件里面的内容
调用到这行代码 pending = parse(service, configs.nextElement());
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();
r = new BufferedReader(new InputStreamReader(in, "utf-8"));
int lc = 1;
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();
}
names的值是
然后调用nextService（）方法
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
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
}
代码 c = Class.forName(cn, false, loader);
使用java反射 获取类
代码 S p = service.cast(c.newInstance()); 生成对象
以上是Android中SPI的机制及实现的原理，大致了解学习、更多的Android进阶技术，可前往《Android核心技术手册》。里面内容板块划分30多个文档，更有视频讲解以及面试相关。
总结
使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，实现解耦。我们的应用程序可以根据实际业务情况启用框架扩展或替换框架组件。
相比使用提供接口jar包，供第三方服务模块实现接口的方式，SPI的方式，让我们不必关心接口的实现类的路径，可以不用通过下面的方式获取接口实现类：
- 代码硬编码import 导入实现类
- 指定类全路径反射获取：例如在JDBC4.0之前，JDBC中获取数据库驱动类需要通过Class.forName(“com.mysql.jdbc.Driver”)，类似语句先动态加载数据库相关的驱动，然后再进行获取连接等的操作
- 第三方服务模块把接口实现类实例注册到指定地方，源框架从这个指定的地方访问实例
通过SPI的方式，第三方服务模块实现接口后，在第三方的项目代码的META-INF/services目录下的配置文件指定实现类的全路径名，源码框架即可找到实现类。
