Java SPI机制分析

SPI 全称为(Service Provider Interface)，是 JDK 内置的一种服务发现机制。它可以动态的为某个接口寻找服务实现，有点类似 IOC(Inversion of Control)的思想，将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

使用 SPI 机制需要在 classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件，这个文件里的内容就是这个接口的具体的实现类。

1. 一个Demo

UserSerivce类：

package com.rickiyang.learn.service;

/**
 * @author rickiyang
 * @date 2019-09-11
 * @Desc TODO
 */
public interface UserService {

    String getUserName (int userId);
}

实现类：

package com.rickiyang.learn.service;

/**
 * @author rickiyang
 * @date 2019-09-11
 * @Desc TODO
 */
public class UserServiceImpl implements UserService {

    @Override
    public String getUserName(int userId) {
        return "xioaming";
    }
}

在resources目录下新建META-INF/services目录，然后新建文本文件，文件名为你的接口类全路径名称，文件内容为实现类全路径名称，多个实现类换行即可。我的文件内容如下：

com.rickiyang.learn.service.UserServiceImpl

测试方法：

package com.rickiyang.learn.javaagent;

/**
 * @author rickiyang
 * @date 2019-09-11
 * @Desc TODO
 */

import com.rickiyang.learn.service.UserService;

import java.util.ServiceLoader;


public class ServiceLoaderTest {

    public static void main(String[] args) {
        ServiceLoader<UserService> serviceLoader = ServiceLoader.load(UserService.class);
        for (UserService service : serviceLoader) {
            String userName = service.getUserName(1);
            System.out.println(userName);
        }
    }

}

整体工程目录如下图所标：

2. SPI实现原理：

1. 应用程序调用 ServiceLoader.load 方法，ServiceLoader.load 方法内先创建一个新的ServiceLoader，并实例化该类中的成员变数，包括：

   • ClassLoader loader(类载入器)
   • AccessControlContext acc(访问控制器)
   • LinkedHashMap<String, S> providers(用于缓存载入成功的类)
   • LazyIterator lookupIterator(实现迭代器功能)

2. 应用程序通过迭代器获取对象实例

   ServiceLoader 先判断成员变量 providers 对象中否有缓存实例对象，如果有缓存，直接返回。

   如果没有缓存，执行类的装载：

   ​ 读取 META-INF/services/ 下的配置文件，

   ​ 获得所有能被实例化的类的名称，

   ​ 通过反射方法 Class.forName() 载入类对象，并用 instance() 方法将类实例化。

   ​ 把实例化后的类缓存到providers 对象中然后返回实例对象。

ServiceLoader内部一些相关字段说明如下，为什么配置文件的路径要放在META-INF/services目录下是因为JDK中写死了配置。

在ServiceLoader初始化过程中，最重要的是其内部的LazyIterator类。通过其构造方法中调用reload()，最终将类名和类加载器传入LazyIterator中去做处理。

LazyIterator 实现了 迭代器接口，所以它最重要的方法无非就是：hasNext() 和 next()两个，基本的逻辑都在这里面实现。

hasNextService的实现大致如下：

1. 如果 nextName已经有值，表明上次查询的时候已经赋值；
2. 如果没有，通过/META-INF/services/加上 接口的全限定类名，就是文件服务类的文件；
3. 将文件路径转为URL对象；
4. 解析URL文件对象，读取内容，最后返回。

next方法的实现也很简单，将nextName中的全路径类名加载进JVM即可。

3. 优缺点

JDK 内置的 SPI 机制本身有它的优点，但由于实现比较简单，也有不少缺点。

优点

使用 Java SPI 机制的优势是实现解耦，使得接口的定义与具体业务实现分离，而不是耦合在一起。应用程序可以根据实际业务情况启用或替换具体组件。

缺点

• 不能按需加载。虽然 ServiceLoader 做了延迟载入，但是基本只能通过遍历全部获取，也就是接口的实现类得全部载入并实例化一遍。如果你并不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
• 获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
• 多个并发多线程使用 ServiceLoader 类的实例是不安全的。
• 加载不到实现类时抛出并不是真正原因的异常，错误很难定位。

上面说的这些缺点对于追求性能的通用框架来说是非常致命的。比如国内的Dubbo项目，就使用自己开发的ServiceLoader机制，ExtensionClassLoader来实现高性能可扩展的SPI。后面会介绍Dubbo相关的源码，我们到时候在详细分析Dubbo中的SPI机制是如何实现。