1、基础概念
(1)、简介
①、SPI全称Service Provider Interface,是JDK内置的一种服务发现机制。提供的一套用来被第三方实现或者扩展的API,它可以用来启用框架扩展和替换组件。大多数开发人员可能不熟悉,因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。
②、Java SPI实际上是“基于接口编程 + 策略模式 + 配置文件”组合实现的动态加载机制。
③、系统里抽象的各个模块,往往有很多不同的实现方案,在面向的对象的设计里,一般推荐模块之间基于接口编程,模块之间不对实现类进行硬编码。
④、一旦代码里涉及具体的实现类,就违反了可拔插的原则,如果需要替换一种实现,就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明,这就需要一种服务发现机制。
⑤、Java SPI就是提供这样的一个机制:为某个接口寻找服务实现的机制。有点类似IOC的思想,就是将装配的控制权移到程序之外,在模块化设计中这个机制尤其重要。所以SPI的核心思想就是解耦。
(2)、约定实现
①、当服务提供者提供了接口的一种具体实现后,在jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件,内容为实现类的全限定名。
②、接口实现类所在的jar包放在主程序的classpath中。
③、主程序通过java.util.ServiceLoder动态装载实现模块,它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名,把类加载到JVM。
④、SPI的实现类必须携带一个不带参数的构造方法。
(3)、实际应用
①、数据库驱动加载接口实现类的加载,JDBC加载不同类型数据库的驱动。
②、日志门面接口实现类加载,SLF4J加载不同提供商的日志实现类。
③、Spring中大量使用了SPI,比如:对Servlet3.0规范对ServletContainerInitializer的实现、自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等。
④、SpringBoot中的自动配置原理,即SpringFactoriesLoader类读取配置文件spring.factories 中的配置文件的这种方式是一种SPI的思想。
⑤、Dubbo中也大量使用SPI的方式实现框架的扩展,不过它对Java提供的原生SPI做了封装,允许用户扩展实现Filter接口。
(4)、优缺点
①、优点
a、Java SPI机制的优势是实现解耦,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。
b、应用程序可根据实际业务情况启用框架扩展或替换框架组件。
②、缺点
a、SrviceLoader只能通过遍历全部获取,也就是接口的实现类全部加载并实例化一遍,如果有扩展实现初始化很耗时,但如果没用上也加载,会很浪费资源。
b、获取某个实现类的方式不够灵活,只能通过Iterator形式获取,不能根据某个参数来获取对应的实现类。
c、多个并发多线程使用ServiceLoader类的实例是不安全的,需要加锁控制。
2、ServiceLoader类
(1)、源码解析
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;
......
}
(2)、load()加载流程
①、ServiceLoader.load方法内先创建一个新的ServiceLoader,并实例化该类中的成员变量,包括:
②、ServiceLoader先判断成员变量providers对象中(LinkedHashMap类型)是否有缓存实例对象,如果有缓存,直接返回。如果没有缓存,执行类的装载:
a、读取META-INF/services/下的配置文件,获得所有能被实例化的类的名称。
b、通过反射方法Class.forName()加载类对象,并用instance()方法将类实例化。
c、把实例化后的类缓存到providers对象中(LinkedHashMap类型),然后返回实例对象。
①、先获取当前线程的ClassLoader,如果ClassLoader为空则使用SystemClassLoader。
a、loader(ClassLoader类型,类加载器)
b、acc(AccessControlContext类型,访问控制器)
c、providers(LinkedHashMap类型,用于缓存加载成功的类)
d、lookupIterator(实现迭代器功能)
public static <S> ServiceLoader<S> load(Class<S> service) {
// 获取当前线程的ClassLoader
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”);
// 如果ClassLoader为空则使用SystemClassLoader
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
②、清除一下缓存,再创建一个LazyIterator对象。
public void reload() {
// 清除之前已经通过ServiceLoader加载过的实现
providers.clear();
// 得到LazyInterator对象
lookupIterator = new LazyIterator(service, loader);
}
③、LazyIterator源码解析
a、LazyIterator#hasNext()方法
判断是否还有下一个元素,内部调用hasNextService()方法。
private boolean hasNextService() {
// 如果下一个不为空
if (nextName != null) {
return true;
}
if (configs == null) {
try {
// PREFIX = "META-INF/services/"
// 得到文件位置
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
nextName = pending.next();
return true;
}
b、LazyIterator#next()方法
返回下一个元素实例,内部调用nextService()方法。
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
// 获取当前解析到的实现类全限定名
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
// 加载指定的类
c = Class.forName(cn, false, loader);
}
...省略...
try {
// 创建实现类实例
S p = service.cast(c.newInstance());
// 放入缓存
providers.put(cn, p);
return p;
}
...省略...
}
3、SPI应用示例
(1)、整体代码结构
①、operate模块:定义公共接口,供其他模块实现
②、add模块:加法运算实现模块,pom依赖operate模块,定义实现类,并创建META-INF/services/下对应的文件。
③、multiply模块:乘法运算实现模块,pom依赖operate模块,定义实现类,并创建META-INF/services/下对应的文件。
④、test模块,测试类,pom依赖add模块、multiply模块。
(2)、operate模块
①、接口定义
package com.demo.spi.operate;
public interface Operate {
void execute(int num1, int num2);
}
(3)、multiply模块
①、接口实现
package com.demo.spi.multiply;
import com.demo.spi.operate.Operate;
public class MultiplyOperate implements Operate {
@Override
public void execute(int num1, int num2) {
System.out.println("MultiplyOperate操作:num1 * num2 = " + (num1 * num2));
}
}
②、pom文件
<dependency>
<groupId>com.demo.spi.operate</groupId>
<artifactId>operate</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
③、META-INF/services/目录对应文件
(4)、add模块
①、接口实现
package com.demo.spi.add;
import com.demo.spi.operate.Operate;
public class AddOperate implements Operate {
@Override
public void execute(int num1, int num2) {
System.out.println("AddOperate操作:num1 + num2 = " + (num1 + num2));
}
}
②、pom文件
<dependency>
<groupId>com.demo.spi.operate</groupId>
<artifactId>operate</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
③、META-INF/services/目录对应文件
(5)、test模块
①、pom文件
根据需要,通过配置自定义引入的模块,不需要引入对应的实现类。
<!--乘法运算模块-->
<dependency>
<groupId>com.demo.spi.multiply</groupId>
<artifactId>multiply</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<!--加法运算模块-->
<dependency>
<groupId>com.demo.spi.add</groupId>
<artifactId>add</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
②、测试类
package com.demo.spi;
import com.demo.spi.operate.Operate;
import java.util.ServiceLoader;
public class TestSPI {
public static void main(String[] args){
ServiceLoader<Operate> serviceLoader = ServiceLoader.load(Operate.class);
for (Operate operate : serviceLoader) {
operate.execute(10, 10);
}
}
}