概述

SPI ，全称为 Service Provider Interface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。

1、SPI具体约定

当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里目录下创建一个接口的全限定名的文件，该文件的内容是是实现类的全限定名；
当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。

基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader

2、JDK实现

2.1 项目结构

2.2 SPI Demo的代码：

package com.lyq.service;
//定义接口
public interface PayMethod {
    void getPayMethod();
}

//两个实现类
package com.lyq.service.impl;

import com.lyq.service.PayMethod;

public class AliPayMethod implements PayMethod {
    public void getPayMethod() {System.out.println("ali pay");}
}

==============类分割线==================

package com.lyq.service.impl;

import com.lyq.service.PayMethod;

public class WeChatPayMethod implements PayMethod {
    public void getPayMethod() {System.out.println("wechat pay");}
}

最后要在ClassPath路径下配置添加一个文件。文件名字是接口的全限定类名（com.lyq.service.PayMethod），内容是实现类的全限定类名，多个实现类用换行符分隔。

com.lyq.service.PayMethod：

1 2	`com.lyq.service.impl.AliPayMethod com.lyq.service.impl.WeChatPayMethod`

2.3 测试

public class SPIDemo {
    public static void main(String[] args) {
        /**
         * 直接实例化耦合度较高
         */
        PayMethod aliPayMethod = new AliPayMethod();
        aliPayMethod.getPayMethod();
        PayMethod weChatPayMethod = new WeChatPayMethod();
        weChatPayMethod.getPayMethod();
        System.out.println("==========================");
        /**
         * 解耦灵活配置法
         */
        testSPI();
    }

    private static void testSPI() {
        //把我们的接口类型保存到ServiceLoader中 service变量
        //创建了lazyIterator对象 （把我们的接口保存     保存我们的classLoader）
        ServiceLoader<PayMethod> load = ServiceLoader.load(PayMethod.class);

        //或者Service.providers()方法获取我们的Iterator对象
        //Iterator<PayMethod> iterator  = Service.providers(PayMethod.class);

        Iterator<PayMethod> iterator = load.iterator();
        while(iterator.hasNext()){
            PayMethod next = iterator.next();
            next.getPayMethod();
        }

    }
}

通过spi机制也可以像我们new对象一样获取实例！执行结果如下：

ali pay
wechat pay

==========================

ali pay
wechat pay

2.4 分析

为什么不直接new而是用spi实现呢？

与我们java设计相关，系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则；实际用时AliPayMethod支付，如果觉得AliPay支付方式不实用，需要替换一种实现，比如将我们的AliPay支付换成WeChatPay支付，就需要修改代码。

为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。

Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。所以SPI的核心思想就是解耦。

3、适用场景

概括地说，适用于：调用者根据实际使用需要，启用、扩展、或者替换框架的实现策略

比较常见的例子：

数据库驱动加载接口实现类的加载
JDBC加载不同类型数据库的驱动
日志门面接口实现类加载
SLF4J加载不同提供商的日志实现类

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

4、源码分析

4.1 ServiceLoader.load()为例

4.1.1 成员变量

首先看看ServiceLoader类的签名类的成员变量：

public final class ServiceLoader<S> implements Iterable<S>{

	//指定的配置文件的路径
    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;
   ......
}

4.1.2 Load

ServiceLoader.load方法内创建一个新的ServiceLoader，并实例化该类中的成员变量，主要包括四大步骤：

1、loader（ClassLoader类型，类加载器）

2、acc（AccessControlContext类型，访问控制器）

3、providers(LinkedHashMap<String,S>类型，用于缓存加载成功的类)

4、lookupIterator(实现迭代器功能)

重要源码提炼如下：

public static <S> ServiceLoader<S> load(Class<S> service) {
	ClassLoader cl = Thread.currentThread().getContextClassLoader();
	return ServiceLoader.load(service, cl);
}

public static <S> ServiceLoader<S> load(Class<S> service,ClassLoader loader)
{
	return new ServiceLoader<>(service, loader);
}

private ServiceLoader(Class<S> svc, ClassLoader cl) {
    ////要加载的接口
	service = Objects.requireNonNull(svc, "Service interface cannot be null");
    //类加载器
	loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
    //访问控制器
    acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
    //先清空
    providers.clear();
    //实例化内部类
    lookupIterator = new LazyIterator(service, loader);
}

4.1.3 查找实现类

查找实现类和创建实现类的过程，都在LazyIterator完成。当我们调用iterator.hasNext和iterator.next方法的时候，实际上调用的都是LazyIterator的相应方法。

public Iterator<S> iterator() {
    return new Iterator<S>() {
        Iterator<Map.Entry<String,S>> knownProviders = providers.entrySet().iterator();
        public boolean hasNext() {
            if (knownProviders.hasNext())
                    return true;
            return lookupIterator.hasNext();
        }
        public S next() {
            f (knownProviders.hasNext())
                    return knownProviders.next().getValue();
            return lookupIterator.next();
        }
    };
}

重点关注lookupIterator.hasNext()方法，它最终会调用到hasNextService。读取META-INF/services/下的配置文件，获得所有能被实例化的类的名称，值得注意的是，ServiceLoader可以跨越jar包获取META-INF下的配置文件，具体加载配置的实现代码如下：

private class LazyIterator implements Iterator<S>{
    Class<S> service;
    ClassLoader loader;
    Enumeration<URL> configs = null;
    Iterator<String> pending = null;
    String nextName = null; 
    private boolean hasNextService() {
        //第二次调用的时候，已经解析完成了，直接返回
        if (nextName != null) {
            return true;
        }
        if (configs == null) {
            //META-INF/services/ 加上接口的全限定类名，就是文件服务类的文件
            //META-INF/services/spi.WordParse
            String fullName = PREFIX + service.getName();
            //将文件路径转成URL对象
            configs = loader.getResources(fullName);
        }
        while ((pending == null) || !pending.hasNext()) {
            //解析URL文件对象，读取内容，最后返回
            pending = parse(service, configs.nextElement());
        }
        //拿到第一个实现类的类名
        nextName = pending.next();
        return true;
    }
    
    /**
    * 创建实例,见4.1.4
    */
    private S nextService() {
        //......
    }
}

4.1.4 创建实例

当然，调用next方法的时候，实际调用到的是lookupIterator.nextService。它通过反射的方式，创建实现类的实例并返回。

private class LazyIterator implements Iterator<S>{
    private S nextService() {
        if (!hasNextService()) throw new NoSuchElementException();
        //全限定类名
        String cn = nextName;
        nextName = null;
        //创建类的Class对象
        Class<?> c = Class.forName(cn, false, loader);
        //通过newInstance实例化
        S p = service.cast(c.newInstance());
        //放入集合，返回实例
        providers.put(cn, p);
        return p; 
    }
}

5、Spring实现

JDK中使用的是ServiceLoader

spring使用的是SpringFactoriesLoader实现，在org.springframework.core.io.support包中

文件路路径不同，spring配置在MATE-INF/spring.factories中。

1
2

// 获取某个已定义接口的实现类，跟JDK的ServiceLoader SPI相似度为90%
List<BeanInfoFactory> beanInfoFactories = SpringFactoriesLoader.loadFactories(BeanInfoFactory.class, classLoader);

Spring通过classpath下META-INF/spring.factories配置文件，找到需要实例化的类进行实例化，其读取配置文件方式与jdk一致，但是比jdk更优势的地方是能指定bean进行实例化

6、总结

6.1 优点

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

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

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

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

6.2 缺点

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

点击这里查看源码

Java

Java SPI

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议，转载请注明出处！

SpringBoot自定义starterr 上一篇

RabbitMQ 下一篇