Java中的SPI基础

什么是SPI

  SPI全称为Service Provider Interface，它是JDK内置的一种服务提供发现机制。SPI是一种动态替换发现的机制。比如，当一个接口想要运行时动态的给它添加实现，只需要添加一个实现。经常遇到的就是java.sql.Driver接口，不同的厂商针对同一接口进行不同的实现，而Java的SPI机制可以为某个接口寻找服务实现。Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。

  类图中，接口对应定义的抽象SPI接口；实现方实现SPI接口；调用方依赖SPI接口。
  SPI接口的定义在调用方。实现位于独立的包中。

Java SPI应用实例

  当服务的提供者提供了一种接口的实现后，需要在classpath的META-INF/services目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体的实现类。当其他的程序需要这个服务的时候，就可以 通过查找这个jar包（一般都是以jar包作为依赖）的META-INF/services中的配置文件，配置文件中有接口具体的实现类名，可以根据这个类型进行实例化加载，就可以使用该服务了。JDK中查找服务实现的工具类是：java.util.ServiceLoader

SPI的用途

  数据库DriverManager、Spring、ConfigurableBeanFactory等都是用到了SPI机制，以数据库DriverManager为例。
  DriverManager是jdbc里管理和注册不同数据库Driver的工具类，针对一个数据库，可能会存在这不同的数据库驱动的实现。在使用特定的驱动时，不希望修改现有的代码，希望通过一个简单的配置就可以达到效果。在使用MySQL驱动时，使用Class.forName(“com.mysql.jdbc.Driver”)加载MySQL驱动，就会执行其中的静态代码把driver注册到DriverManager中，以便后续的使用。
在JDBC4.0以后，不在需要使用Class.forName来加载驱动，直接获取连接即可，使用了Java的SPI扩展机制来实现。在Java中定义了java.sql.Driver接口，并没有具体的实现，具体的实现是有不同的厂商进行实现的。
  在mysql-connector-java-5.1.45.jar中，META-INF/services目录下有一个名为java.sql.Driver的文件：

com.mysql.jdbc.Driver
com.mysql.fabric.jdbc.FabricMySQLDriver

  在postgresql-42.2.2.jar中，META-INF/services目录下有一个名为java.sql.Driver的文件：

org.postgresql.Driver

  在MySQL中获取数据库连接Connection的过程

Connection conn = DriverManager.getConnection(url, username, password);

  不需要使用Class.forName(“com.mysql.jdbc.Driver”)加载MySQL驱动

MySQL DriverManager的实现

  MySQL中的DriverManager使用了Java中的SPI扩展机制来查找相关的驱动。在DriverManager中有一个静态代码块，如下：

static {
	loadInitialDrivers();
	println("JDBC DriverManager initialized");
}

  在静态代码块中有一个loadInitialDrivers方法，loadInitialDrivers方法中用到了上文中提到的SPI工具类ServiceLoader

    public Void run() {
        ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
        Iterator<Driver> driversIterator = loadedDrivers.iterator();

        /* Load these drivers, so that they can be instantiated.
         * It may be the case that the driver class may not be there
         * i.e. there may be a packaged driver with the service class
         * as implementation of java.sql.Driver but the actual class
         * may be missing. In that case a java.util.ServiceConfigurationError
         * will be thrown at runtime by the VM trying to locate
         * and load the service.
         *
         * Adding a try catch block to catch those runtime errors
         * if driver not available in classpath but it's
         * packaged as service and that service is there in classpath.
         */
        try{
            while(driversIterator.hasNext()) {
                driversIterator.next();
            }
        } catch(Throwable t) {
        // Do nothing
        }
        return null;
    }

  遍历使用SPI获取到的具体实现，实例化各个实现类。在遍历的时候，首先调用driversInterator.next()方法，这里会搜索classpath下以及jar包中所有的META-INF/services目录下的java.sql.Driver文件，并找到文件中的实现类的名字。

ServiceLoader原理解析

    // 特定的读取位置
    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;

  简单梳理一下ServiceLoader的源码，实现流程如下：

1. 应用程序调用ServiceLoader.load方法，ServiceLoader.load方法会创建一个新的ServiceLoader实例，并实例化该类的成员变量。包括service、loader、acc、lookupIterator，并清除provider中已经缓存的内容。
2. 应用程序通过迭代器接口获取Iterator实例，先判断成员变量providers对象中LinkedHashMap<String, S>是否已经缓存了实例对象，如果已经存在缓存，则直接返回。没有缓存，则执行类加载过程，具体实现如下：
   • 读取META-INF/services下的配置文件，获取所有能够被实例化的类的名称，ServiceLoader可以跨越jar包读取META-INF下的配置文件。

       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);
       }
   

   • 通过反射方法Class.forName()加载类对象，并用instance()方法将类实例化
   • 把实例化后的对象缓存至providers中，然后返回实例对象

               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
   

总结

  SPI机制在实际开发中的使用场景很多。特别是统一标准的不同厂商的实现，当有关组织或者公司定义标准后，具体厂商或框架开发者开发实现，之后提供给开发者使用。

• 优点：
  • 使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，而不是耦合在一起。应用程序可以根据实际业务情况启用框架扩展或者替换框架组件。
• 缺点
  • 虽然ServiceLoader也算是使用的延迟加载，但是基本上只能通过遍历全部获取，也就是接口的实现类全部加载并实例化了一遍。无论想不想用某些实现类，它也被加载并实例化了，这就造成了浪费。
  • 获取某一个实现类的方法不够灵活，只能通过Iterator形式获取，不能根据某个参数来获取对应的实现类。
  • 多个并发多线程使用ServiceLoader类实例是不安全的。