（转）SPI机制

最新推荐文章于 2025-07-20 23:06:36 发布

_changeme

最新推荐文章于 2025-07-20 23:06:36 发布

阅读量270

点赞数

CC 4.0 BY-SA版权

分类专栏： java网页开发

原文链接：https://www.cnkirito.moe/spi/

java网页开发专栏收录该内容

4 篇文章

订阅专栏

前言

在查看Spring装配Servlet时候有用到的SPI机制
查看原文章JAVA 拾遗 – 关于 SPI 机制

JDK提供的SPI(Service Provider Interface)机制，可能很多人不太熟悉，因为这个机制是针对厂商或者插件的，也可以在一些框架的扩展中看到。其核心类 java.util.ServiceLoader可以在 jdk1.8 的文档中看到详细的介绍。虽然不太常见，但并不代表它不常用，恰恰相反，你无时无刻不在用它。玄乎了，莫急，思考一下你的项目中是否有用到第三方日志包，是否有用到数据库驱动？其实这些都和 SPI 有关。再来思考一下，现代的框架是如何加载日志依赖，加载数据库驱动的，你可能会对class.forName(“com.mysql.jdbc.Driver”)这段代码不陌生，这是每个 java 初学者必定遇到过的，但如今的数据库驱动仍然是这样加载的吗？你还能找到这段代码吗？这一切的疑问，将在本篇文章结束后得到解答。

首先介绍 SPI机制是个什么东西

实现一个自定义的 SPI

项目结构

invoker是我们的用来测试的主项目。
interface是针对厂商和插件商定义的接口项目，只提供接口，不提供实现。
good-printer,bad-printer 分别是两个厂商对 interface 的不同实现，所以他们会依赖于interface项目。
这个简单的 demo 就是让大家体验，在不改变invoker代码，只更改依赖的前提下，切换interface的实现厂商。

interface 模块

moe.cnkirito.spi.api.Printer
public interface Printer {
    void print();
}

interface 只定义一个接口，不提供实现。规范的制定方一般都是比较牛叉的存在，这些接口通常位于 java，javax 前缀的包中。这里的 Printer就是模拟一个规范接口。

good-printer 模块

3.1 good-printer\pom.xml

<dependencies>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>interface</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

规范的具体实现类必然要依赖规范接口

3.2 moe.cnkirito.spi.api.GoodPrinter

public class GoodPrinter implements Printer {
    public void print() {
        System.out.println("你是个好人 ~");
    }
}

作为 Printer规范接口的实现一

3.3 resources\META-INF\services\moe.cnkirito.spi.api.Printer
moe.cnkirito.spi.api.GoodPrinter

这里需要重点说明，每一个 SPI 接口都需要在自己项目的静态资源目录中声明一个 services 文件，文件名为实现规范接口的类名全路径，在此例中便是 moe.cnkirito.spi.api.Printer，在文件中，则写上一行具体实现类的全路径，在此例中便是 moe.cnkirito.spi.api.GoodPrinter。

这样一个厂商的实现便完成了。

4 bad-printer 模块

我们在按照和 good-printer 模块中定义的一样的方式，完成另一个厂商对 Printer 规范的实现。

4.1 bad-printer\pom.xml

<dependencies>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>interface</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

4.2 moe.cnkirito.spi.api.BadPrinter

public class BadPrinter implements Printer {
    public void print() {
        System.out.println("我抽烟，喝酒，蹦迪，但我知道我是好女孩 ~");
    }
}

4.3 resources\META-INF\services\moe.cnkirito.spi.api.Printer
moe.cnkirito.spi.api.BadPrinter

这样，另一个厂商的实现便完成了。

invoker 模块

这里的 invoker 便是我们自己的项目了。如果一开始我们想使用厂商 good-printer 的 Printer 实现，是需要将其的依赖引入。

<dependencies>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>interface</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>good-printer</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

5.1 编写调用主类

public class MainApp {


    public static void main(String[] args) {
        ServiceLoader<Printer> printerLoader = ServiceLoader.load(Printer.class);
        for (Printer printer : printerLoader) {
            printer.print();
        }
    }
}

ServiceLoader是java.util提供的用于加载固定类路径下文件的一个加载器，正是它加载了对应接口声明的实现类。

5.2 打印结果1

你是个好人 ~

如果在后续的方案中，想替换厂商的 Printer 实现，只需要将依赖更换

ndencies>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>interface</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>moe.cnkirito</groupId>
        <artifactId>bad-printer</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

调用主类无需变更代码，这符合开闭原则

5.3 打印结果 2

我抽烟，喝酒，蹦迪，但我知道我是好女孩 ~

是不是很神奇呢？这一切对于调用者来说都是透明的，只需要切换依赖即可！

SPI 在实际项目中的应用
先总结下有什么新知识，resources/META-INF/services 下的文件似乎我们之前没怎么接触过，ServiceLoader 也没怎么接触过。那么现在我们打开自己项目的依赖，看看有什么发现。

在 mysql-connector-java-xxx.jar 中发现了META-INF\services\java.sql.Driver文件，里面只有两行记录：

com.mysql.jdbc.Driver
com.mysql.fabric.jdbc.FabricMySQLDriver

我们可以分析出，java.sql.Driver 是一个规范接口，com.mysql.jdbc.Driver
com.mysql.fabric.jdbc.FabricMySQLDriver 则是 mysql-connector-java-xxx.jar 对这个规范的实现接口。

在 jcl-over-slf4j-xxxx.jar中发现了META-INF\services\org.apache.commons.logging.LogFactory文件，里面只有一行记录：

org.apache.commons.logging.impl.SLF4JLogFactory

相信不用我赘述，大家都能理解这是什么含义了

更多的还有很多，有兴趣可以自己翻一翻项目路径下的那些 jar 包

既然说到了数据库驱动，索性再多说一点，还记得一道经典的面试题：class.forName(“com.mysql.jdbc.Driver”) 到底做了什么事？

先思考下：自己会怎么回答？

都知道 class.forName 与类加载机制有关，会触发执行 com.mysql.jdbc.Driver类中的静态方法，从而使主类加载数据库驱动。如果再追问，为什么它的静态块没有自动触发？可答：因为数据库驱动类的特殊性质，JDBC 规范中明确要求 Driver 类必须向 DriverManager注册自己，导致其必须由class.forName 手动触发，这可以在java.sql.Driver 中得到解释。完美了吗？还没，来到最新的DriverManager源码中，可以看到这样的注释, 翻译如下：

DriverManager类的方法getConnection 和 getDrivers 已经得到提高以支持 Java Standard Edition Service Provider机制。JDBC 4.0 Drivers 必须包括 META-INF/services/java.sql.Driver 文件。此文件包含java.sql.Driver 的 JDBC 驱动程序实现的名称。例如，要加载 my.sql.Driver类，META-INF/services/java.sql.Driver 文件需要包含下面的条目：

my.sql.Driver

应用程序不再需要使用 Class.forName()显式地加载JDBC驱动程序。当前使用 Class.forName()加载JDBC驱动程序的现有程序将在不作修改的情况下继续工作。

可以发现，Class.forName 已经被弃用了，所以，这道题目的最佳回答，应当是和面试官牵扯到 JAVA 中的 SPI 机制，进而聊聊加载驱动的演变历史。

java.sql.DriverManager
public Void run() {
    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
    Iterator<Driver> driversIterator = loadedDrivers.iterator();

    try{
        while(driversIterator.hasNext()) {
            driversIterator.next();
        }
    } catch(Throwable t) {
    // Do nothing
    }
    return null;
}