在Java生态中，我们经常遇到这样的需求：定义一个接口，然后由不同的厂商或模块提供各自的实现，主程序在运行时根据配置或环境自动找到并加载这些实现。比如MySQL、Oracle的JDBC驱动，SLF4J对接不同日志实现，都是典型的场景。支撑这一切的底层机制就是SPI（Service Provider Interface），它是JDK从1.6开始内置的服务发现标准。理解SPI的工作原理，不仅能让你明白JDK众多扩展点的设计思路，也能为阅读Spring Boot、Dubbo等框架的源码打下基础。
什么是SPI：接口与实现的解耦约定
SPI的全称是Service Provider Interface，它与API的概念相对应。API是接口的定义者提供能力给调用方使用，调用方依赖接口完成功能；而SPI是接口的调用方定义规范，由第三方提供实现，最终由框架或主程序在运行时发现并加载实现。简单说，API是“你实现接口我来调用”，SPI是“我定义规范你来实现，我来发现你”。
举个例子，JDK定义了java.sql.Driver接口，但JDK本身并不实现具体的数据库连接逻辑，而是由各数据库厂商提供驱动包。我们写Class.forName("com.mysql.jdbc.Driver")的时代早已过去，现在的JDBC 4.0之后，直接调用DriverManager.getConnection()就能工作，背后正是SPI在自动扫描并注册驱动。
使用SPI需要遵守一套固定的约定：在工程的资源目录下创建META-INF/services文件夹，以接口的全限定名作为文件名创建一个文本文件，文件内容是实现类的全限定名，每行一个。目录结构如下：
src
└── main
└── resources
└── META-INF
└── services
└── com.example.PaymentService
// 文件内容：com.example.AliPayService
// com.example.WechatPayService只要遵守这个约定，主程序通过ServiceLoader就能拿到所有实现，完全不需要硬编码任何实现类名，实现了接口与实现的彻底解耦。
ServiceLoader核心源码解析
java.util.ServiceLoader是SPI的核心入口，它实现了Iterable接口，因此可以直接用for-each循环遍历所有实现。我们先看一个基本用法：
ServiceLoader<PaymentService> loader = ServiceLoader.load(PaymentService.class);
for (PaymentService service : loader) {
service.pay(100);
}ServiceLoader.load()内部其实做了两件事：一是获取当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()），二是创建一个LazyIterator。注意这里的关键词“Lazy”，说明SPI的加载是懒加载的，也就是遍历到某个实现时才会真正去实例化它，而不是调用load()时就把所有实现类都创建出来。
LazyIterator的hasNext()方法会去拼接资源文件路径。源码中的核心逻辑是：META-INF/services/ + 接口全限定名，然后调用类加载器的getResources()方法查找所有匹配的资源文件。这里用getResources()而不是getResource()是有讲究的，前者会返回Enumeration，能找到类路径上多个jar包中同名的配置文件，这也是SPI能聚合多个提供者的关键。
找到文件后，next()方法会解析文件内容，按行读取实现类名，通过Class.forName()加载类，再调用newInstance()创建实例。因此SPI有一个隐含要求：实现类必须有无参构造器，否则会抛出ServiceConfigurationError。整个流程可以概括为：读取配置文件、反射加载类、反射实例化、缓存到内部providers集合，下次遍历优先从缓存取。
还有一个容易被忽略的细节是类加载器的选择。因为ServiceLoader位于核心库，由启动类加载器加载，而第三方实现类在应用类路径上，如果直接用它自己的类加载器去找实现类是找不到的。JDK通过线程上下文类加载器巧妙地解决了这个“父加载器无法访问子加载器类”的问题，这也是JDBC等核心API能加载厂商驱动的根本原因。
原生SPI的缺陷与增强方案
原生SPI虽然简单好用，但在生产级框架中暴露出不少问题。第一，它只能全量遍历，无法按名称或条件精确加载某一个实现，即使只需要A实现，B和C也会被实例化，造成资源浪费。第二，实例化通过newInstance()完成，意味着实现类不能有构造器依赖注入，与Spring等容器天然不兼容。第三，ServiceLoader本身不是线程安全的，多线程同时遍历可能出现重复实例化。第四，加载失败时异常信息不够友好，排查问题比较困难。
正因如此，主流框架都在原生SPI基础上做了增强。Dubbo的SPI借鉴了JDK的设计，但支持通过键值对形式给实现命名，可以用ExtensionLoader.getExtension("alipay")精确加载指定实现，还实现了IOC和AOP能力，能对扩展点自动装配依赖。Spring Boot的自动装配则把配置文件换成了META-INF/spring.factories和后来的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，由SpringFactoriesLoader负责加载，并配合注解实现条件装配。
在实际项目中，如果只是简单的插件化场景，直接用JDK SPI就够了，零依赖且稳定；如果需要动态选择实现、依赖注入或者扩展点复杂，建议参考Dubbo的思路，通过键值对配置加上缓存机制自己实现一个轻量的ServiceLoader，或者直接引入现成框架。无论哪种方式，理解META-INF/services约定和懒加载迭代器的原理，都是掌握Java服务发现机制的基石。