Java 的 SPI 机制是什么？和 API 有什么区别？

简化版

SPI（Service Provider Interface，服务提供者接口）是 Java 提供的一种**「接口定义在一方，实现由第三方提供并动态加载」的机制。核心思路：框架方只定义接口，不写实现；服务提供方写实现类，并在 META-INF/services/ 下放一个「接口全名」命名的文件，里面写实现类的全名；运行时用 ServiceLoader 读取这些文件、反射加载所有实现。它实现了面向接口编程 + 解耦**，是 JDBC 驱动、SLF4J 日志门面、Dubbo 扩展等的底层机制。和 API 的区别：API 是「我定义我实现，你来调用」，SPI 是「我定义接口，你来实现，我来加载」——调用方和实现方的角色反过来了。

详细版

SPI 的三个组成：

1. 接口：框架方定义（如 java.sql.Driver）
2. 实现类：提供方实现（如 mysql 的 com.mysql.cj.jdbc.Driver）
3. 配置文件：META-INF/services/接口全限定名
             文件内容 = 实现类全限定名（一行一个）

使用 ServiceLoader 加载：

// 框架方：定义接口
public interface Logger { void log(String msg); }

// 提供方：实现 + 在 META-INF/services/com.xxx.Logger 文件里写实现类全名
public class ConsoleLogger implements Logger { ... }

// 加载方：运行时发现并加载所有实现
ServiceLoader<Logger> loaders = ServiceLoader.load(Logger.class);
for (Logger logger : loaders) {    // 遍历触发反射实例化
    logger.log("hello");
}

SPI vs API：

维度	API	SPI
接口定义方	实现方（提供者）	调用方（框架）
实现方	提供者自己	第三方
谁调用	使用者调提供者的接口	框架加载并调第三方实现
典型	普通类库的公开方法	JDBC、SLF4J、Dubbo SPI

⚠️ JDK 原生 SPI 有个缺点：ServiceLoader 会一次性加载配置文件里所有实现类并实例化，不能按需加载某一个（哪怕你只想用其中一个）。Dubbo 因此自己实现了增强版 SPI（按 key 精确加载、支持自适应和依赖注入）。

完整版教学

一、SPI 要解决的问题：框架不想依赖具体实现

设想你写一个框架，需要「日志」功能，但你不想把框架绑死在某个具体日志库上（用户可能想用 log4j、logback、或自研的）。怎么办？

坏方案：框架直接 new Log4jLogger()  → 强依赖 log4j，用户换不了
好方案（SPI）：
  框架只定义 Logger 接口，不关心谁实现
  用户想用哪个日志库，就提供哪个实现 + 配置文件
  框架运行时用 ServiceLoader 把用户提供的实现加载进来

SPI 的本质是**「控制反转」的一种**：框架把「用哪个实现」的决定权交给使用者，自己只面向接口编程。这样框架和实现彻底解耦——框架 jar 里没有任何具体实现的依赖，实现由外部「插」进来。JDBC 是最经典的例子：java.sql 只定义 Driver 接口，MySQL/Oracle 各自提供驱动实现，你换数据库只需换驱动 jar，业务代码不动。

二、SPI 和 API 的方向：谁定义、谁实现、谁调用

理解 SPI 最关键的是搞清「角色反转」：

API（普通类库）：
  提供者：定义接口 + 写实现 + 打包
  使用者：调用提供者的接口
  方向：使用者 ──调用──▶ 提供者的实现

SPI（服务发现）：
  框架方：定义接口 + 写加载逻辑（不写实现）
  提供者：写实现 + 配置文件
  方向：框架 ──加载并回调──▶ 第三方的实现

一句话：API 是「别人写好给我调」，SPI 是「我定标准让别人来实现，我负责发现和加载」。SPI 里，接口的定义方（框架）和实现方（第三方）是分离的，且框架反过来「调用」第三方的实现——这正是「Interface」前面那个「Service Provider」的含义：为「服务提供者」定义的接口。

三、ServiceLoader 的工作原理

ServiceLoader.load(接口) 的内部流程：

1. ServiceLoader.load(Logger.class)
2. 扫描 classpath 下所有 jar 的 META-INF/services/com.xxx.Logger 文件
3. 读取文件里每一行（实现类的全限定名）
4. 迭代时：Class.forName(实现类名) 加载 → newInstance() 反射实例化
5. 返回实现实例，供框架使用

关键是「约定优于配置」：不需要框架知道有哪些实现，只要提供方把实现类名写进 META-INF/services/接口全名 这个约定位置的文件，ServiceLoader 就能自动发现。加一个新实现，不用改框架任何代码，只要 jar 里带上配置文件——这就是「可插拔」。加载是懒加载的（迭代到才实例化），但不能只加载指定的某一个，这是 JDK SPI 的局限。

四、破坏双亲委派：SPI 的类加载难题

SPI 有一个经典的「双亲委派」难题，是面试高频深挖点。回顾双亲委派：类加载时优先委派给父加载器，核心类（如 java.sql.Driver）由 Bootstrap ClassLoader 加载。

问题：java.sql.DriverManager（核心类，Bootstrap 加载）
      要加载 com.mysql.Driver（实现类，在应用 classpath，应用类加载器管）
      按双亲委派：Bootstrap 加载器根本看不到应用 classpath 的类！
      → Bootstrap 无法加载 MySQL 驱动，SPI 卡住了

