SPI服务发现机制

 

SPI服务发现机制

 

 

1、什么是SPI？

SPI的本质是一种“接口编程 + 策略模式 + 约定发现” 的机制。

• Service（服务）：一个特定的功能规范，通常是一个Java接口或抽象类。

• Service Provider Interface（服务提供者接口）：就是这个接口，定义了服务的标准。

• Service Provider（服务提供者）：对SPI接口的具体实现。

核心思想： 将服务的实现（提供商）与接口的定义（规范）分离。框架或核心库只定义接口，第三方可以提供自己的实现，然后核心库能自动发现并加载这些实现，而无需修改核心库的代码。

 

2、SPI的工作机制与约定

Java内置的SPI机制遵循一个非常简单的约定：

1. 在 META-INF/services/ 目录下，创建一个以 SPI接口的全限定名 命名的文件。

2. 文件内容是该接口的 具体实现类的全限定名，每行一个。

3. 程序通过 java.util.ServiceLoader 类来动态加载和实例化这些实现。

3、一个经典的例子：JDBC

这是理解SPI为何要打破双亲委派的最佳例子。

步骤分解：

1. 定义SPI接口

   • Java核心库（在 rt.jar 中）定义了 java.sql.Driver 接口。

2. 提供实现

   • MySQL厂商提供了 mysql-connector-java.jar，其中包含了 com.mysql.cj.jdbc.Driver 类，它实现了 java.sql.Driver 接口。

   • 在这个JAR包的 META-INF/services/ 目录下，会有一个名为 java.sql.Driver 的文件。

   • 文件内容只有一行：com.mysql.cj.jdbc.Driver。

3. 服务发现与加载

   • 在你的Java程序中，你通常会写 Class.forName("com.mysql.cj.jdbc.Driver")（老方式）或者直接 DriverManager.getConnection(...)（新方式）。

   • 在 DriverManager 的初始化阶段，它会使用 ServiceLoader 来加载所有在 META-INF/services/java.sql.Driver 文件中声明的驱动实现。

4、如何使用？

// 1. 通过ServiceLoader加载指定SPI接口的所有实现
ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class);

// 2. 遍历并使用这些实现
for (Driver driver : loader) {
    System.out.println("Found driver: " + driver.getClass().getName());
    // 可以根据需要调用driver的方法
    // driver.connect(...);
}

 

5、核心问题：类加载器的困境与打破双亲委派

现在我们来分析这个过程中的类加载器问题，这是SPI机制的精髓所在。

• java.sql.Driver 接口在哪里？

  • 它在 rt.jar 中。

  • 由 Bootstrap ClassLoader（启动类加载器）加载。

• com.mysql.cj.jdbc.Driver 实现类在哪里？

  • 它在应用程序的 ClassPath 下（比如 mysql-connector-java.jar）。

  • 理应由 Application ClassLoader（应用类加载器）加载。

按照双亲委派模型：

1. 当 ServiceLoader 试图去加载 com.mysql.cj.jdbc.Driver 时，它会委派给它的父加载器 Application ClassLoader。

2. Application ClassLoader 能成功加载这个类吗？不能！ 因为要加载 com.mysql.cj.jdbc.Driver，首先需要先解析它的父类/接口，也就是 java.sql.Driver。

3. Application ClassLoader 会委派给它的父加载器 Extension ClassLoader，后者再委派给 Bootstrap ClassLoader。

4. Bootstrap ClassLoader 负责加载核心库，它成功加载了 java.sql.Driver 接口。

5. 现在问题来了：Bootstrap ClassLoader 只认识 rt.jar 中的核心类，它根本不认识、也无法加载位于ClassPath下的 com.mysql.cj.jdbc.Driver 类！

6. 于是，加载请求会层层向下传递，最终又回到了 Application ClassLoader。这次，Application ClassLoader 发现自己找到了这个类，于是它成功加载了 com.mysql.cj.jdbc.Driver。

这里的关键点在于：
一个由父加载器（Bootstrap）加载的接口，需要用到由子加载器（Application）加载的实现类。 这是标准的双亲委派模型无法直接支持的，因为父加载器无法“向下”去请求子加载器加载东西。

解决方案：线程上下文类加载器

为了解决这个问题，Java引入了 Thread Context ClassLoader（线程上下文类加载器）。

• 是什么？ 它是绑定到当前线程的一个类加载器。

• 默认是什么？ 如果没有特别设置，默认就是 Application ClassLoader。

• 谁打破了委派？ ServiceLoader 在加载实现类时，并不使用它自己的类加载器（通常是 Application ClassLoader 或 Extension ClassLoader），而是显式地使用当前线程的上下文类加载器（默认就是 Application ClassLoader）来直接加载 META-INF/services/ 中配置的实现类。

这个过程的本质是：
让一个核心库的类（由 Bootstrap 加载的 DriverManager），“借用”了一条位于子层的类加载器（Application ClassLoader），来加载本不属于自己管辖范围的类。这是一种父级委托子级加载的模式，完美地“打破”了标准的双亲委派模型。

 

 

总结：