JavaSPI的原理和实践
在Java中,我们经常会提到面向接口编程,这样减少了模块之间的耦合,更加灵活。
在一个项目中我们也通常将接口和实现类放在一起,但是如果哪天我们要替换其它的实现类,或者是修改实现类,涉及到实现类的代码也要相应地修改。
能不能这样:在调用服务的时候,我们只调用接口,不用关心实现类呢?无论我们怎么切换实现类,调用接口的部分代码都能正常运行?
当然是可以的,Java SPI ( Service Provider Interface )就提供了这样的机制。
Java SPI机制中,我们 不再是手动指定接口和实现类的关系,而是让接口去寻找可用的实现类 。
事实上,我们经常使用的Spring框架、日志接口等等,都是使用了SPI机制实现了扩展。 1,SPI和API
在说起 SPI 之前,我们还是先看一下API ,API 我们已经很熟悉了,和SPI 都可以被称作接口。
只不过 API 的功能的实现,以及接口的定义全部是接口的实现者提供的,调用者只需要调用接口即可:
不过 SPI 就不一样了,在SPI 机制中,调用者仍然是调用接口,但是这个接口是独立存在的,并且可以由不同的实现者实现:
也就是说,这里接口只是一个标准,并且提供接口的那一方并不一定回去实现接口,而是根据接口的定义,由更多的第三方实现。
这个接口可以 由一个甚至是多个实现者去实现 。也因此, 调用者在调用接口时,可能还需要指定一下使用哪个实现者的实现类 。
实现者也叫做 服务提供者 。
事实上,我们日常生活中经常使用的U盘也很类似SPI 机制,U盘使用的是USB接口,USB接口仅仅是一个规范(接口),但是发明USB接口的公司并没有去生产U盘,而是由不同的U盘厂商例如金士顿、闪迪(实现者)等等去根据这个规范生产U盘,然后我们就可以去选择自己喜欢的牌子(选择实现者)购买U盘,不过平时无论使用什么牌子的U盘,我们只需要插入到电脑的USB接口(调用接口)即可使用,而不用关心不同的厂商是怎么实现USB接口的功能的。
可见,SPI 机制将实现者和接口再次解耦合了,使得接口更加易于扩展。
事实上,我们常常用的SLF4J 就是一个Java的日志接口,但是它也仅仅是一个接口,所以被称作门面。而它的实现有Logback 、Log4j 等等,并且在切换实现的时候,我们只需要修改一下依赖配置即可,代码并不需要任何变动,因为代码中也仅仅是调用了接口。2,自己完成一个SPI
那么现在,我们也来以一个最简单的日志接口为例,实现自己的SPI 。(1) 定义SPI接口
先新建一个空的Maven项目log-interface ,然后在里面创建一个日志接口,声明日志接口具备的方法(功能):package com.gitee.swsk33.loginterface.spi; /** * 定义日志接口 */ public interface Logger { /** * INFO级别日志方法 * * @param message 日志打印消息 */ void info(String message); /** * DEBUG级别日志方法 * * @param message 日志打印消息 */ void debug(String message); } 复制代码
这样,我们便定义了这么一个日志接口,并声明日志接口需要有info 和debug 这两个日志功能。
然后就是编写服务类,这个服务类是这里最为重要的地方,它的作用是扫描所有实现了Logger 接口的实现类并加载进来,然后供调用者去调用。
先看代码:package com.gitee.swsk33.loginterface.service; import com.gitee.swsk33.loginterface.spi.Logger; import java.util.ArrayList; import java.util.List; import java.util.ServiceLoader; /** * 服务,用于加载所有服务使用者的实现类,以及供外部调用 * 该类为一个单例 */ public class LoggerService { /** * 该类唯一单例 */ private static final LoggerService LOGGER = new LoggerService(); /** * 默认的Logger实现类 */ private final Logger defaultLogger; /** * 所有的Logger实现类列表 */ private final List allLoggers = new ArrayList<>(); /** * 私有化构造器 */ private LoggerService() { // 加载全部Logger接口的实现类 ServiceLoader loader = ServiceLoader.load(Logger.class); // 将实现类放入我们的Logger实现类列表 for (Logger logger : loader) { allLoggers.add(logger); } // 这里取出第一个作为默认实现类 if (!allLoggers.isEmpty()) { defaultLogger = allLoggers.get(0); } else { defaultLogger = null; } System.out.println("加载到" + allLoggers.size() + "个服务实现!"); } /** * 获取该服务类的唯一单例 * * @return 该服务类的唯一单例 */ public static LoggerService getInstance() { return LOGGER; } /** * 调用默认的实现类的info日志打印方法 * * @param message 消息 */ public void info(String message) { if (defaultLogger == null) { System.err.println("没有找到实现了Logger接口的类!"); return; } defaultLogger.info(message); } /** * 调用默认的实现类的debug日志打印方法 * * @param message 消息 */ public void debug(String message) { if (defaultLogger == null) { System.err.println("没有找到实现了Logger接口的类!"); return; } defaultLogger.debug(message); } } 复制代码
首先这个类是一个单例的类,在构造器中,我们使用ServiceLoader 这个类来将实现了Logger 接口的所有类都扫描进来,并存入我们的实现类列表,然后我们取出列表中的第一个作为默认实现。
在下面我们定义了info 和debug 来完成对接口的默认实现类的调用。
最后,在项目目录下执行mvn install 命令将其安装至本地Maven仓库,以便后续服务提供者引入并实现。(2) 完成一个接口的实现
现在再新建一个空的Maven项目logservice-one ,并引入上面接口项目为依赖:
然后编写实现类:package com.gitee.swsk33.logserviceone.service; import com.gitee.swsk33.loginterface.spi.Logger; /** * Logger SPI的实现类 */ public class LogOne implements Logger { @Override public void info(String s) { System.out.println("[LogOne INFO] " + s); } @Override public void debug(String s) { System.out.println("[LogOne DEBUG] " + s); } } 复制代码
然后在resources 目录下创建目录META-INF/services ,这个目录中是用于声明该服务实现中有哪些实现类实现了什么接口。
在这个目录下我们新建一个文件名为com.gitee.swsk33.loginterface.spi.Logger ,文件中的内容为:com.gitee.swsk33.logserviceone.service.LogOne 复制代码
可见,该目录下文件名是要实现的接口的全限定类名(包名 + 类名),而文件中内容是实现了该接口的实现类的全限定类名。
大家参考这里的文件名及其中的内容,与我们上述的接口全限定类名、实现类全限定类名对比一下就知道了!
如果说这个项目中有多个类实现了Logger 接口,那么我们都需要在文件中声明,一行一个实现类的全限定类名。
最终整个项目结构如下:
同样地,最后记得在项目目录下执行mvn install 命令将其安装至本地Maven仓库,以便调用者调用。(3) 测试接口
这里再新建一个Maven空项目log-test ,作为接口的调用者,在依赖中引入实现者:
然后创建一个主类调用一下接口试试:package com.gitee.swsk33.logtest; import com.gitee.swsk33.loginterface.service.LoggerService; public class Main { private static final LoggerService LOGGER = LoggerService.getInstance(); public static void main(String[] args) { LOGGER.info("测试info消息"); LOGGER.debug("测试debug消息"); } } 复制代码
结果:
可见,我们成功地调用了Logger 接口中的方法。
通常调用者的依赖中可能会同时引入 SPI 接口依赖和服务提供者(实现)的依赖,这样也没问题,不过通常服务提供者本身就依赖于SPI 接口,因此只引入服务提供者依赖,也会间接地引入SPI 接口依赖,不影响我们调用SPI 接口。
我们这里只有一个服务提供者logservice-one ,如果说还有logservice-two 等等多个服务提供者,我们只需要在依赖中更换一下即可,代码完全不需要改变。
也可见调用者在调用接口的时候,只需要关注接口就行了,不需要关心实现类。3,再看ServiceLoader
可见在SPI 接口中,我们使用ServiceLoader 完成了对所有实现了Logger 接口的类的扫描和加载,那么具体的过程是什么样的呢?
如果大家去查看这个类的源码,可以发现它实现了Iterable 接口,这也说明我们可以通过迭代的方式去完成多个实现类的切换。
然后在其源码中,有这么一个常量定义:static final String PREFIX = "META-INF/services/"; 复制代码
这就说明,ServiceLoader 会去扫描服务提供者的classpath 路径下的META-INF/services 目录,来扫描哪些类实现了指定接口,而其静态方法load 的参数,正是指定了被实现的接口。也因此我们要在服务提供者的项目的resources 目录下创建这个目录并申明接口和对应实现类的全限定类名。
在Maven项目中, resources 目录就对应的是classpath 的根目录。
简而言之,ServiceLoader 加载实现类的过程如下:先是调用load 方法并指定要扫描的接口然后扫描项目中META-INF/services 目录,这包括调用者项目以及它所引入的所有依赖包中的META-INF/services 目录下的声明扫描到所有实现类后,根据其类名,先判断是否跟SPI 接口为同一类型,如果是则利用反射的方式将所有实现类实例化,加载进内存,并返回所有实现类的实例列表
可见,这就是JDK中SPI 机制加载服务的大致过程,事实上,现在很多框架也利用SPI 机制实现了灵活地扩展。