1、什么是SPI机制

SPI（Service Provider Interface），是JDK内置的一种 服务提供发现机制，可以用来启用框架扩展和替换组件，主要是被框架的开发人员使用，比如java.sql.Driver接口，其他不同厂商可以针对同一接口做出不同的实现，MySQL和PostgreSQL都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。Java中SPI机制主要思想是将装配的控制权移到程序之外，类似Spring的IOC机制。在模块化设计中这个机制尤其重要，其核心思想就是 解耦。

SPI整体机制图如下：

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

2、SPI和API的区别

在现今的微服务的框架下，我们最常见的是提供API服务，也就是接口和实现都部署在同一个集群中，向外通过Http/Rpc协议，外部调用方，通过引入jar包的方式，使用我们的服务，常用的框架Dubbo，便是是如此。

这里实际包含两个问题，第一个SPI和API的区别？第二个什么时候用API，什么时候用SPI？

SPI - “接口”位于“调用方”所在的“包”中

• 概念上更依赖调用方。
• 组织上位于调用方所在的包中。
• 实现位于独立的包中。
• 常见的例子是：插件模式的插件。

例如：

• 数据库驱动加载接口实现类的加载
  JDBC加载不同类型数据库的驱动
• 日志门面接口实现类加载
  SLF4J加载不同提供商的日志实现类
• Spring
  Spring中大量使用了SPI,比如：对servlet3.0规范对ServletContainerInitializer的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
• Dubbo
  Dubbo中也大量使用SPI的方式实现框架的扩展, 不过它对Java提供的原生SPI做了封装，允许用户扩展实现Filter接口

API - “接口”位于“实现方”所在的“包”中

• 概念上更接近实现方。
• 组织上位于实现方所在的包中。
• 实现和接口在一个包中。

例如：微服务中提供的接口API，微信的提现接口。

3、简单的SPI的实例

结合网上的案例，实现了一个简单的案例，步骤如下：

• 先定义好接口

public interface Search {
    public List<String> searchDoc(String keyword);   
}

• 文件搜索实现

public class FileSearch implements Search{
    @Override
    public List<String> searchDoc(String keyword) {
        System.out.println("文件搜索 "+keyword);
        return null;
    }
}

• 数据库搜索实现

public class DatabaseSearch implements Search{
    @Override
    public List<String> searchDoc(String keyword) {
        System.out.println("数据搜索 "+keyword);
        return null;
    }
}

• resources 接下来可以在resources下新建META-INF/services/目录，然后新建接口全限定名的文件：com.jd.javalearn.spi.Search，里面加上我们需要用到的实现类

// 文件名为接口的全限定类名
com.jd.javalearn.spi.Search

//内容
com.jd.javalearn.spi.impl.DataBaserSearch
com.jd.javalearn.spi.impl.FileSearch

• 测试方法

public class SPiTest {
    public static void main(String[] args) {
        ServiceLoader<Search> load = ServiceLoader.load(Search.class);
        Iterator<Search> iterator = load.iterator();
        while (iterator.hasNext()){
            Search next = iterator.next();
            next.searchDoc("helloWorld");
        }

    }
}

在com.jd.javalearn.spi.Search文件里写上两个实现类，结果如下：

原理：

ServiceLoader.load(Search.class)在加载某接口时，会去META-INF/services下找接口的全限定名文件，再根据里面的内容加载相应的实现类。

这就是spi的思想，接口的实现由provider实现，provider只用在提交的jar包里的META-INF/services下根据平台定义的接口新建文件，并添加进相应的实现类内容就好。

上面的案例是在同一个项目中，似乎没有体现SPI的价值和意义。

因为SPI的接口和实现都是在同一个包中，跟我们所说的概念不太相符合。

SPI - “接口”位于“调用方”所在的“包”中

• 概念上更依赖调用方。
• 组织上位于调用方所在的包中。
• 实现位于独立的包中。

通过Maven的多模块机制，重新编织SPI。其中设计到一个问题，就是循环引用的问题。

原来的设计：

        1、定义了两个模块 spi_client 和 spi_provider

        2、spi_client中定义了接口（调用方），spi_provider中定义了实现（服务提供方）

