Java中的SPI原理浅谈 - 一只烤鸭朝北走
source link: https://www.cnblogs.com/wha6239/p/16692713.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Java中的SPI原理浅谈
在面向对象的程序设计中，模块之间交互采用接口编程，通常情况下调用方不需要知道被调用方的内部实现细节，因为一旦涉及到了具体实现，如果需要换一种实现就需要修改代码，这违反了程序设计的"开闭原则"。所以我们一般有两种选择：一种是使用API(Application Programming Interface)，另一种是SPI（Service Provider Interface），API通常被应用程序开发人员使用，而SPI通常被框架扩展人员使用。
在进入下面学习之前，我们先来再加深一下API和SPI这两个的印象：
API:由实现方制定接口标准并完成对接口的不同实现，这种模式服务接口从概念上更接近于实现方；
SPI:由调用方制定接口标准，实现方来针对接口提供不同的实现；从前半句话我们来看，SPI其实就是"为接口查找实现"的一种服务发现机制；这种模式，服务接口组织上位于调用方所在的包中，实现位于独立的包中。
API和SPI简略图示：
看完上面的简单图示，相信大家对API和SPI的区别有了一个大致的了解，现在我们使用SPI机制来实现我们一个简单的日志框架：
第一步，创建一个maven项目命名为spi-interface，定义一个SPI对外服务接口，用来后续提供给调用者使用；
package cn.com.wwh;
/**
*
* @FileName Logger.java
* @version:1.0
* @Description: 服务提供者接口
* @author: wwh
* @date: 2022年9月19日 上午10:31:53
*/
public interface Logger {
/**
*
* @Description:(功能描述)
* @param msg
*/
public void info(String msg);
/**
*
* @Description:(功能描述)
* @param msg
*/
public void debug(String msg);
}
package cn.com.wwh;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.ServiceLoader;
/**
*
* @FileName LoggerService.java
* @version:1.0
* @Description: 为服务的调用者提供特定的功能，是SPI的核心功能
* @author: wwh
* @date: 2022年9月19日 上午10:33:30
*/
public class LoggerService {
private static final LoggerService INSTANCE = new LoggerService();
private final Logger logger;
private final List<Logger> loggers = new ArrayList<>();
private LoggerService() {
//ServiceLoader是实现SPI的核心类
ServiceLoader<Logger> sl = ServiceLoader.load(Logger.class);
Iterator<Logger> it = sl.iterator();
while (it.hasNext()) {
loggers.add(it.next());
}
if (!loggers.isEmpty()) {
logger = loggers.get(0);
} else {
logger = null;
}
}
/**
* @Description:(功能描述)
* @return
*/
public static LoggerService getLoggerService() {
return INSTANCE;
}
/**
*
* @Description:(功能描述)
* @param msg
*/
public void info(String msg) {
if (logger == null) {
System.err.println("在info方法中没有找到Logger的实现类...");
} else {
logger.info(msg);
}
}
/**
*
* @Description:(功能描述)
* @param msg
*/
public void debug(String msg) {
if (logger == null) {
System.err.println("在debug方法中没有找到Logger的实现类...");
} else {
logger.info(msg);
}
}
}
将上面这个这个项目打成spi-interface.jar包。
第二步，新建一个maven项目并导入第一步中打出来的spi-interface.jar包，这个项目用来提供服务的实现，定义一个类，实现第一步中定义的cn.com.wwh.Logger接口，示例代码如下：
package cn.com.wwh;
import cn.com.pep.Logger;
/**
*
* @FileName Logback.java
* @version:1.0
* @Description: 服务接口的实现类
* @author: wwh
* @date: 2022年9月19日 上午10:50:31
*/
public class Logback implements Logger {
@Override
public void debug(String msg) {
System.err.println("调用Logback的debug方法，输出的日志为：" + msg);
}
@Override
public void info(String msg) {
System.err.println("调用Logback的info方法，输出的日志为：" + msg);
}
}
同时在当前项目的classpath路径下建立META-INF/services/文件夹（至于为什么这么建立目录，我们一会儿再解释），并且新建一个名称为cn.com.wwh.Logger内容为cn.com.wwh.Logback的文件，这一步是关键（具体作用后面再详细说明），然后将上面第二步这个这个项目打成spi-provider.jar包，供给之后使用，我目前使用的开发工具是Eclipse，目录结构如下图所示：
第三步，编写测试类，新建一个maven项目，命名为spi-test，导入前面两个步骤打的spi-interface.jar和spi-provider.jar这两个jar包，并编写测试代码，示例如下：
package cn.com.wwh;
import cn.com.pep.LoggerService;
/**
*
* @FileName SpiTest.java
* @version:1.0
* @Description:
* @author: wwh
* @date: 2022年9月19日 上午10:56:31
*/
public class SpiTest {
public static void main(String[] args) {
LoggerService logger = LoggerService.getLoggerService();
logger.info("我是中国人");
logger.debug("白菜多少钱一斤");
}
}
有了SPI我们可以将服务和服务提供者轻松地解耦，假如将来的某一天我们需要将日志保存到数据库，或者通过网络发送，我们直接只需要替换针对服务接口的实现类即可，别的地方都不用修改，这更符合程序设计中的“开闭原则”。
SPI的大致原理是：应用启动的时候，扫描classpath下面的所有jar包，将jar包下的/META-INF/services/目录下的文件加载到内存中，进行一系列的解析（文件的名称是spi接口的全路径名称，文件内容应该是spi接口实现类的全路径名，可以用多个实现类，在文件中换行保存），之后判断当前类和当前接口是否是同一类型？结果为true，则通过反射生成指定类的实例对象，保存到一个map集合中，可以通过遍历或者迭代的方式拿出来使用。
SPI实质就是一个加载服务实现的工具，核心类是ServiceLoader，其实了解了SPI的原理，我们再接着探究JDK中的源码就没有那么费力了，下面我们开始源码分析吧。
ServiceLoader类是定义在java.util包下的，使用final定义禁止子类继承和修改，实现了Iterable接口，使得可以通过迭代或者遍历的方式获取SPI接口的不同实现。
从上面的我们所举的例子中，我们知道SPI的入口是ServiceLoader.load(Class<S> service)方法，我们来看看它都干了什么？
上面的这4步总的来说，就是使用指定的类型和当前线程绑定的classLoader实例化了一个LazyIterator对象赋值给lookupIterator这个引用，并且清除了原来providers列表中缓存的服务的实现。接下来我们调用了ServiceLoader实例的iterator（）方法获取了一个迭代器，代码如下：
1 public Iterator<S> iterator() {
2 //通过匿名内部类方式提供了一个迭代器
3 return new Iterator<S>() {
4 //获取缓存的服务实现者的迭代器
5 Iterator<Map.Entry<String, S>> knownProviders = providers.entrySet().iterator();
6
7 //判断迭代器中是否还有元素
8 public boolean hasNext() {
9 //缓存的服务实现者的迭代器中已经没有元素了
10 if (knownProviders.hasNext())
11 return true;
12 return lookupIterator.hasNext();//判断延迟加载的迭代器中是否还有元素
13 }
14
15 //获取迭代其中的下一个元素
16 public S next() {
17 if (knownProviders.hasNext())
18 return knownProviders.next().getValue();
19 return lookupIterator.next();//获取延迟加载的迭代器中的下一个元素
20 }
21
22 public void remove() {
23 throw new UnsupportedOperationException();
24 }
25 };
26 }
我们接着调用上步获取的迭代器it的hasNext()方法，因为我们在ServiceLoader.load()过程中其实是清除了providers列表中的缓存服务实现的，所以其实调用的是lookupIterator.hasNext()方法，如下：
1 public boolean hasNext() {
2 if (nextName != null) {//存在下一个元素
3 return true;
4 }
5 if (configs == null) {//配置文件为空
6 try {
7 String fullName = PREFIX + service.getName();//获取配置文件路径
8 if (loader == null)
9 configs = ClassLoader.getSystemResources(fullName);
10 else
11 configs = loader.getResources(fullName);//加载配置文件
12 } catch (IOException x) {
13 fail(service, "Error locating configuration files", x);
14 }
15 }
16 //遍历配置文件内容
17 while ((pending == null) || !pending.hasNext()) {
18 if (!configs.hasMoreElements()) {
19 return false;
20 }
21 pending = parse(service, configs.nextElement());//配置文件内容解析
22 }
23 nextName = pending.next();//获取服务实现类的全路径名
24 return true;
25 }
26
假如上部判断为true,紧接着我们又调用了迭代器it的next()方式，同理也调用的是lookupIterator.next()方法，源码如下：
1 public S next() {
2 if (!hasNext()) {
3 throw new NoSuchElementException();
4 }
5 String cn = nextName;//文件中保存的服务接口实现类的全路径名
6 nextName = null;
7 Class<?> c = null;
8 try {
9 //获取全限定名的Class对象
10 c = Class.forName(cn, false, loader);
11 } catch (ClassNotFoundException x) {
12 fail(service, "Provider " + cn + " not found");
13 }
14 //判断实现类和服务接口是否是同一类型
15 if (!service.isAssignableFrom(c)) {
16 fail(service, "Provider " + cn + " not a subtype");
17 }
18 try {
19 //通过反射生成服务接口的实现类，并判断这个实例是否是接口的实现
20 S p = service.cast(c.newInstance());
21 //将服务接口的实现缓存起来，并返回
22 providers.put(cn, p);
23 return p;
24 } catch (Throwable x) {
25 fail(service, "Provider " + cn + " could not be instantiated", x);
26 }
27 throw new Error(); // This cannot happen
28 }
其实spi实现的主要流程是：扫描classpath路径下的所有jar包下的/META-INF/services/目录（即我们需要将服务接口的具体实现类暴露在这个目录下，之前我们提到需要在实现类的classpath下面建立一个/META-INF/services/文件夹就是这个原因。），找到对应的文件，读取这个文件名找到对应的SPI接口，然后通过InputStream流将文件内容读出来，获取到实现类的全路径名，并得到这个全路径名所表示的Class对象，判断其与服务接口是否是同一类型，然后通过反射生成服务接口的实现，并保存在providers列表中，供给后续的使用。
SPI这种设计方式为我们的应用扩展提供了极大的便利，但是它的短板也是显而易见的，Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。所以说 Java SPI 无法按需加载实现类。
另外，SPI 机制在很多框架中都有应用：slf4j日志框架、Spring 框架的基本原理也是类似的反射。还有 Dubbo 框架提供同样的 SPI 扩展机制，只不过 Dubbo 和 spring 框架中的 SPI 机制具体实现方式跟咱们今天学得这个有些细微的区别（Dubbo可以实现按需加载实现类），不过整体的原理都是一致的，我们今天先对SPI有个简单的了解，相信有了今天的基础理解剩下的那几个也不是什么难事。
好了，今天就到这儿了，文章中有说的不对的地方还请各位大佬批评指正，一起学习，共同进步，谢谢。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK