SPI（Service Provider Interface）是JDK内置的一种服务提供发现机制，它弥补了类加载双亲委派模型的局限、做了很好的补充。广义上来说也可以认为是一种软件设计模式，使得接口与实现解耦，实现面向接口编程。一般用于框架扩展和替换组件实现。
双亲委派类加载模型的局限性
三种类加载器：
- BootstrapClassLoader 加载
rt.jar中的类，所有加载器的根，由底层C++实现 - ExtClassLoader 扩展类加载器，加载
jre/lib/ect目录或java.ext.dirs属性指定的目录下的类 - AppClassLoader 系统类加载器，加载classpath下的类
以HelloWorld这种代码为例：.java文件编译为.class文件，然后jvm加载.class文件到内存，就是执行所谓类加载，到方法区生成类的描述、方法、静态成员等，并在堆区生成对应的Class对象。
比如我们在HelloWorld里用到了HashMap，AppClassLoader加载我们写的HelloWorld应用程序，然后如果使用java核心类库的比如HashMap这些，那么就会双亲委派，最终会由BootstrapClassLoader来加载HashMap类。
父ClassLoader无法使用子ClassLoader加载的类
考虑一种场景：比如类似jdbc，核心包里边有interface api，然后实现impl.jar肯定是开发者通过classpath引入到应用程序里的，这由AppClassLoader加载了。
应用程序使用jdbc的功能，然后双亲委派，最终BootstrapClassLoader会发现加载过api，但是会发现自己这个类加载器（加载的类里）没有impl.jar实现，所以无法工作。
即，如下加载关系：
BootstrapClassLoader -> api interface
AppClassLoader -> impl
这该咋办？
- 线程上下文类加载器，
默认情况下就是AppClassLoader，可以通过Thread.currentThread().getClassLoader()和Thread.currentThread().getContextClassLoader()获取线程上下文类加载器。 - SPI
使用ServiceLoader ，会根据约定从classpath下的META-INF/services/目录找文件名为接口全限定类目的配置文件，比如文件名为com.wangan.interfaceName，然后这个配置里边会配置这个接口的实现类的名字，这样就可以加载到实现类然后使用了。
接下来通过一个简单的例子体会一下JDK的SPI，以及所谓面向接口编程和模块化。
一个实现类implments接口的例子
//接口
package com.wangan.spi;
public interface SPIService {
public void execute();
}
//实现
public class SPIServiceImplA implements SPIService{
@Override
public void execute() {
System.out.println("SPIServiceImplA execute");
}
}
我们假设实现类是通过独立的implA.jar包，引入到当前工程里的，然后通常我们可以按照如下方式用：
SPIService service = new SPIServiceImplA();
service.execute();
这当然可行，但是这个做有个不完美的地方：
如果有一天接口SPIService需要替换为一个SPIServiceImplB的实现，那么需要：
1、替换引入的implA.jar为implB.jar；
2、修改所有使用SPIService的代码。简单来说就是所谓的耦合。
软件设计教科书告诉我们要面向接口进行编程，当前的业务模块也就是我们这个工程，跟依赖的模块也就是implA.jar应该减少耦合，应该依赖双发共同约定的interface、也就是SPIService进行配合编程。业务模块里边理论上不应该出现implements实现的代码，而上面service = new SPIServiceImplA()就破坏了这个规则。
PS：这是单体服务里的解耦合，可以类比一下微服务之间的RPC调用（比如Dubbo、Feigh等），客户端只有接口的定义部分，而实现部分仅出现在服务端。
OK，按照上面的思路，我们看看使用Java的SPI应该怎么做。
使用Java SPI解耦合，实现模块之间面向接口编程
在src/META-INF/services目录下新建com.wangan.spi.SPIService文件，内容：
com.wangan.spi.SPIServiceImplA
com.wangan.spi.SPIServiceImplB
然后加载使用：
import java.util.Iterator;
import java.util.ServiceLoader;
public class SPITest {
public static void main(String[] args) {
ServiceLoader<SPIService> loader = ServiceLoader.load(SPIService.class);
Iterator<SPIService> ite = loader.iterator();
while(ite.hasNext()) {
service = ite.next();
service.execute();
}
}
}
输出：
SPIServiceImplA execute
SPIServiceImplB execute
优势一下就体现出来了，比如上面说的那个情况，换实现的时候只需要把implA.jar从业务工程里去掉，然后引入新的实现包，在implB.jar包里配置好com.wangan.spi.SPIService文件指明实现类是SPIServiceImplB就行了，业务模块调用的地方一行代码也不用改！
源码走读
首先，java.util.ServiceLoader是在rt.jar里的，所以它是BootstrapClassLoader加载的。
ServiceLoader类一开始是个成员变量PREFIX，就是配置文件的位置，其他关键代码如下：
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;
//load方法
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl); //new ServiceLoader<>(service, loader)
}
//返回的是ServiceLoader实例，其实现了Iterator接口
private ServiceLoader(Class<S> svc, ClassLoader cl) {
//加载的接口不能为null
service = Objects.requireNonNull(svc, "Service interface cannot be null");
//传进来的ClassLoader如果为空就使用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);
}
可以看到lookupIterator是一个LazyIterator实例，这是一个内部类、也是实现了Iterator接口。
然后我们回到我们的代码，通过loader = ServiceLoader.load(SPIService.class)拿到ServiceLoader之后，loader.iterator()取迭代器，然后通过ite.hasNext()和ite.next()去拿到我们的实现类的实例的，所以接下重点看看这几个方法的实现就好了。so，接着看：
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();
}
};
}
我们可以看到，最终都是用的lookupIterator也就是LazyIterator的对应方法，所以真正加载逻辑都是在LazyIterator这个内部类里。关键代码如下：
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;
}
//hasNextService是使用class loader加载resource配置文件，然后遍历里边的配置项目。
//next()方法最终调的是nextService()：
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
c = Class.forName(cn, false, loader); //这里的loader可以确保能够使用我们的实现类，据此得到实现类的Class对象
} 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()); //得到实现类的实例，并Class.cast(Object obj)转成接口类型
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反射的方法得到的实现类的实例。
值得一提的是反射得到实例之前，确保了ClassLoader是实现类对应的加载器，回忆一下之前的ServiceLoader.load()方法里用的class loader是Thread.currentThread().getContextClassLoader()或ClassLoader.getSystemClassLoader()。这是个很关键的点。
还记得前文提到过的吗，父ClassLoader无法使用子ClassLoader加载的类，所以要先知道是哪个子ClassLoader加载的这个类，然后用反射的方式实例化这个类的实例。
实际案例有JDBC驱动，Apache common-logging等等，特别适合这种技术标准组织指定某种规范，然后各个提供商去做自己的实现的场景。
