这事要从面试聊起。Java的SPI机制Service Provider Interface经常被当成一道八股题但真正把它用明白的人并不多。它解决的问题很明确框架定义好了一套扩展接口第三方可以在运行时被自动发现和加载业务代码里既看不到new关键字的硬编码也不需要把所有实现类硬凑到一个注册中心只需要在classpath下放一个文本文件JDK里的ServiceLoader就会按约定把实现找出来并实例化。对于看框架源码的中高级Java开发、准备面试的人、以及要设计公共模块的架构师来说掌握SPI等于掌握了一把打开JDBC驱动加载、Spring自动装配、Dubbo扩展点这些源码的钥匙。这篇文章不绕弯从原理、手写案例到避坑经验一次讲透。1. SPI到底解决什么问题面试和源码屡次碰到1.1 没有SPI的日子我们是怎么被耦合拖垮的假设现在要给一个老业务系统接多家消息发送渠道。最开始你设计了MessageSender接口然后AliYunSender、TencentSender各写一个实现类。业务侧怎么选择常规做法是写一个工厂public class MessageSenderFactory { public static MessageSender create(String channel) { if (ali.equals(channel)) { return new AliYunSender(); } if (tencent.equals(channel)) { return new TencentSender(); } throw new IllegalArgumentException(unknown channel); } }这段代码看起来没毛病但问题会在你接入第三个、第四个渠道时暴露每来一个新厂商你都要改动工厂类重新编译、重新发版甚至因为打包配置把某个渠道的依赖抖错线上直接起不来。核心业务代码里全是渠道细节接口的提供方和实现方被硬编码绑定在一起这还不是最头疼的。更麻烦的是如果某个实现类需要初始化一堆资源、注册一堆回调所有逻辑都要堆在工厂的create方法里工厂会越写越臃肿最后变成谁都看不懂的上帝类。SPI就是为了解决这个接口与实现解耦的问题而存在的。它的核心思想是把选择哪个实现这件事从代码挪到classpath上的一个配置文件中框架本身只负责按约定扫描和实例化业务开发者不再需要关心具体类名。换句话说扩展能力从改代码变成了加jar包这是插件化架构的基础。1.2 SPI、API、服务发现别再把概念混在一起很多人在简历上写熟悉Java SPI机制但被问和API有什么区别就卡住了。两者的关注点完全不同。APIApplication Programming Interface是功能提供方给出的一套调用接口使用方直接调用它们例如List、Map。提供方掌握契约调用方写死依赖它。SPIService Provider Interface恰好反过来是框架、JDK制定了一套扩展契约真正干活的实现由第三方提供框架在运行时通过配置文件去发现具体实现。契约在框架手里执行在外部实现方手里调用方通常是无感的。服务发现Service Discovery是更通用的概念SPI是Java平台上的服务发现实现方式META-INF/services配置文件就是服务注册表。有个更通俗的类比SPI像插座标准。插座孔的形状和电压是国家标准接口契约谁家生产的插头供应商实现只要符合标准都能插上去用标准的发布方并不需要认识每一个插头厂商各家厂商把符合标准的产品放到货架上配置文件用户框架按标准去找货架就能买到对应商品。JDBC就是这个类比的最佳实例后面会细说。2. Java SPI规范与核心实现原理2.1 SPI的三件套约定标准Java SPI的运作有三个核心组成部分。第一必须有一个确定的接口或抽象类它是整个扩展的契约。第二必须有若干实现类且实现类在Java标准实现中必须提供一个无参构造方法因为ServiceLoader默认通过反射调用无参构造进行实例化如果构造方法有参加载时会直接抛异常。第三也是最容易被忽略却最强的约定必须在classpath下的META-INF/services目录里创建一个文本文件文件名必须是接口的全限定名文件内容则是实现类的全限定名一行一个。比如META-INF/services/com.example.spi.MessageSender文件内容com.example.spi.aliyun.AliYunSender com.example.spi.tencent.TencentSender这就是所谓的约定优于配置。它不需要你写任何额外的注册代码只需要把jar包放进classpath并保证配置文件在jar包的对应路径下即可。之所以强调最终jar包是因为很多人在IDE里跑得好好的一打出来就找不到实现大概率是配置文件没有被打进META-INF/services根路径。2.2 ServiceLoader源码流程一步步拆开看JDK官方提供的java.util.ServiceLoader就是SPI机制的门面。它的工作流程大致三步。第一步构造阶段ServiceLoader.load(MessageSender.class)会确定使用哪个类加载器去扫描本质上是按META-INF/services/接口全限定名这个路径去读取资源。如果没有显式传入类加载器它使用线程上下文类加载器。第二步懒加载阶段调用iterator()或forEach时才开始真正读取配置。读取到一行实现类名后通过Class.forName(className, true, loader)完成类加载再反射调用无参构造实例化。注意这一步是懒加载load()本身并不会立即实例化任何对象如果配置文件里没有内容甚至不会报错。第三步缓存与迭代阶段同一个ServiceLoader实例内部维护了一个providers缓存同一个实例遍历两次实现类只会被实例化一次。但如果你每次调用ServiceLoader.load()都新建一个实例前面的缓存就失效了配置会被重新读取、对象会被重新创建。这个细节在性能优化部分非常关键。2.3 双亲委派之外的另一条路线程上下文类加载器这是SPI机制真正有深度的部分也是面试官最爱追问的方向。Java的类加载遵循双亲委派模型一个类加载器收到加载请求后先交给父加载器父加载器处理不了才自己加载。这套模型保证了Object、String这些基础类不会被用户篡改。但SPI场景天然和双亲委派冲突。拿JDBC举例DriverManager是JDK核心库里的类由启动类加载器加载理论上它不可能去加载MySQL、PostgreSQL这些第三方厂商提供的Driver实现类因为启动类加载器搜索路径里根本不存在这些第三方jar包。为了解决这个问题JDK引入了线程上下文类加载器。Thread.currentThread().getContextClassLoader()默认是应用程序类加载器它能看见classpath上的所有第三方jar。ServiceLoader.load(Driver.class)内部使用的就是这个类加载器从而让核心库能够倒挂去加载外部实现。这就是SPI打破双亲委派的本质。回答为什么SPI要破坏双亲委派时把驱动加载场景从头到尾讲一遍面试官基本不会再为难你。3. 从零手写一个完整可运行的SPI示例3.1 定义扩展接口与两个实现类理论讲再多不如亲手跑通一次。下面这个示例基于普通Maven项目即可运行不需要Spring不需要任何第三方依赖。先定义支付渠道接口PayServicepackage com.example.spi; import java.math.BigDecimal; public interface PayService { String channelName(); boolean pay(BigDecimal amount); }然后定义两个实现类。为了模拟真实插件场景把实现类放在不同的子包中并且都提供无参构造package com.example.spi.impl; import com.example.spi.PayService; import java.math.BigDecimal; public class AlipayService implements PayService { Override public String channelName() { return alipay; } Override public boolean pay(BigDecimal amount) { System.out.println(使用支付宝支付 amount); return true; } }WechatPayService的写法几乎一样只是渠道名改成wechat输出内容改为微信支付。要注意如果实现类有带参构造比如通过构造器注入渠道配置标准SPI默认机制是支持不了的需要配合自定义初始化逻辑或者改用增强版SPI这点后面避坑部分详谈。3.2 正确创建META-INF/services配置文件打开src/main/resources目录手动创建META-INF/services文件夹然后在里面新建一个文件名完全等于接口全限定名的文本文件com.example.spi.PayService。文件内容如下com.example.spi.impl.AlipayService com.example.spi.impl.WechatPayService注意几个细节路径必须是META-INF/services不能再套一层额外的目录文件名是接口全限定名不是实现类名内容每行一个实现类全限定名不能有包路径前缀不能写class关键字。这里再多说一句有些IDE或编辑器默认会往文件头写入BOM头或者行尾残留空格。BOM和空格在SPI配置解析时都可能造成ClassNotFoundException或provider not found的诡异问题。建议把配置文件的编码固定为UTF-8无BOM写完顺便看一眼行尾有没有多余空白字符。尤其在使用Windows记事本时保存UTF-8编码默认会带上BOM这个坑我踩过不止一次。3.3 用ServiceLoader加载并运行客户端代码非常简单package com.example.spi.client; import com.example.spi.PayService; import java.math.BigDecimal; import java.util.ServiceLoader; public class PayClient { public static void main(String[] args) { ServiceLoaderPayService loader ServiceLoader.load(PayService.class); for (PayService payService : loader) { System.out.println(发现渠道: payService.channelName()); payService.pay(new BigDecimal(199.00)); } } }运行main方法后控制台会按配置文件的顺序输出两个渠道的信息。如果只希望接入其中一个渠道把配置文件里的对应行删掉客户端代码一行都不用改。这就是SPI加实现不加代码、删实现不改逻辑的精髓。我建议把这个demo放到一个独立的小工程里之后读JDBC源码或者看Dubbo扩展点实现时可以随时拿它做对照实验会比你孤立看源码记忆深刻得多。还可以顺手试一下把配置文件里的实现类全限定名故意改成不存在的类观察异常类型和堆栈这对排查生产问题很有帮助。4. 框架和中间件是如何基于SPI实践的4.1 JDBC你从第一行Java代码开始就在用SPIJDBC是Java标准库中SPI最经典的应用。JDBC 4.0之前开发者必须手写Class.forName(com.mysql.cj.jdbc.Driver)把驱动类注册到DriverManager。这一步本质上是把驱动实现类硬编码进业务代码。JDBC 4.0之后驱动jar包只需在META-INF/services/java.sql.Driver文件中声明实现类DriverManager在静态初始化阶段就会通过ServiceLoader.load(Driver.class)自动发现并注册所有可见驱动。细看DriverManager源码就能发现它在loadInitialDrivers()中读取配置文件然后迭代Driver接口的实现当Connection创建时再根据URL判断该交给哪个driver。这里出现了一个关键问题java.sql.Driver属于JDK核心模块而MySQL驱动是第三方jar里的类核心模块的类加载器根本不认识它。所以ServiceLoader.load(Driver.class)默认使用线程上下文类加载器把第三方实现从classpath上拉起来。你平时只写一行DriverManager.getConnection(url)就能连上数据库背后就是这套SPI加载逻辑在工作。这个案例也解释了为什么很多老项目里有Class.forName(com.mysql.jdbc.Driver)这行看似冗余的代码。它在JDBC 4.0之前是必须的现在则完全没必要。如果你在代码审计中看到这种写法可以顺手和同事聊聊历史演进这也是个不错的面试题切入点。4.2 SLF4J门面与实现的约定式绑定SLF4J被广泛使用的核心原则是日志API与日志实现解耦。你引入slf4j-api后代码里统一用LoggerFactory.getLogger打日志但实际输出到控制台还是输出到文件取决于classpath里放的是logback-classic、slf4j-simple还是其他binding。SLF4J 2.0版本已经全面切换到java.util.ServiceLoader风格的服务查找早期版本则是通过约定去查找StaticLoggerBinder这类固定名称的类。理解这个场景的关键是日志框架本身就是一类SPI思想的应用。你在编译期只依赖slf4j-api运行时才通过classpath发现具体实现如果没有配置binding日志会输出一条无法找到binding的警告。反过来说明SPI机制把用哪个实现的决策完全推迟到了运行时让依赖关系从编译期硬绑定变成了运行期软绑定。4.3 从标准SPI走向Spring与Dubbo的增强版JDK SPI是零依赖的原始方案但它有几个局限性只能按接口全量加载所有实现无法按名称精确获取某一个不能对实现注入依赖配置文件格式简单不支持额外参数。正因为这些短板Spring和Dubbo分别做了增强。Spring Boot的META-INF/spring.factories与SpringFactoriesLoader本质上就是SPI扩容配置文件支持keyvalue形式Spring根据EnableAutoConfiguration等key批量加载候选类再通过条件装配决定哪些真正生效。你在项目里加一个DataSourceAutoConfiguration时并不需要手动注册Spring Boot自动配置就是靠这套机制扫描出来的。Dubbo更直接把配置文件从固定的META-INF/services扩展到了META-INF/dubbo并支持按key区分实现wechatcom.example.spi.impl.WechatPayService alipaycom.example.spi.impl.AlipayService配合SPI注解后框架内可以通过参数动态指定需要哪个实现比如extensionLoader.getExtension(wechat)。这套设计解决了JDK SPI全量加载、无法选择的痛点也是Dubbo扩展点体系的核心基础。读完这个对比你会发现JDK SPI是地基Spring和Dubbo是在地基上盖的房子。5. 实战中的坑一次讲个够5.1 加载不到实现先从配置文件四要素排查我自己在写中间件时遇到SPI加载不出来第一反应不是怀疑类加载器而是检查四件事接口全限定名是否写错、META-INF/services路径是否正确、实现类全限定名是否完整、配置文件是否存在于最终打出的jar包里。这四件事里任何一件出问题表现都是静默不加载或者抛ClassNotFoundException。这里分享两个很实际的排查手段。第一编译后直接解压看产物。在Maven项目里执行mvn package之后到target/classes/META-INF/services确认一下配置文件有没有生成如果被其他工具二次处理过再用jar tf xxx.jar确认配置文件确实在jar包的META-INF/services根路径下。第二在代码里临时输出加载到的类信息比如遍历ServiceLoader时打印每个元素的getClass().getName()一旦发现某个实现始终不出现优先怀疑配置文件的类名写错了。配置文件内容一行出现多个类、出现包名点号错误都会导致加载失败。5.2 多个实现顺序不可控业务别依赖顺序SPI规范没有规定配置文件内容的加载顺序实现类的迭代顺序在不同版本JDK、不同打包方式下可能完全不同。JDK8的实现逻辑是扫描classpath下的资源和jar顺序这会导致你在本地正常、部署到容器后顺序翻转的情况。如果哪个二把刀把默认实现寄托在配置文件的第一行上生产环境迟早给他上一课。如果业务逻辑依赖第一个实现是默认实现那就危险了。我的建议是要么配置文件里只保留一个默认实现把具体选择逻辑放到增强SPI或自定义service loader中要么启动时把所有实现加载到一个MapString, 接口按渠道名精确查找而不是依赖遍历顺序。看过Dubbo源码的话会发现它不依赖配置文件顺序而是通过key取值这就是对JDK SPI顺序坑的典型规避。5.3 ServiceLoader不是全局单例性能问题不能忽视分布式系统里性能优化的第一优先级往往是减少重复创建。ServiceLoader.load()返回的是新对象每次遍历还会重新解析文件、重新反射实例化。如果你在热门调用路径上每次请求都ServiceLoader.load()性能损耗虽然绝对值不算大但完全没必要而且会给后续排查带来干扰。正确的做法是在应用启动阶段做一次加载把结果缓存到本地静态集合private static final MapString, PayService PAY_SERVICES new ConcurrentHashMap(); static { ServiceLoaderPayService loader ServiceLoader.load(PayService.class); for (PayService service : loader) { PAY_SERVICES.putIfAbsent(service.channelName(), service); } }这样做同时解决了按名选择的问题。需要说明的是同一个ServiceLoader实例的内部缓存是有效的所以如果你只遍历一次并保存引用性能问题不大但每次新建实例就会重新扫描。把这块理解清楚面试被追问SPI性能如何优化时才能答到点子上。5.4 多ClassLoader与模块化场景坑更隐蔽在Web容器或OSGi这类多类加载器环境中每个应用都可能有自己的类加载器META-INF/services资源的可见性取决于线程上下文类加载器。如果你在框架线程里加载SPI而框架线程的上下文类加载器不是应用类加载器就可能出现明明jar在classpath上却加载不到实现的问题。Java 9引入模块系统后SPI还有一种更正式的写法在module-info.java里用provides声明提供方、用uses声明使用方服务加载时能感知模块边界。不过实际项目中绝大多数场景依然沿用META-INF/services这种classpath方式两者在模块化项目里可以共存但需要仔细确认服务绑定是否真的生效。这张速查表基本涵盖了我遇到过的典型问题现象可能原因解决方案ServiceConfigurationError提示not a subtype配置文件点错实现类检查类名、接口继承关系ClassNotFoundException实现jar未引入、类名拼错、文件有BOM引入依赖修正配置去BOM屡次加载却拿不到实现文件名/路径不对用jar tf检查产物SLF4J启动报无法找到bindingclasspath缺少日志实现加入logback等binding实现顺序不稳定扫描顺序不确定不依赖顺序改为map按key取每次调用都重新创建实例每次新建ServiceLoader启动时缓存Provider6. 我的使用心得与进阶建议接触SPI机制久了我越来越觉得它本质是一种插件化思维。JDK SPI本身很简单真正考验人的是在什么场景下选择什么级别的扩展方案。如果你写的只是一个普通业务模块两三套实现靠接口加工厂就够用了强行引入SPI反而让代码难跟踪如果你在写公共库、中间件、框架底层标准SPI是零依赖的最优解加上Spring的SpringFactoriesLoader就能做得更舒服如果还需要按名称选择、条件加载、依赖注入那就直接考虑Dubbo SPI这类增强实现。最后分享一个非常实用的小技巧读Spring Boot自动装配源码时先看META-INF/spring.factories里的key再反查SpringFactoriesLoader再对比JDK的ServiceLoader源码三者对照着看你对配置驱动扩展的理解会瞬间上一个台阶。等到面试被问到SPI线程上下文类加载器或者JDBC驱动加载流程你会发现这些问题不再是一段八股文而是你平日里亲手验证过的东西。