在Java中SPI机制是什么_Java服务发现原理解析

SPI是JDK自带的运行时自动查找接口实现类机制，依赖ServiceLoader和META-INF/services/配置文件；常见问题包括类加载器不匹配、配置路径/格式错误、懒加载导致异常延迟暴露及跨类加载器失效。

SPI 就是运行时自动找接口实现类的机制，靠 ServiceLoader + META-INF/services/ 配置文件驱动，不是“框架功能”，而是 JDK 自带的底层能力。

为什么 ServiceLoader.load(X.class) 找不到你的实现类？

这是最常卡住的地方：它不报错，但迭代器为空。根本原因不是代码写错了，而是类路径和加载时机没对上。

• ServiceLoader 默认用当前线程的上下文类加载器（Thread.currentThread().getContextClassLoader()），不是你直觉里的“当前类的类加载器”
• 如果在 Web 容器（如 Tomcat）或 Spring Boot 启动早期调用，getContextClassLoader() 可能指向 AppClassLoader，而你的 SPI 实现 jar 包实际由 WebappClassLoader 加载 —— 类加载器隔离导致找不到
• 配置文件名必须是接口全限定名，比如接口是 com.example.LogService，文件路径必须是 META-INF/services/com.example.LogService，内容只能写一行：实现类全名（如 com.example.Slf4jLogService），末尾不能有空格或换行
• 配置文件必须在 resources 目录下，且打包后要真实出现在 jar 的根路径里；IDE 中若用 Maven 多模块，确保 spi-impl 模块的 resources 被正确包含进最终 jar

ServiceLoader 是懒加载，别在 for 循环外就假设对象已创建

它内部用 LazyIterator，只有调用 iterator.hasNext() 或 next() 时才真正尝试加载、实例化类。这意味着：

• 异常不会在 load() 时抛出，而是在遍历时才暴露 —— 比如 ClassNotFoundException、NoClassDefFoundError 或构造函数抛异常
• 如果你只调用 serviceLoader.iterator() 却没遍历，什么都不会发生，也不会缓存任何实例
• 每次调用 iterator() 都会新建一个迭代器，重复解析配置文件、重复反射创建对象；不要把它当单例缓存使用

JDBC 驱动是 SPI 最典型的“反直觉”案例

你从没显式调用 ServiceLoader.load(Driver.class)，但 DriverManager.getConnection() 内部用了它 —— 这就是为什么加了 mysql-connector-java 依赖就能连 MySQL，不用手动 Class.forName("com.mysql.cj.jdbc.Driver")（老写法）。

• MySQL 8+ 的驱动 jar 包里自带 META-INF/services/java.sql.Driver，内容是 com.mysql.cj.jdbc.Driver
• DriverManager 在静态块中调用 ServiceLoader.load(Driver.class)，一启动就扫描所有实现
• 注意：JDBC 规范要求驱动类必须有无参构造函数，且需在构造时向 DriverManager 注册自己 —— 这是 SPI 之外的额外契约，不是所有 SPI 接口都这样

Spring Boot 的 spring.factories 不是原生 SPI，但思路同源

它模仿了 SPI 的“外部配置驱动加载”思想，但实现完全独立：SpringFactoriesLoader 专门读取 META-INF/spring.factories，支持键值对（如 org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.MyAutoConfig），还能按 key 分组、支持条件化加载。

• 别指望把 spring.factories 放到 META-INF/services/ 下让 ServiceLoader 识别 —— 它俩文件路径、格式、加载逻辑都不同
• 如果你在写 SDK，想兼容 Spring Boot 自动装配，就得同时提供 spring.factories；想被通用 Java 环境识别，才需要标准 SPI 配置
• Dubbo 的 SPI 更进一步：支持 @SPI 注解定义默认实现、@Adaptive 动态代理、加载顺序控制 —— 原生 ServiceLoader 连“优先级”“别名”都没有

真正容易被忽略的是类加载器边界问题：SPI 的“解耦”只在代码层面成立，一旦跨了类加载器（比如 OSGi、Tomcat 多应用、JRebel 热替换），ServiceLo

ader 就失效了 —— 它不会跨加载器搜索，也不会帮你做类委托。这时候要么统一类加载策略，要么换用更可控的加载方式（如手动 Class.forName(name, true, loader)）。