问题在于：这两个模块互相引用。spi_client的pom文件引用了spi_provider，spi_provider则需要spi-client提供的接口

所以：增加一个模块，接口模块:spi_interface，

spi_interface，主要是因为接口是双方都要用的，避免循环引用，调用方需要根据接口查找并调用服务，而提供者需要实现接口，如果把接口定义到调用者模块，那么提供者要实现接口就必须引入整个调用者模块！容易引起循环引用。

父pom

 <modules>
        <module>spi_client</module>
        <module>spi_provider</module>
        <module>spi_interface</module>
    </modules>

spi_client中pom

 <parent>
        <artifactId>java_learn</artifactId>
        <groupId>org.example</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>spi_client</artifactId>
    <dependencies>
        <!--   引入接口模块    -->
        <dependency>
            <groupId>org.example</groupId>
            <artifactId>spi_interface</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <!--   实现接口模块 可以按需求进行替换    -->
        <dependency>
            <groupId>org.example</groupId>
            <artifactId>spi_provider</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

spi_provider的pom

    <parent>
        <artifactId>java_learn</artifactId>
        <groupId>org.example</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>spi_provider</artifactId>
    <dependencies>
        <!--  待实现的接口      -->
        <dependency>
            <groupId>org.example</groupId>
            <artifactId>spi_interface</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

还是一样的代码，但是结构上更接近SPI的思想，也是一样的效果

4、Java SPI的缺点

注意这里说的是Java SPI的缺点，SPI是一种机制，而Java SPI只是它的其中一种实现。

注意到实现类的加载过程，是通过java.util.ServiceLoader进行实现。通过iterator，遍历每一个实现类，而没有按需加载。

1. 不能按需加载。虽然 ServiceLoader 做了延迟载入，但是基本只能通过遍历全部获取，也就是接口的实现类得全部载入并实例化一遍。容易造成资源浪费。
2. 获取某个实现类的方式不够灵活，只能通过 Iterator 形式迭代获取，不能根据某个参数来获取对应的实现类。
3. 多线程并发使用 ServiceLoader 类的实例存在安全隐患。
4. 实现类不能通过有参构造器实例化。

注意事项
接口实现类必须提供一个无参的构造器！

5、总结

      Java SPI 的实现流程

• 1、当服务提供者提供了接口的一种具体实现后，在jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
• 2、接口实现类所在的jar包放在主程序的classpath中；
• 3、主程序通过java.util.ServiceLoder动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；
• 4、SPI的实现类必须携带一个不带参数的构造方法；

优点：
使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，而不是耦合在一起。应用程序可以根据实际业务情况启用框架扩展或替换框架组件。

相比使用提供接口jar包，供第三方服务模块实现接口的方式，SPI的方式使得源框架，不必关心接口的实现类的路径，可以不用通过下面的方式获取接口实现类：

• 代码硬编码import 导入实现类
• 指定类全路径反射获取：例如在JDBC4.0之前，JDBC中获取数据库驱动类需要通过Class.forName("com.mysql.jdbc.Driver")，类似语句先动态加载数据库相关的驱动，然后再进行获取连接等的操作
• 第三方服务模块把接口实现类实例注册到指定地方，源框架从该处访问实例

通过SPI的方式，第三方服务模块实现接口后，在第三方的项目代码的META-INF/services目录下的配置文件指定实现类的全路径名，源码框架即可找到实现类

缺点：

• 虽然ServiceLoader也算是使用的延迟加载，但是基本只能通过遍历全部获取，也就是接口的实现类全部加载并实例化一遍。如果你并不想用某些实现类，它也被加载并实例化了，这就造成了浪费。获取某个实现类的方式不够灵活，只能通过Iterator形式获取，不能根据某个参数来获取对应的实现类。
• 多个并发多线程使用ServiceLoader类的实例是不安全的。

参考

Java核心技术36讲
The Java? Tutorials
Java Doc
Service Provider Interface: Creating Extensible Java Applications
Service provider interface
Java ServiceLoader使用和解析
Java基础之SPI机制
Java中SPI机制深入及源码解析
SPI机制简介