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的机制。

image

• 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
}

从代码层面上看，我们可以得出几点结论：

1. ServiceLoader是懒加载，有缓存的。
2. ServiceLoader加载时，全部加载，没有提供单个service独立加载的方法，如果调用方只希望调用部分实现类，目前ServiceLoader并不支持。
3. 虽然ServiceLoader内部使用了LinkedHashMap，但是并没有对外暴露接口，只能通过Iterator访问。
4. 并发访问同一个ServiceLoader是线程不安全的。

总结

Java提供的SPI机制，优势在于解耦，调用方不需要明确耦合第三方实现类，而是交由ServiceLoader提供。当程序需要使用另一种第三方实现类时，直接替换依赖就可以，无需重构代码。
缺点其实在上面说到了。这里就不赘述了。Dubbo其实也是针对这些默认SPI的缺点才自己实现了Dubbo SPI。