你应该了解的 Java SPI 机制

前言

不知你们如今有没有去公司复工，我已经在家办公将近 3 周了，同时也在家呆了一个多月；还好工做并无受到任何影响，我我的一直以为远程工做和 IT 行业是很是契合的，这段时间的工做效率甚至比在办公室还高，同时因为咱们公司的业务在海外，因此疫情几乎没有形成太多影响。

扯远了，此次主要是想和你们分享一下 Java 的 SPI 机制。周末没啥事，我翻了翻我以前的写的博客 《设计一个可拔插的 IOC 容器》，发现当时的实现并不那么优雅。

还没看过的朋友的我先作个前景提要，当时的需求：

我实现了一个相似于的 SpringMVC 但却很轻量的 http 框架 cicada，其中固然也须要一个 IOC 容器，能够存放全部的单例 bean。

这个 IOC 容器的实现我但愿能够有多种方式，甚至能够提供一个接口供其余人实现；固然切换这个 IOC 容器的过程确定是不能存在硬编码的，也就是这里所提到的可拔插。
当我想使用 A 的实现方式时，我就引入 A 的 jar 包，使用 B 时就引入 B 的包。

先给你们看看两次实现的区别，先从代码简洁程度来讲就是 SPI 更胜一筹。

什么是 SPI

在具体分析以前仍是先了解下 SPI 是什么？

首先它实际上是 Service provider interface 的简写，翻译成中文就是服务提供发现接口。

不过这里不要被这个名词搞混了，这里的服务发现和咱们常听到的微服务中的服务发现并不能划等号。

就如同上文提到的对 IOC 容器的多种实现方式 A、B、C（能够把它们理解为服务），我须要在运行时知道应该使用哪种具体的实现。

其实本质上来讲这就是一种典型的面向接口编程，这一点在咱们刚开始学习编程的时候就被反复强调了。

SPI 实践

接下来咱们来如何来利用 SPI 实现刚才提到的可拔插 IOC 容器。

既然刚才都提到了 SPI 的本质就是面向接口编程，因此天然咱们首先须要定义一个接口：

其中包含了一些 Bean 容器所必须的操做：注册、获取、释放 bean。

为了让其余人也能实现本身的 IOC 容器，因此咱们将这个接口单独放到一个 Module 中，可供他人引入实现。

因此当我要实现一个单例的 IOC 容器时，我只须要新建一个 Module 而后引入刚才的模块并实现 CicadaBeanFactory 接口便可。

固然其中最重要的则是须要在 resources 目录下新建一个 META-INF/services/top.crossoverjie.cicada.base.bean.CicadaBeanFactory 文件，文件名必须得是咱们以前定义接口的全限定名（SPI 规范）。

其中的内容即是咱们本身实现类的全限定名：

top.crossoverjie.cicada.bean.ioc.CicadaIoc

能够想象最终会经过这里的全限定名来反射建立对象。

只不过这个过程 Java 已经提供 API 屏蔽掉了：

public static CicadaBeanFactory getCicadaBeanFactory() {
        ServiceLoader<CicadaBeanFactory> cicadaBeanFactories = ServiceLoader.load(CicadaBeanFactory.class);
        if (cicadaBeanFactories.iterator().hasNext()){
            return cicadaBeanFactories.iterator().next() ;
        }

        return new CicadaDefaultBean();
    }

当 classpath 中存在咱们刚才的实现类（引入实现类的 jar 包），即可以经过 java.util.ServiceLoader 工具类来找到全部的实现类（能够有多个实现类同时存在，只不过一般咱们只须要一个）。

---

一些都准备好以后，使用天然就很是简单了。

<dependency>
        <groupId>top.crossoverjie.opensource</groupId>
        <artifactId>cicada-ioc</artifactId>
        <version>2.0.4</version>
    </dependency>

咱们只须要引入这个依赖便能使用它的实现，当咱们想换一种实现方式时只须要更换一个依赖便可。

这样就作到了不修改一行代码灵活的可拔插选择 IOC 容器了。

SPI 的一些其余应用

虽然平时并不会直接使用到 SPI 来实现业务，但其实咱们使用过的绝大多数框架都会提供 SPI 接口方便使用者扩展本身的功能。

好比 Dubbo 中提供一系列的扩展：

同类型的 RPC 框架 motan 中也提供了响应的扩展：

他们的使用方式都和 Java SPI 很是相似，只不过原理略有不一样，同时也新增了一些功能。

好比 motan 的 spi 容许是否为单例等等。

再好比 MySQL 的驱动包也是利用 SPI 来实现本身的链接逻辑。

总结

Java 自身的 SPI 其实也有点小毛病，好比：

• 遍历加载全部实现类效率较低。
• 当多个 ServiceLoader 同时 load 时会有并发问题（虽然没人这么干）。

最后总结一下，SPI 并非某项高深的技术，本质就是面向接口编程，而面向接口自己在咱们平常开发中也是必备技能，因此了解使用 SPI 也是很用处的。

本文全部源码：

https://github.com/TogetherOS/cicada

你的点赞与分享是对我最大的支持