1.Spi机制概述
SPI ，全称为Service Provider Interface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。
Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。
为什么不直接new而是用spi实现：
与我们java设计相关，系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则；实际用时word解析，如果觉得word解析方式不实用，需要替换一种实现，比如将我们的word解析换成Excel解析，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。
Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。所以SPI的核心思想就是解耦。
2.代码分析
public interface BaseDriven {
public void url(String url);
}
public class MysqlDriven implements BaseDriven {
@Override
public void url(String url) {
System.out.println("mysql " + url);
}
}
RedisDriven相同的代码思路
这里说明一点就是MysqlDriven和RedisDriven的pom有BaseDriven的依赖
<dependencies>
<dependency>
<groupId>com.atgiogi</groupId>
<artifactId>BaseDriven</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
最后Api调用:
public class MainApi {
public static void main(String[] args) {
ServiceLoader<BaseDriven> serviceLoader = ServiceLoader.load(BaseDriven.class);
Iterator<BaseDriven> iterator = serviceLoader.iterator();
// for (BaseDriven baseDriven : serviceLoader) {
// baseDriven.url("1");
// }
while (iterator.hasNext()){
BaseDriven driven = iterator.next();
driven.url("11");
}
}
}
pom有他们的依赖
<dependencies>
<dependency>
<groupId>com.atgiogi</groupId>
<artifactId>BaseDriven</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.atgiogi</groupId>
<artifactId>MysqlDriven</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.atgiogi</groupId>
<artifactId>RedisDriven</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
3.Spi机制的应用场景
数据库驱动加载接口实现类的加载
JDBC加载不同类型数据库的驱动
日志门面接口实现类加载
SLF4J加载不同提供商的日志实现类
Spring
Spring中大量使用了SPI,比如：对servlet3.0规范对ServletContainerInitializer的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
Dubbo
Dubbo中也大量使用SPI的方式实现框架的扩展, 不过它对Java提供的原生SPI做了封装，允许用户扩展实现Filter接口
4.ServiceLoader分析
ServiceLoader.load():
ServiceLoader.load方法内先创建一个新的ServiceLoader，并实例化该类中的成员变量，主要四大步骤包括：
1、loader(ClassLoader类型，类加载器)
2、acc(AccessControlContext类型，访问控制器)
3、providers(LinkedHashMap<String,S>类型，用于缓存加载成功的类)
4、lookupIterator(实现迭代器功能)
lookupIterator.hasNext():
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);
}
}
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;
}
}
调用next方法的时候，实际调用到的是lookupIterator.nextService。它通过反射的方式，创建实现类的实例并返回。
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
S p = service.cast(c.newInstance());
providers.put(cn, p);
return p;
}
5.Spi总结
优点
使用Java SPI机制的优势是实现解耦, 应用程序可以根据实际业务情况启用框架扩展或替换框架组件。
相比使用提供接口jar包，供第三方服务模块实现接口的方式，SPI的方式，让我们不必关心接口的实现类的路径，可以不用通过下面的方式获取接口实现类：
- 代码硬编码import 导入实现类
- 指定类全路径反射获取：例如在JDBC4.0之前，JDBC中获取数据库驱动类需要通过Class.forName(“com.mysql.jdbc.Driver”)，类似语句先动态加载数据库相关的驱动，然后再进行获取连接等的操作
- 第三方服务模块把接口实现类实例注册到指定地方，源框架从这个指定的地方访问实例
缺点
- 虽然ServiceLoader也算是使用的延迟加载，但是基本只能通过遍历全部获取，也就是接口的实现类全部加载并实例化一遍。如果你并不想用某些实现类，它也被加载并实例化了，这就造成了浪费。获取某个实现类的方式不够灵活，只能通过Iterator形式获取，不能根据某个参数来获取对应的实现类。
- 多个并发多线程使用ServiceLoader类的实例是不安全的。
