引言
在日常的项目开发中，我们为了提升程序的扩展性，经常使用面向接口的编程思想进行编程。不仅体现了程序设计对于对修改关闭，对于扩展开放的设计原则，同时也实现了程序可插拔。那么今天本文所阐述的SPI正是这种编程思想的体现。今天就和大家聊聊SPI到底是个什么鬼。顺便和大家一起看下一些常见的框架中是怎么使用SPI机制来进行框架扩展的。
什么是SPI
我们经常使用的各种sdk其实就是一种接口以及接口的实现在同一jar包中的实现方式，通过调用接口完成一次业务调用。但是为了增强程序的扩展属性，可以考虑使用SPI。
SPI（Service Provider Interface），即为服务提供者接口。听上去有点不明觉厉，不知道表达什么意思。按照我的理解，它就是一种服务发现机制。其本质就是将接口与实现进行解偶分离，服务方只定义接口，具体实现由第三方进行实现，从而提升了程序的可扩展性，让服务提供方可以面向接口编程。
我们只需要在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成实现类的的加载注入。
使用方提供规则说明，实际服务提供方完成具体实现。其实这种思想和spring中的组件扫描是类似的，都是先指定好规则，服务提供方更具规范让框架自动进行服务发现。
重点来了，知识点来了，敲黑板了。自此我们可以发现，无论是本文谈到的SPI，还是SpringBoot中的自动配置原理，实际都是一种约定大于配置的开发思想，通过事先约定好的内容，进行具体实现，从而提升程序的扩展性。所以希望大家在看一项技术时，除了关注技术细节，进行纵向了解，也要关注横向技术对比，从而找到这些技术的共通之处，了解其背后的设计思想，我一直觉得这个是非常重要的，毕竟招式一直都是在变化，但是内功修炼更加重要。
SPI源码分析
1、SPI使用
Java SPI 约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件，然后文件里面记录的是此 jar 包提供的具体实现类的全限定名。大致的过程如下所示：
2、SPI实例分析
以Mysql的驱动加载为例，首先定义好需要进行扩展的模板接口，即为java.sql.Driver接口。各个数据库厂商可以更具自身数据库的特点进行对应的驱动开发，但是都要遵从这个模板接口。
在Mysql的驱动二方包中，在其 Classpath 路径下的 META-INF/services/ 目录中，创建一个以服务接口完全名称一致的的文件，在这个文件中保存的内容是模板接口具体实现类的完全限定名。
在对应的目录中进行具体的类实现，这些实现类都实现了java.sql.Driver接口。
具体的代码实现，通过ServiceLoader加载对应的实现类，完成类的实例化操作。当然这个ServiceLoader也可以自己定义，像Dubbo、Seata这样的框架都自己定义类加载器。
public final class ServiceLoader<S> implements Iterable<S> { private static final String PREFIX = "META-INF/services/"; ... public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader) { return new ServiceLoader<>(service, loader); } public static <S> ServiceLoader<S> load(Class<S> service) { ClassLoader cl = Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); } 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; reload(); } ... }
我们一起来分析下这个服务加载器的工作流程，首先通过ServiceLoader.load()进行加载。先获取当前线程绑定的 ClassLoader，如果当前线程绑定的 ClassLoader为null，则使用 SystemClassLoader进行代替，而后清除一下provider缓存，最后创建一个 LazyIterator。 LazyIterator的部分源码如下：
private class LazyIterator implements Iterator<S> { Class<S> service; ClassLoader loader; Enumeration<URL> configs = null; Iterator<String> pending = null; String nextName = null; ... public boolean hasNext() { if (acc == null) { return hasNextService(); } else { PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() { public Boolean run() { return hasNextService(); } }; return AccessController.doPrivileged(action, acc); } } ... private boolean hasNextService() { if (nextName != null) { return true; } if (configs == null) { try { //key：获取完全限定名 String fullName = PREFIX + service.getName(); if (loader == null) configs = ClassLoader.getSystemResources(fullName); else configs = loader.getResources(fullName); } catch (IOException x) { fail(service, "Error locating configuration files", x); } } while ((pending == null) || !pending.hasNext()) { if (!configs.hasMoreElements()) { return false; } pending = parse(service, configs.nextElement()); } nextName = pending.next(); return true; } ... }
key：通过预定好的目录地址以及类名来指定类的具体地址，类加载器根据这个地址来加载具体的实现类。
大致的SPI加载过程如下所示：
