关于JAVA SPI的面试题还蛮多的，正好来深度分析一下。在此之前，先看一道面试题。
面试官问：“Java的SPI机制是什么？”
你答：“META-INF/services里放配置文件，ServiceLoader加载。”
面试官追问：“那JDBC 4.0为什么不用写Class.forName了？Bootstrap ClassLoader看不见MySQL驱动的。”
是不是就有点被问倒了? 哈哈，下文尝试一下来回答这个问题。
本篇从三个层面来讲：
- SPI是什么、解决了什么痛点
- TCCL怎么让父加载器加载到子加载器的类，面试核心考点
- Dubbo/ES/Kafka Connect在SPI基础上做了什么增强，Spring Boot为什么没用它
读完本文后，面试官再问SPI，你能从META-INF/services一路讲到TCCL和Dubbo的@Adaptive。
SPI解决了什么痛点
做过业务系统的人都知道，框架如果只依赖具体实现类，换MySQL驱动、换日志实现，往往得改源码重新编译。搞中间件和基础库时，这条路子走不通，因为：接口得稳定，实现得能换。
SPI（Service Provider Interface）是JDK给出的约定：框架只依赖接口，第三方在jar里放**META-INF/services/配置文件，运行时由ServiceLoader**发现实现类。
JDBC是最常被引用的例子。JDBC 4.0之前，应用得自己写Class.forName("com.mysql.jdbc.Driver")把驱动类加载进来。4.0之后，DriverManager初始化时调用ServiceLoader.load(Driver.class)，classpath上各厂商驱动jar在META-INF/services/java.sql.Driver里登记实现类，应用只写jdbc:mysql://...，不用知道驱动类全名。控制权从应用主动加载变成了框架被动发现。
JDK SPI需要的三样东西：
| 要素 | 说明 | 要求 |
|---|---|---|
| 接口 | 框架定义的扩展契约 | 公共接口 |
| 配置文件 | META-INF/services/<接口全名> | UTF-8，每行一个实现类 |
| 实现类 | provider 具体类 | public 无参构造 |
和工厂+switch、配置文件里写类名再反射相比，SPI的差别在于约定统一：
| 方式 | 耦合度 | 发现机制 | 多实现共存 |
|---|---|---|---|
| 工厂 + switch | 框架要知道所有实现类名 | 编译期写死 | 加实现要改框架代码 |
| 配置类名 + 反射 | 配置与代码分离，但无标准目录 | 各自约定 | 靠配置选一项 |
| JDK SPI | 框架只依赖接口 | META-INF/services/<接口全名> | 天然支持多项，框架自行筛选 |
SPI的三要素齐了，但还有一个关键问题：配置文件在jar里，谁来扫？用什么ClassLoader扫？这就引出了TCCL。
TCCL(线程上下文类加载器)：SPI为什么能加载到应用classpath上的类
先看一个矛盾：
java.sql.DriverManager在rt.jar里，由Bootstrap ClassLoader加载。你的com.mysql.cj.jdbc.Driver在应用classpath里，由AppClassLoader加载。
Bootstrap根本看不见AppClassLoader的东西,这是双亲委派模型的硬性规定。
那JDBC 4.0凭什么能做到不用写Class.forName？
答案在TCCL（线程上下文类加载器）。ServiceLoader.load(Driver.class)无参重载时，取的是当前线程的上下文类加载器，默认指向AppClassLoader，从应用classpath扫描并加载驱动实现：
public static <S> ServiceLoader<S> load(Class<S> service) { ClassLoader cl = Thread.currentThread().getContextClassLoader(); return new ServiceLoader<>(Reflection.getCallerClass(), service, cl); }DriverManager.getConnection里也有类似逻辑：调用方类加载器为空或是Platform时，回退到TCCL。
准确说法：SPI通过TCCL主动绕过双亲委派的方向限制，让rt.jar里的框架代码能加载到应用classpath上的实现类。TCCL作为桥梁，让父加载器侧代码能加载子加载器可见的实现。
面试时把TCCL和JDBC驱动加载串起来讲，一般就能答到点子上。
JDK SPI怎么工作
两方各干什么
SPI里固定有两个角色。**框架（消费方）**只依赖接口，比如java.sql.Driver。**实现方（provider）**在jar里放两样东西：实现类本身，以及META-INF/services/java.sql.Driver，里面写实现类全名，一行一个。MySQL、PostgreSQL各自登记，框架代码不用改。
调用时按什么顺序发生
很多人以为ServiceLoader.load(Driver.class)一执行就会实例化驱动，其实不是。load只准备好loader，classpath还没扫。
真正干活的是迭代器。DriverManager初始化时拿到ServiceLoader<Driver>的迭代器，逐个next()。每往前一步，JDK才去classpath找META-INF/services/java.sql.Driver，读类名，再反射创建实例。这叫懒加载：第一次next()才暴露配置错误或类找不到。
ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class); Iterator<Driver> it = loader.iterator(); Driver driver = it.next(); // 到这行才真正去扫配置文件、加载类classpath上挂了多个驱动jar，配置文件会被合并，迭代器按顺序吐出多个Driver实例。DriverManager.getConnection(url)再逐个问能不能接这个URL，能接就用。SPI只负责找出来，选哪一个由框架定。带中间件接入的项目里，classpath同时挂MySQL和PostgreSQL驱动，最终用哪个取决于URL前缀匹配，不是SPI替你拍板。
DriverManager在初始化阶段对迭代中的异常做了catch，避免某个坏驱动拖垮全局——这是消费方的防御写法，不是SPI自带的容错。
实现方要满足什么
classpath部署时，实现类要有public无参构造，且能被当前ClassLoader加载。配置文件用UTF-8，#后面是注释，重复类名会跳过。
JDK 9之后走模块系统，SPI有两条并行路径：
| 机制 | 配置方式 | 优先级 |
|---|---|---|
| 模块化 SPI | module-info的provides/uses | 高，ServicesCatalog先查 |
| 传统 SPI | META-INF/services/文件 | 与模块化双轨并存 |
模块里的provider还可以提供静态provider()方法返回实例，不一定要无参构造。classpath上的命名模块实现，在旧式扫描路径里可能被跳过，做JPMS迁移时要单独留意。
JDK SPI是底座，中间件在底座上怎么改？先看两个插件场景。
Kafka Connect和Elasticsearch怎么用SPI
Elasticsearch和Kafka Connect都做插件，新能力靠外部的jar接入，不会在核心代码里把实现类名写死。两家都沿用META-INF/services/约定，差别在ClassLoader和实例化时机。
Kafka Connect：标准SPI + plugin.path
Connect的Source/Sink连接器、Converter、Transformation等，来自用户自带jar。Connect把plugin.path目录下的jar当插件库，启动时用ServiceLoaderScanner扫描。插件jar里要有对应接口的services文件，扫描器检查类能加载、public、有无参构造，才进可用列表。
Connect更贴近标准ServiceLoader规则。
Elasticsearch：自研SPIClassIterator，延迟实例化
ES启动时装插件，每个插件有自己的ClassLoader。PluginsService用自研的SPIClassIterator读services文件，只读类名、不马上**new**，避免classpath顺序和静态初始化把启动搞挂。和标准ServiceLoader比，ES多包这一层，因为插件ClassLoader隔离和启动顺序更复杂。
插件场景这么玩其实够用了，但是一些开源的RPC框架还要按名取、排序、注入，Dubbo因此自建了一套。
Dubbo为什么自己搞一套SPI
JDK SPI只能全量迭代，不能按名字取某一个实现，也没有优先级、依赖注入。RPC框架扩展点多、组合关系复杂，Dubbo在JDK SPI思路上自建了ExtensionLoader。
配置文件路径变了：META-INF/dubbo/internal/<接口全名>，内容是name=实现类，例如dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol。
加载方式也变了：不是for (Protocol p : loader)，而是按名取：
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("dubbo");Dubbo在原生SPI之上补了四块能力：
| 特性 | 作用 |
|---|---|
| 按名获取 | getExtension("dubbo")，不用全量迭代 |
@Adaptive | 按URL参数在运行时选具体实现 |
@Activate | 条件激活与order排序 |
| Wrapper | 装饰器链包装扩展点 |
Dubbo没有替换JDK SPI规范，而是在RPC场景把发现、选择、组装做完整。
Spring Boot为啥不用JDK SPI
Dubbo在SPI之上做了增强，那Spring Boot呢？很多人以为Spring Boot的自动配置也是JDK SPI，其实不是。
Spring Boot自动配置走的是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，由SpringFactoriesLoader演进而来，不是JDK SPI。别把@EnableAutoConfiguration说成JDK SPI。
| 对比项 | JDK SPI | Spring Boot imports |
|---|---|---|
| 配置文件 | META-INF/services/接口全名 | META-INF/spring/*.imports |
| 格式 | 每行一个实现类 | 每行一个配置类全名 |
| 典型用途 | JDBC、插件发现 | Starter自动配置 |
工业级框架的SPI演进对比
接口、配置文件、加载器，JDK SPI定了最小协议。Kafka Connect、Elasticsearch、Dubbo在同一思路上各自演进：改配置路径、换ClassLoader、控制实例化时机。
原理就讲到这里，下面我们过一遍高频的面试题。
面试里常问的四个问题
下面四个问题串起来，就是大多数SPI面试的主线。建议对照上文TCCL、Dubbo、Spring Boot几节，用自己的话说一遍。
Q1：SPI是什么
SPI是JDK的服务发现机制：框架定义接口，第三方在META-INF/services/登记实现类，ServiceLoader运行时加载。SPI是提供方实现框架定义的接口，控制权在框架这边。
Q2：TCCL和JDBC驱动加载怎么串起来？
DriverManager在rt.jar，MySQL驱动在应用classpath。ServiceLoader.load()无参重载取TCCL（默认AppClassLoader），从应用classpath扫描驱动。DriverManager.getConnection在类加载器为空或Platform时也回退TCCL。本质是TCCL作为桥梁，让父加载器侧代码能加载子加载器可见的实现。
Q3：Dubbo SPI和JDK SPI有什么不同？
JDK SPI只能全量迭代，无按名、无优先级、无注入。Dubbo用META-INF/dubbo/internal/和name=实现类格式，通过getExtension(name)按名加载；@Adaptive按URL选实现，@Activate做排序和条件激活，Wrapper做装饰。JDK SPI负责发现，Dubbo SPI负责发现+组装。
Q4：Spring Boot自动配置是JDK SPI吗？
不是。Spring Boot走META-INF/spring/*.imports，由SpringFactoriesLoader加载，配合@Conditional做条件装配。和JDK SPI是两条线，不要搞混。
最后，如何评价Java SPI
接口稳定、实现方在独立jar里、框架愿意自己做多实现筛选，这类场景SPI仍然合适。JDBC驱动、ES和Kafka插件都是典型用法。
原生SPI有三条硬局限：
- 不能按名字直接取实现，只能迭代后自己筛
- 没有优先级和条件激活，多个实现共存时框架得另写规则
- 只负责**
new**对象，不做依赖注入，实现类里要用别的Bean得自己想办法
希望这篇文章能帮到你。
参考内容
- Java SE ServiceLoader 文档
- JDBC 4.0 驱动自动加载说明
- Dubbo ExtensionLoader 扩展机制
)
