JAVA SPI解析
在阅读Dubbo源码时发现Dubbo针对java的spi机制做了扩展。那么spi究竟是什么呢？
SPI 是什么
SPI全称为Service Provider Interface，是Java提供的用来加载第三方实现的service的API。
比如java.sql.Driver接口，第三方厂商比如MySql，PostgreSql均会实现这个接口来提供接入数据库的实现，Java的SPI机制就可以某个接口寻找服务实现。
当服务提供者实现了一种接口后，需要在classpath的META-INF/services中创建一个以服务接口名命名的文件，文件的内容是这个接口的具体实现类。当调用者需要用到这个服务时，就会查找对应jar包下的META-INF/services中的配置，如果找到了，那么就会实例化这个实现类，调用者就可以调用对应的服务了。Java中，查找实现类的工具类是java.util.ServiceLoader。
一个DEMO
接下来我们自己实现一个简单的SPI服务，从中可以学习到SPI的机制。
- api为接口，其下有一个名为
People的interface,提供一个hello的方法
image - jack与jenny为
People的实现module，各自继承People接口，并实现自己的代码逻辑，本例为了简单只是单纯的输出了各自的名字,如下所示:
image
image - jack与jenny分别在自己module下的resources文件夹下创建
META-INF/services文件夹，并且在该文件夹下创建一个名为io.wkz.People的文件，文件内容分别为Jack与Jenny的全限定名。其结构如下：
image - service依赖上面三个module，并且在main函数中，使用
ServiceLodaer加载People的实现类，并且分别调用hello方法，如下所示：
image
其输出如下：
image
观察main函数会发现，我们并没有在main函数下实例化Jack或Jenny,但是我们在调用服务时，仍然调用到了这两个类的实例。从这里可以发现，SPI的核心思想其实就是解耦。
原理解析
既然在上一个例子里我们是使用的ServiceLoader来获取不同的服务提供者，那么我们就进入ServiceLoader源码探索一番吧。
首先查看一下ServiceLoader的属性字段
public final class ServiceLoader<S>
implements Iterable<S>
{
//看属性名可知此字段就是查找配置文件的前缀文件夹名，从这里也了解了为什么必须要在META-INF/services下新增配置文件。
private static final String PREFIX = "META-INF/services/";
// 代表被加载的类或者接口
private final Class<S> service;
// 类加载器，用于加载并实例化服务
private final ClassLoader loader;
// 创建ServiceLoader时采用的访问控制上下文
private final AccessControlContext acc;
// 实例化后的服务缓存，用的是LinkedHashMap，所以是按顺序排列的，具体排列顺序是按实例化的先后顺序
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// 迭代器，Lazy代表是懒的
private LazyIterator lookupIterator;
...
}
属性字段上比较简单，接下来我们看一下ServiceLoader.load方法，跟踪代码发现其最终是实例化了一个ServiceLoader类并返回。继续进入构造方法
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();
}
构造函数里前面三行属于防御式编程，将null处理掉，要么报错，要么设置默认值。最后一行的reload方法是清空providers，并且实例化一个LazyIterator用于后期迭代。
LazyIterator也比较简单，看名字就是实现了Iterator接口的。比较关键的方法是nextService
private S nextService() {
//防御式编程
if (!hasNextService())
throw new NoSuchElementException();
//nextName是在hasNextService方法中赋值的，这里获取到就置空
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
//使用当前的ClassLoader加载类
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
//加载失败，抛错。
fail(service,
"Provider " + cn + " not found");
}
//判断加载的类是不是当前service的子类或者实现类。
if (!service.isAssignableFrom(c)) {
fail(service,
"Provider " + cn + " not a subtype");
}
try {
//实例化类。注意这里，这步表明我们实现的service必须要有一个无参构造函数
S p = service.cast(c.newInstance());
//进行缓存。这里可以看ServiceLoader的Iterator实现。是先判断的providers是不是hasNext，如果不是，则进入到本LazyIterator中，从一定程度上解决了创建时就加载全部实现类的问题，但是并没有治本。
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
//防御式编程
throw new Error(); // This cannot happen
}
从代码层面上看，我们可以得出几点结论：
- ServiceLoader是懒加载，有缓存的。
- ServiceLoader加载时，全部加载，没有提供单个service独立加载的方法，如果调用方只希望调用部分实现类，目前ServiceLoader并不支持。
- 虽然ServiceLoader内部使用了LinkedHashMap，但是并没有对外暴露接口，只能通过Iterator访问。
- 并发访问同一个ServiceLoader是线程不安全的。
总结
Java提供的SPI机制，优势在于解耦，调用方不需要明确耦合第三方实现类，而是交由ServiceLoader提供。当程序需要使用另一种第三方实现类时，直接替换依赖就可以，无需重构代码。
缺点其实在上面说到了。这里就不赘述了。Dubbo其实也是针对这些默认SPI的缺点才自己实现了Dubbo SPI。
