JAVA SPI思想

1. SPI介绍

SPI全称Service Provider Interface，是Java提供的一套用来被第三方实现或者扩展的接口，其意义在于为某个接口寻找服务的实现，主要应用在框架中用来寻找组件，提高扩展性。

汽车制造是一个比较繁琐的过程，通常的手段是先规定汽车各个零部件的生产规格，各个零部件厂商按照这种规则去生产合格的零部件。汽车生产商挑选合适的零部件去组装以出产汽车。汽车某个零部件损坏也不用废弃掉整个汽车，只需要更换组件即可。

SPI就是用来怎么去寻找汽车零部件的一种机制，生产规格就是接口的定义，零部件生产商生产零部件就是遵循接口提供具体的实现，SPI挑选合适的组件进行组装后完成特定的功能，当某个组件存在漏洞或问题时可以在不改动代码的前提下替换组件以提高扩展性。

2. SPI规则

SPI旨在为某个接口寻找服务的实现，因此在设计初期就要规定好组件的接口，JAVA的SPI机制使用步骤如下：

定义组件接口（生产规格）

实现组件接口（提供组件）

配置组件文件（查找组件）

反射实例调用（组装工作）

3. SPI案例

组件定义工程中定义组件开发的规范，即定义组件需要实现哪些接口组件A工程和组件B工程提供对组件的实现，即实现组件定义的接口组件应用工程挑选合适的组件进行组件的运用

3.1 组件的定义

在【commons-api】工程中定义组件的规范，即定义接口，接口名称为ComponentService，内容如下：

public interface ComponentService
{
    /**
     * 获取组件的名称
     * @return 组件名称
     */
    String getComponentName();
}

3.2 组件的实现

在【component-A】工程中按照组件定义的规范提供组件，即实现组件定义接口，类名称为ComponentA，内容如下：

public class ComponentA implements ComponentService
{
    /**
     * 组件名称
     */
    private static final String COMPONENT_NAME = "组件A";

    @Override
    public String getComponentName()
    {
        return COMPONENT_NAME;
    }
}

按照JAVA的SPI规则在【component-A】工程的resource/META-INF/services资源目录下新建文件，文件名称为组件接口的全限定名，内容为组件实现的全限定名

在【component-B】工程中也提供对应的组件实现，类名称为ComponentB，内容如下：

public class ComponentB implements ComponentService
{
    /**
     * 组件名称
     */
    private static final String COMPONENT_NAME = "组件B";

    @Override
    public String getComponentName()
    {
        return COMPONENT_NAME;
    }
}

同样在【component-B】工程的resource/META-INF/services资源目录下配置文件

3.3 组件的选用

基于maven构建的java工程使用pom文件来编排项目所需要的依赖组件，现在需要用到组件，并且我觉得A组件比B组件更适合我，如是在【component-application】工程的pom中我编排了组件A，内容如下：

<dependencies>
    <dependency>
        <groupId>com.xxxx</groupId>
        <artifactId>component-A</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

在【component-application】工程中新建应用程序启动类来运用组件，类名称为Main，内容如下：

public class Main
{
    public static void main(String[] args)
    {
        // 加载组件
        ServiceLoader<ComponentService> components = ServiceLoader.load(ComponentService.class);
        for (ComponentService component : components)
        {
            // 运用组件：打印组件名称
            System.out.println(component.getComponentName());
        }
    }
}

启动【component-application】工程的Main类的main方法，结果如下：

假如某一天我发现组件A存在很大漏洞，需要更换组件将组件A替换成组件B，只需要在【component-application】工程的pom中去掉组件A的依赖，导入组件B的依赖即可，pom内容如下：

<dependencies>
    <dependency>
        <groupId>com.xxxx</groupId>
        <artifactId>component-B</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

无需修改【component-application】工程的具体使用细节，就可以达到替换组件的目的，运行如下：

4. SPI原理

JAVA提供的SPI机制主要依靠的是java.util.ServiceLoader类，从SPI案例中入手，进入ServiceLoader.load方法一探究竟。

load方法最终会创建一个LazyIterator 的实例，看到Iterator大概就知道和迭代器有关，继续了解一下LazyIterator 是什么

猜想得不错，LazyIterator 和迭代器有关，它是ServiceLoader的一个内部类，实现了Iterator接口，那只需要重点关注Iterator接口定义的方法

public boolean hasNext()

public S next()

Iterator接口定义的hasNext方法用于判断迭代的是否是否还有下一个元素，LazyIterator 的hasNext方法最终是调用的hasNextService方法，重点研究这个。

通过类加载器获取到指定目录下的资源文件配置的组件实现的全限定名，存放在configs的一个容器变量中，有了组件实现的全限定名，后面多半就是反射生成对象返回了，继续看一下LazyIterator 的next方法。LazyIterator的next方法主要逻辑是在nextService方法中，仔细分析一下

和刚才的猜想一致，拿到了组件实现的全限定名通过Class.forName来生成组件对象，所以程序就通过for循环得到了对象可以进行调用。

5. SPI要求

java.util.ServiceLoader类是这样来描述自己的

A simple service-provider loading facility.

一个简单的服务提供者加载工具

The only requirement enforced by this facility is thatprovider classes must have a zero-argument constructor so that they can beinstantiated during loading

强制执行的唯一要求是提供者类必须有一个无参的构造函数，以便它们可以在加载过程中实例化，从Class.forName生成实例对象就可以看出使用的是无参构造

6. SPI应用

​ SPI的这种组件替换思想很容易让人想到我们熟知的JDBC规范。JDBC是JAVA规定的应用程序连接数据库的标准，定义了连接数据库的几个接口，比如Connection、Statement、ResultSet。各个数据库厂商提供自己的JDBC实现，这就是我们所说的数据库驱动。开发人员只需要关心如何使用JDBC的各个接口，不需要学习不同厂商的实现，这就是面向接口编程。

JDBC编程分为四个步骤，SPI在驱动管理器DriverManager中得到了应用

Mysql驱动和SqlServer驱动都有SPI的配置

在驱动管理器的loadInitialDrivers方法中就会通过SPI机制获取可用的驱动，loadInitialDrivers方法会在静态代码块中被调用。这里并没有通过全限定名反射实例化，真正的驱动注册是数据库厂商提供的驱动类中通过静态代码块将驱动注册到驱动管理器中的registeredDrivers集合变量中的，以MySQL驱动为例：

在驱动管理器的getConnection方法中会遍历SPI查找到的可用驱动，通过驱动获取链接，直至链接获取成功才返回。

总结