JDK 的解法是线程上下文类加载器（Thread Context ClassLoader）：

DriverManager 加载驱动时，不走双亲委派，而是：
  用 Thread.currentThread().getContextClassLoader()（默认是应用类加载器）
  → 让"高层的核心类"能反向使用"低层的应用类加载器"去加载实现
  → 打破了双亲委派"只能向上委派"的限制

这是「父加载器请求子加载器帮忙加载」的反向操作，专门为 SPI 设计。面试问「SPI 和双亲委派的关系」，答案就是：SPI 通过线程上下文类加载器打破了双亲委派，让核心类能加载到应用层的实现。

五、SPI 的实战应用

SPI 在 Java 生态里无处不在：

应用	接口	SPI 加载的实现
JDBC	`java.sql.Driver`	MySQL/Oracle/PostgreSQL 各家驱动
SLF4J	日志门面	logback/log4j 具体日志实现
Spring Boot	`spring.factories`（增强版 SPI）	各种自动配置类
Dubbo	扩展点接口	各种协议、负载均衡、序列化实现
JAXP/XML	解析器接口	各种 XML 解析器实现

以 JDBC 为例，为什么现在不用写 Class.forName("com.mysql.jdbc.Driver") 了？因为 JDBC 4.0+ 用了 SPI——MySQL 驱动 jar 的 META-INF/services/java.sql.Driver 文件里已注册了驱动类，DriverManager 启动时通过 ServiceLoader 自动加载，无需手动注册。这就是 SPI「自动发现」的威力。

六、JDK SPI 的局限与增强版

JDK 原生 ServiceLoader 简单但有硬伤，Dubbo/Spring 都做了增强：

局限	说明	增强方案
全量加载	一次实例化所有实现，无法只取一个	Dubbo SPI 按 key 精确加载
无法传参/注入	实例化不能依赖注入	Dubbo SPI 支持 IoC/AOP
加载失败难定位	一个实现出错影响整体	增强版做了容错
只能按顺序遍历	不能按名字选实现	Dubbo 用 `@SPI` + name 选择

所以 Dubbo 不用 JDK SPI 而是自研了一套（放在 META-INF/dubbo/ 下，用 key=实现类 格式），支持「按名字加载指定实现」「自适应扩展」「实现类之间依赖注入」。这也是面试常问「Dubbo SPI 和 JDK SPI 的区别」的由来——增强了按需加载、IoC、AOP 等能力。

记忆钩子：「SPI = 框架定接口、第三方给实现、ServiceLoader 靠 META-INF/services 配置文件反射加载；和 API 角色反转（我定标准你来实现）；靠线程上下文类加载器打破双亲委派；JDBC/SLF4J/Dubbo 都用它」。

七、常见误区与追问

误区：SPI 和 API 差不多。 角色完全相反——API 是「提供者定义并实现、使用者调用」，SPI 是「框架定义接口、第三方实现、框架加载」，接口定义方和实现方分离。
误区：ServiceLoader 可以只加载我想要的那个实现。 JDK SPI 会全量加载配置文件里所有实现并实例化，不能按需选一个；要按 key 加载得用 Dubbo 增强 SPI。
误区：SPI 需要手动指定实现类。 不需要，把实现类名写进 META-INF/services 约定文件即可自动发现，加实现不改框架代码。
误区：SPI 不涉及类加载机制。 它恰恰要打破双亲委派——核心类通过线程上下文类加载器反向加载应用层实现，这是 SPI 的关键难点。
追问：SPI 为什么要破坏双亲委派？ 核心类（如 DriverManager，Bootstrap 加载）需加载应用 classpath 里的实现类，但 Bootstrap 看不到应用层，只能用线程上下文类加载器（应用类加载器）反向加载。
追问：JDBC 4.0 后为什么不用 Class.forName 注册驱动了？ 驱动 jar 用 SPI 在 META-INF/services/java.sql.Driver 注册了驱动类，DriverManager 通过 ServiceLoader 自动加载，无需手动注册。
追问：Dubbo SPI 相比 JDK SPI 增强了什么？ 按 key 精确加载指定实现（不全量）、支持实现类之间依赖注入（IoC）和包装（AOP）、自适应扩展、更好的容错。

八、加强记忆

SPI 是「框架定接口、第三方给实现、运行时动态加载」的解耦机制，本质是「控制反转」——框架不绑定具体实现，把「用哪个」的决定权交给使用者。三要素是接口（框架定义）+ 实现类（第三方）+ META-INF/services/接口全名 配置文件（内容是实现类全名），ServiceLoader.load(接口) 扫描这些文件、反射加载所有实现。它和 API 的角色恰好反转：API 是「别人写好给我调」，SPI 是「我定标准让别人实现、我来发现加载」。SPI 有个经典难点——它打破双亲委派：核心类（如 Bootstrap 加载的 DriverManager）要加载应用层的实现类，只能靠线程上下文类加载器反向委派。JDBC、SLF4J、Dubbo、Spring Boot 都建立在 SPI 上。JDK 原生 SPI 的局限是「全量加载、不能按 key 选、不支持注入」，所以 Dubbo 自研了增强版。一句话「框架定接口、别人来实现、ServiceLoader 读配置反射加载、靠线程上下文类加载器破双亲委派」。

简化版

详细版