[toc]

1. 介绍

SPI 全称：Service Provider Interface，是Java提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件。比如java.sql.Driver接口，其他不同厂商可以针对同一接口做出不同的实现，MySQL和PostgreSQL都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。Java中SPI机制主要思想是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是解耦。

简单来说, 框架只提供接口(规范), 具体实现由业务自行实现, 调用的时候自然就调用了具体的业务类,
和spring 的ioc很类似, 定义接口, 由实现类完成业务, 只是 ioc使用 @service 等注解完成类注入, SPI 通过java.util.ServiceLoader 注入,
如此, 即使没有spring框架也能做到定义接口, 由业务方来实现, 比如在common包中,没有spring环境, 但需要提供这种能力,就可以用SPI

2. 案例介绍

定义一个接口：

Phone.java

package com.light.sword;

/**
 * @author: Jack
 * 2021/1/31 上午1:44
 */
public interface Phone {
    String getSystemInfo();
}

两个实现

package com.light.sword;

/**
 * 华为手机
 * @author: Jack
 * 2021/1/31 上午1:48
 */
public class Huawei implements Phone {
    @Override
    public String getSystemInfo() {
        return "Hong Meng";
    }
}

package com.light.sword;

/**
 * 苹果手机
 * @author: Jack
 * 2021/1/31 上午1:48
 */
public class IPhone implements Phone {
    @Override
    public String getSystemInfo() {
        return  "iOS";
    }
}

然后需要在resources目录下新建 META-INF/services 目录，并且在这个目录下新建一个与上述接口的全限定名一致的文件:

com.light.sword.Phone (这是一个文件，是的，一切皆是文件。)

在这个文件中写入接口的实现类的全限定名（文件 com.light.sword.Phone 中写死的内容）：

com.light.sword.Huawei
com.light.sword.IPhone

如图

注意：这个META-INF/services 目录是写死的约定，在 java.util.ServiceLoader 源码实现中, java.util.ServiceLoader#PREFIX 可以看到这个目录的硬编码。

加载实现类并调用服务

package com.light.sword;

import java.util.ServiceLoader;

public class Main {

    public static void main(String[] args) {
        // 通过 ServiceLoader.load() 来加载实现类
        ServiceLoader<Phone> phoneServiceLoader = ServiceLoader.load(Phone.class);
        phoneServiceLoader.forEach(provider -> {
            String systemInfo = provider.getSystemInfo();
            System.out.println(systemInfo);
        });
    }
}

这样一个简单的 Java SPI 的demo就完成了。可以看到其中最为核心的就是通过一系列的约定（其实，就是按照人家 java.util.ServiceLoader 的规范标准来），然后，通过ServiceLoader 这个类来加载具体的实现类，进而调用实现类的服务。

3. SPI 实现原理解析

首先，ServiceLoader实现了Iterable接口，所以它有迭代器的属性，这里主要都是实现了迭代器的hasNext和next方法。这里主要都是调用的lookupIterator的相应hasNext和next方法，lookupIterator是懒加载迭代器。

其次，LazyIterator中的hasNext方法，静态变量PREFIX就是”META-INF/services/”目录，这也就是为什么需要在classpath下的META-INF/services/目录里创建一个以服务接口命名的文件。

最后，通过反射方法Class.forName()加载类对象，并用newInstance方法将类实例化，并把实例化后的类缓存到providers对象中，(LinkedHashMap<String,S>类型）然后返回实例对象。

3.1. SPI 的不足

1.不能按需加载，需要遍历所有的实现，并实例化，然后在循环中才能找到我们需要的实现。如果不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。

2.获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。（Spring 的BeanFactory，ApplicationContext 就要高级一些了。）

3.多个并发多线程使用 ServiceLoader 类的实例是不安全的。

4. 扩展

要使用SPI, 重点是要在 META-INF/services 目录下, 写接口文件以及具体实现, 这样十分麻烦

谷歌有一个工具, 可以自动帮我们完成这个操作, 它就是auto-service,

4.1 使用

未实验

maven依赖

<dependency>
      <groupId>com.google.auto.service</groupId>
      <artifactId>auto-service-annotations</artifactId>
      <version>1.0-rc6</version>
      <optional>true</optional>
      <scope>compile</scope>
</dependency>
<dependency>
      <groupId>com.google.auto.service</groupId>
      <artifactId>auto-service</artifactId>
      <version>1.0-rc6</version>
      <optional>true</optional>
      <scope>compile</scope>
</dependency>

实现类

@AutoService(Phone.class)
public class IPhone implements Phone { 
    // ...
}
@AutoService(Phone.class)
public class Huawei implements Phone {
    // ...
}

这样就能正常使用了, 编译代码后, 在META-INF/services 会自动出现相应文件

Java SPI (Service Provider Interface) 机制详解-腾讯云开发者社区-腾讯云 (tencent.com)

google-auto之自动生成组件化文件_zcswl7961的博客-CSDN博客

java注解处理器之Google Auto Service - strongmore - 博客园 (cnblogs.com)

Google Auto Service_原理

1. 介绍#

2. 案例介绍#

3. SPI 实现原理解析#

3.1. SPI 的不足#

4. 扩展#

4.1 使用#