第1章 认识SPI机制与模块边界：接口定义、服务发现、实现解耦
1.1 SPI是什么——从服务提供者接口说起
SPI（Service Provider Interface）是Java提供的一种服务发现与加载机制，它允许第三方为某个接口提供实现类，并在运行时由框架自动发现并加载。其核心思想是：接口定义与实现分离，调用者只依赖接口，实现类通过约定方式注册。
一句话理解：SPI就是Java原生的“插件”机制——你写好接口，别人写好实现，然后把实现类的全限定名写到一个配置文件中，框架启动时自动扫描并加载。
1.2 模块边界与解耦收益
在传统硬编码依赖中，调用方直接`new`一个实现类，导致编译期强耦合。SPI通过以下两层边界实现松耦合：
- 接口边界：调用方只依赖接口，不依赖任何实现类；
- 发现边界：实现类通过META-INF/services/下的配置文件暴露自己，而非通过代码导入。
这种架构带来的收益：
- 实现类可独立扩展（新增一个jar包即可）；
- 调用方无需修改代码；
- 模块间仅通过接口通信，便于单元测试和替换。
1.3 核心接口与规范
| 组件 | 角色 | 说明 |
|---|---|---|
java.util.ServiceLoader | 服务加载器 | JDK内置的SPI加载工具，会扫描所有jar包中 META-INF/services/<接口全限定名> 文件 |
| 接口（Interface） | 服务契约 | 调用方与提供方共同遵守的抽象类型 |
| 实现类 | 服务提供者 | 实现该接口的具体类，必须有无参构造器 |
| 配置文件 | 服务注册表 | 文件名 = 接口全限定名，内容为一行一个实现类全限定名 |
1.4 SPI工作流程
下图展示了最简SPI机制的完整调用链路：
1.5 代码实战：最简SPI示例
第1步：定义接口
// GreetingService.java
public interface GreetingService {
String greet(String name);
}第2步：编写实现类（放在单独模块或同模块但不出口）
// EnglishGreeting.java
public class EnglishGreeting implements GreetingService {
@Override
public String greet(String name) {
return "Hello, " + name;
}
}
// ChineseGreeting.java
public class ChineseGreeting implements GreetingService {
@Override
public String greet(String name) {
return "你好，" + name;
}
}第3步：创建配置文件
在src/main/resources/META-INF/services/目录下，创建以接口全限定名命名的文件：
# 文件名：com.example.GreetingService
# 文件内容（每行一个实现类全限定名）：
com.example.impl.EnglishGreeting
com.example.impl.ChineseGreeting第4步：客户端使用ServiceLoader加载
// Main.java
import java.util.ServiceLoader;
public class Main {
public static void main(String[] args) {
// 加载所有GreetingService实现
ServiceLoader<GreetingService> loader = ServiceLoader.load(GreetingService.class);
for (GreetingService service : loader) {
System.out.println(service.greet("World"));
}
}
}第5步：编译与运行
# 编译所有Java源文件（假设都在src下）
javac -d build src/com/example/GreetingService.java src/com/example/impl/*.java src/Main.java
# 将资源文件复制到build目录（重要！）
cp -r src/META-INF build/
# 运行
java -cp build Main输出结果（顺序可能依文件内容打印）：
Hello, World
你好，World
关键点：运行时需要确保
META-INF/services/com.example.GreetingService文件在classpath中。如果使用IDE，通常会自动复制资源文件，但命令行构建时必须手动处理。
1.6 调试要点与常见错误
- 未找到实现类：抛出
ClassNotFoundException。检查配置文件中类名是否拼写正确、包名完整、编译后class文件是否在classpath下。 - 零个提供者：for循环直接跳过，没有任何输出。此时应检查
META-INF/services目录是否存在、文件名是否与接口全限定名完全一致（包括大小写）。 - 多实现类顺序不可控：配置文件中的行顺序决定了加载顺序，如果依赖特定顺序，可考虑使用
@Order注解（需要额外机制）。 - 构造函数异常：SPI要求实现类有无参构造器，否则会抛出
InstantiationException。
1.7 性能与稳定性优化要点
| 关注点 | 说明 | 优化建议 |
|---|---|---|
| 懒加载 | ServiceLoader默认惰性迭代，只有在调用iterator.next()时才真正加载类 | 无需额外配置，但尽量避免遍历全部实现而只取第一个 |
| 类加载隔离 | SPI使用调用者的ClassLoader加载实现类，在多模块ClassLoader场景下可能找不到 | 显式指定ClassLoader：ServiceLoader.load(Interface.class, customClassLoader) |
| 实现类缓存 | 每次调用loader.iterator()都会重新读取配置文件并实例化 | 自行缓存List<T>结果，或使用ServiceLoader::stream()获取提供者懒加载描述 |
| 并发安全 | ServiceLoader迭代器不是线程安全的 | 在多线程场景下，先一次性加载到本地集合再使用 |
注意：SPI机制本身不依赖任何第三方库，但实际生产中常与Spring结合使用。Spring的
@Autowired + spring.factories 本质上是更高级的SPI变体。理解原生SPI有助于理解大型框架的自动装配原理。
1.8 本章小结
- SPI通过接口 + 配置文件 + ServiceLoader实现模块边界与解耦。
- 实现类无需被客户端代码显式导入，只需符合约定即能被自动发现。
- 配置文件路径固定：
META-INF/services/<接口全限定名>，内容为行分隔的实现类全限定名。 - 调试时重点检查：文件名是否准确、类是否在classpath、是否提供无参构造器。
- 性能上采用懒加载，但注意迭代器非线程安全，多线程场景需自行同步或预加载。