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的方法
  • JackJennyPeople的实现module,各自继承People接口,并实现自己的代码逻辑,本例为了简单只是单纯的输出了各自的名字,如下所示:
  • jack与jenny分别在自己module下的resources文件夹下创建META-INF/services文件夹,并且在该文件夹下创建一个名为io.wkz.People的文件,文件内容分别为JackJenny的全限定名。其结构如下:
  • service依赖上面三个module,并且在main函数中,使用ServiceLodaer加载People的实现类,并且分别调用hello方法,如下所示: 其输出如下:

观察main函数会发现,我们并没有在main函数下实例化JackJenny,但是我们在调用服务时,仍然调用到了这两个类的实例。从这里可以发现,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。