很多 Java 开发者学完基础后会陷入一个尴尬期写业务代码得心应手但一看框架源码就各种“这谁啊”“这哪来的”。尤其是当你第一次在 Spring Boot 的自动配置里看到META-INF/spring.factories、在 JDBC 连接数据库时看到META-INF/services/com.mysql.cj.jdbc.Driver这种文件时大概率是一脸懵的。这些文件背后藏着一个贯穿整个 Java 生态的底层机制——SPIService Provider Interface服务提供者接口。我最初接触 SPI 时也不太重视觉得无非就是“配置一下接口实现类”。直到后来自己写中间件、做可插拔模块设计时被逼着去手撸了一遍 ServiceLoader才意识到这东西远不止“配置”那么简单。它关系到 ClassLoader 的加载逻辑、框架的解耦设计、以及 Java 模块化体系下的服务发现规则。这篇文章我就想把这个机制彻底拆开从最朴素的问题入手一路讲到源码、真实案例和手写实现希望能帮你把这块短板补上。1. 从“代码里写死”到“运行时发现”SPI 解决的到底是什么问题在讲 SPI 之前得先看一个大家都会遇到的场景你的业务系统里有一套日志输出逻辑最初你直接把实现类写死在代码里。后来需求变了要换成另一个实现你还能改代码重新编译。但如果这个系统已经打包上线或者这段代码在别人给的 jar 包里呢你是去改 jar 包吗显然不行。这就是写死依赖的痛点调用方和实现方被硬绑定在一起任何一方变动都要重新编译、重新部署更别提扩展第三方实现时的痛苦。1.1 一个最简单的接口多实现需求假设有一个支付接口public interface Payment { void pay(BigDecimal amount); }某公司 A 用了支付宝实现公司 B 用了微信支付实现。如果两边都要在一套系统里用早期的做法是搞一个策略工厂通过配置项去判断创建哪个实现代码大概是这种风格public class PaymentFactory { public static Payment create() { String type Config.getInstance().get(payment.type); if (alipay.equals(type)) { return new AlipayPayment(); } else if (wechat.equals(type)) { return new WechatPayment(); } throw new IllegalArgumentException(unsupported type: type); } }这种写法能解决基本切换问题但每增加一种支付方式你都要改动这个工厂类重新发版。从这里开始很多人会引入“反射 配置”的方案先读配置里的类名再Class.forName()加载并实例化。这比原来的if/else灵活不少本质上已经接近 SPI 的思路了。1.2 从 Class.forName 到服务发现协议Class.forName()的好处是类名可以完全由配置决定所以只要配置文件不改代码就永远不用动。但问题也随之而来类名散落在各种不同的配置文件里格式五花八门谁来加载、加载顺序是什么、怎么处理加载失败全靠自己写。SPI 的出现就是把这件事标准化了。它约定了一套规则调用方定义接口或抽象类但不关心实现类是谁。实现方在自己的 jar 包中以固定路径META-INF/services/接口全限定名放一个文件文件内容是实现类的全限定名。调用方通过java.util.ServiceLoader统一加载所有可用的实现。这样做的好处是接口与实现彻底解耦。系统里有哪些实现、想启用哪个实现不再需要通过改代码来调整而是通过放入或移除 jar 包来完成。这也就是“插件化开发”的本源思路之一。1.3 SPI 和 API 的本质区别谁在写规则、谁在找人在学习 SPI 时最绕的一个概念是它与 API 的区别。我平时给伙伴们解释时习惯用“点菜”来打比方API 场景餐厅调用方要求所有供应商实现方必须按照餐厅定好的菜谱和餐具规格来提供菜品。规则由调用方定实现方照着做。SPI 场景插座接口是标准化的电器厂商实现方按插座标准生产各类电器而用户调用方自己决定插哪个电器的插头上去。规则由实现方或第三方扩展调用方只留了一个标准的接入点。对应到代码层面API 中接口是主控方主动声明并调用的实现方必须依赖这个接口而 SPI 中接口是标准制定方声明的调用方只负责“发现”实现方至于实现方是谁、有多少个运行时才知道。这里有个容易被忽略的点SPI 带来灵活性的同时也意味着调用方要付出“未知”的代价——因为你不知道运行时到底会加载到哪些实现所以必须对所有可选实现的行为有预判否则可能出现诡异的问题。这算是一个哲学层面的权衡后面踩坑部分我还会提到。2. 深入 ServiceLoader 源码它到底是怎么找到那些实现的理解了 SPI 的思想接下来就要看官方实现java.util.ServiceLoader了。它从 JDK 1.6 就开始提供直到今天Java 模块化JPMS之后依然在使用。我当初阅读它的源码时最大的感受是这玩意儿核心逻辑极其简单但完全读懂后你对 ClassLoader 的理解会上一个台阶。2.1 从入口方法看整个加载流程ServiceLoader 的用法非常简单ServiceLoaderPayment loader ServiceLoader.load(Payment.class); for (Payment payment : loader) { // 遍历所有实现 }load的完整签名是public static S ServiceLoaderS load(ClassS service) { ClassLoader cl Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); }这里有个很关键的细节它默认用的是线程上下文类加载器Thread Context ClassLoader而不是当前类的类加载器。为什么要这么设计等会儿在讲 JDBC 案例时我会详细解释这里先记住这个结论。再看一下load(service, cl)内部做的事public static S ServiceLoaderS load(ClassS service, ClassLoader loader) { return new ServiceLoader(service, loader); }构造函数里最关键的一步是这段private ServiceLoader(ClassS svc, ClassLoader cl) { service Objects.requireNonNull(svc, Service interface cannot be null); reload(); }而reload()做了两件事清了缓存、创建了一个懒加载的 LazyIteratorpublic void reload() { providers.clear(); lookupIterator new LazyIterator(service, loader); }也就是说调用 load 只是做了准备真正读取文件和实例化对象发生在你第一次迭代的时候。这就是 ServiceLoader 全链路懒加载的设计。2.2 LazyIterator读取配置、解析类名、反射创建LazyIterator 是 ServiceLoader 的一个内部类持有三个关键字段接口类型service、类加载器loader、以及一个默认的PendingIterator。看一下它的核心hasNextService()方法private boolean hasNextService() { if (nextName ! null) { return true; } if (configs null) { try { String fullName PREFIX service.getName(); if (loader null) { configs ClassLoader.getSystemResources(fullName); } else { configs loader.getResources(fullName); } } catch (IOException x) { fail(service, Error locating configuration files, x); } } while ((pending null) || !pending.hasNext()) { if (!configs.hasMoreElements()) { return false; } pending parse(service, configs.nextElement()); } nextName pending.next(); return true; }这里有一个非常重要的机制loader.getResources(fullName)不是获取一个资源而是遍历类加载器能见到的所有 jar 包找出全部匹配的配置文件。这也是为什么多个 jar 里都放了同一个服务接口的配置文件时ServiceLoader 能全部发现它们的原因。找到配置文件后parse方法逐行读取内容并把每行配置的类名存到 pending 列表中然后由nextService()去真正执行Class.forName和newInstanceprivate S nextService() { if (!hasNextService()) { throw new NoSuchElementException(); } String cn nextName; nextName null; Class? c null; try { c Class.forName(cn, false, loader); } catch (ClassNotFoundException x) { fail(service, Provider cn not found, x); } if (!service.isAssignableFrom(c)) { fail(service, Provider cn not a subtype, x); } try { S p service.cast(c.getDeclaredConstructor().newInstance()); providers.put(cn, p); return p; } catch (Throwable x) { fail(service, Provider cn could not be instantiated, x); } throw new Error(); }注意Class.forName(cn, false, loader)的第二个参数为false表示只加载类不执行静态初始化块。这一点跟Class.forName(cn)这种会触发初始化的写法不同是一个容易被忽略却很重要的细节。2.3 为什么 ServiceLoader 在循环里才真正干活我在第一次读源码时有个大疑问为什么不能像Map那样直接返回所有实例非要搞一个迭代器后来想明白了这是为了按需加载配置文件可能分布在多个 jar 里如果load()时就全部加载那么类加载耗时会翻好几倍还会拖慢 JVM 启动。有些实现类可能依赖于特定环境比如某个 jar 只在特定平台存在一次性加载容易造成其他环境启动失败。懒加载还能让调用方在遍历时自行控制流程想拿几个就拿几个不必一次拿完。这个设计思路在 JDK 里并不少见但很多人用循环遍历完后根本没有意识到这一点。如果你的需求是“拿一个就行了”可以这么写ServiceLoaderPayment loader ServiceLoader.load(Payment.class); for (Payment payment : loader) { // 第一个即是我们要的用完就 break executor.execute(payment); break; }因为底层是懒加载break 之后后续的类根本不会被加载和实例化效率是好的。3. 最经典的落地案例JDBC 驱动加载背后的 SPI 布局如果说只看理论还差点意思那 JDBC 驱动加载就是 SPI 在 JDK 生态里最标准的一次实践。你天天用DriverManager.getConnection()但大概率没认真看过它底层是怎么找到驱动类的。一段异常常见的代码:Class.forName(com.mysql.cj.jdbc.Driver); Connection conn DriverManager.getConnection(url, user, password);早期版本的 JDBC 需要手动Class.forName来加载驱动是因为DriverManager只能通过注册机制知道有哪些驱动。而到了 JDK 1.6 之后Class.forName这一行其实都可以不写了。驱动加载已经内置了 SPI 机制。在 MySQL 驱动包里你会发现这个文件mysql-connector-j-8.x.x.jar └── META-INF └── services └── java.sql.Driver文件内容大概是这样com.mysql.cj.jdbc.Driver打开DriverManager的源码在静态初始化块中有这段static { loadInitialDrivers(); println(JDBC DriverManager initialized); }而loadInitialDrivers()内部就是用 ServiceLoader 扫描java.sql.Driver这个接口的所有实现并一一暴露给DriverManagerServiceLoaderDriver loadedDrivers ServiceLoader.load(Driver.class); IteratorDriver driversIterator loadedDrivers.iterator();所以只要把驱动 jar 放到 classpath 里DriverManager就会自动发现驱动根本不需要Class.forName手动触达。这里有几个值得深入思考的点。3.1 为什么用线程上下文类加载器而不是启动类加载器java.sql.Driver接口定义在java.sql模块里这个模块属于 JDK 基础模块由启动类加载器Bootstrap ClassLoader负责加载。而 MySQL 驱动的实现类在外部 jar 里根本不在启动类加载器的加载范围里。如果 ServiceLoader 沿用“自己的类加载器”来加载配置就会面临一个问题启动类加载器找不到业务代码所在的 jar 包自然也就发现不了驱动实现。为了解决这种“基础模块需要调用外部实现”的困境JDK 引入了线程上下文类加载器作为桥梁。它默认是应用类加载器App ClassLoader能看到整个 classpath因此就能读到 mysql 驱动 jar 里的配置文件。这个机制是 SPI 机制中最容易让初学者混乱的地方。我这样记忆谁要加载外部实现谁就是调用方调用方如果自身由上层类加载器管辖就要通过线程上下文类加载器去“向下”借力。3.2 从 DriverManager 的注册表理解“动态发现”的价值DriverManager 内部维护了一个CopyOnWriteArrayListDriverInfo registeredDrivers列表。SPI 机制找到的驱动实例会自动添加进这个列表里。当用户通过getConnection(url, ...)时DriverManager 会遍历列表让每个驱动尝试连接。能连上就返回连不上则继续找下一个。这种做法的价值在于你的应用代码完全不感知具体驱动是谁、有几个。今天加一个新的数据库驱动 jar明天去掉旧的 jar应用代码一行都不用改。这种“插上就能用”的体验正是 SPI 为生态带来的核心价值。我在自己写中间件时也借鉴了这套逻辑把对接方定义为接口配置通过 SPI 暴露主程序里只依赖接口。实测下来扩展一个对接方只需要新增一个 jar主程序完全不用动非常省心。4. 手写一个极简 SPI 框架把 ServiceLoader 的脾气管教明白网上讲 SPI 的文章很多但大部分停留在“怎么用 ServiceLoader”这个层面。如果只是这样我敢说你过两周就忘光了。我自己的经验是手写一个简化版本的 ServiceLoader把核心逻辑走一遍你才能真正明白配置文件、接口、类加载、实例化之间是怎么协作的。这一章我会带你从零写一个迷你 SPI 加载器它不做完整健壮性处理但把核心机制体现到位可以加深理解。4.1 定义接口与两个实现类先声明一个插件接口比如一个消息推送接口public interface MessageSender { void send(String message); }然后写两个实现分别模拟短信推送和邮件推送public class SmsSender implements MessageSender { Override public void send(String message) { System.out.println([SMS] sending: message); } } public class EmailSender implements MessageSender { Override public void send(String message) { System.out.println([EMAIL] sending: message); } }在项目的resources目录下创建配置目录和文件src/main/resources/META-INF/services/ └── me.xxx.spi.demo.MessageSender文件内容me.xxx.spi.demo.SmsSender me.xxx.spi.demo.EmailSender注意文件名必须是接口的全限定名一个实现类一行不能有多个空行或注释JDK 原始实现不支持#注释我们这里简化处理。4.2 核心加载器的几个关键方法写一个MiniServiceLoader类核心逻辑分三步。第一步拿到加载器并定位资源public static S MiniServiceLoaderS load(ClassS service) { ClassLoader loader Thread.currentThread().getContextClassLoader(); return new MiniServiceLoader(service, loader); }第二步利用ClassLoader.getResources找到资源并解析类名private void readConfig() throws IOException { String fullName META-INF/services/ service.getName(); EnumerationURL urls classLoader.getResources(fullName); while (urls.hasMoreElements()) { URL url urls.nextElement(); try (InputStream in url.openStream(); BufferedReader reader new BufferedReader(new InputStreamReader(in, StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { line line.trim(); if (!line.isEmpty() !classNames.contains(line)) { classNames.add(line); } } } } }这里用getResources而不是getResource正是为了拿到 classpath 下所有 jar 里的同名配置文件。第三步加载并实例化然后缓存public ListS loadAll() { ListS list new ArrayList(); for (String className : classNames) { try { Class? clazz Class.forName(className, false, classLoader); if (!service.isAssignableFrom(clazz)) { continue; } Object instance clazz.getDeclaredConstructor().newInstance(); list.add(service.cast(instance)); } catch (Exception e) { System.err.println(failed to load provider: className , reason: e.getMessage()); } } return list; }注意这里我们做了类型校验确保配置文件里的类确实实现了接口避免运行时类型转换错误。完整的使用方式MiniServiceLoaderMessageSender loader MiniServiceLoader.load(MessageSender.class); ListMessageSender senders loader.loadAll(); for (MessageSender sender : senders) { sender.send(hello); }输出大约是这样[SMS] sending: hello [EMAIL] sending: hello这个迷你版本虽然只有几十行但把 SPI 的完整链路走了一遍你能清楚看到配置文件怎么找、类名怎么解析、实例怎么创建。自己动手写一遍后再回头看 ServiceLoader 源码就顺多了。4.3 手写过程中容易犯的三个低级错误第一个错误配置文件放错了位置。很多人把文件直接放在src/main/java下结果编译后没有进入 classpath运行时读取不到。文件的正确位置是src/main/resources编译后位于 classes 目录下。第二个错误文件里写了空行或者编译器注释。ServiceLoader 的解析逻辑比较简单对空行和非法行基本就是跳过或直接报错。为了避免低级错误最好保持每行一个类名末尾不要有额外空格。第三个错误接口和实现类不在同一个模块时容易漏掉 import 或包名写错。这里要反复检查配置文件里写的是不是完全限定名带包名如com.example.spi.EmailSender而不是简单的类名。5. 别把 SPI 用歪了几个踩坑现场与最佳实践深度了解一个机制光看它怎么用是不够的还得知道哪些场景下容易翻车。这里整理几个我实际遇到或看别人踩过的坑每一个背后都有真实的教训。5.1 多实现共存时的顺序问题配置文件顺序不可靠有时你需要多个实现按特定顺序执行比如一个安全过滤器链。但 ServiceLoader 在迭代多个资源时机制是这样的每个 jar 包里的配置按行读取行与行之间按顺序不同 jar 包之间的顺序取决于 classpath 的扫描顺序。这种顺序不可靠getResources不保证跨 jar 包的相对顺序。如果你依赖实现顺序绝不能在业务代码里假设“文件里写在前面就先执行”。我在之前一个项目中就出现过一次诡异故障一台机器上消息推送用的是短信方式另一台机器上却走了邮件。排查了半天发现是 classpath 中 jar 顺序不同导致的。后来统一改成按配置项排序、或者用Priority注解标注实现优先级问题才稳定下来。5.2 懒加载与并发迭代时实现类可能还没准备ServiceLoader 本身不是线程安全的它的 LazyIterator 有内部状态nextName、pending、configs。如果你在多个线程里同时调用同一个 loader 实例的iterator()可能抛出ConcurrentModificationException或者出现状态错乱。更隐蔽的问题是有些小白会做这种操作ServiceLoaderMessageSender loader ServiceLoader.load(MessageSender.class); MessageSender sender loader.iterator().next(); // 可能抛 NoSuchElementException如果 classpath 里实际没有对应实现next()就会抛异常。那么调用方必须有预案要么捕获异常要么提前判断hasNext()要么在编译期就保证至少有一个实现存在。5.3 实例化失败会造成连锁反应在nextService()里如果newInstance()抛异常ServiceLoader 会调用fail()最终抛出一个ServiceConfigurationError这是一个Error而不是Exception也就是说你如果只捕获 Exception 是接不住的。这意味着你写的实现类构造函数不能随便抛非受检异常。尤其是构造函数里如果做了 I/O 操作、网络连接这种容易失败的事情很可能导致整个服务加载过程直接失败。我的原则是实现类的构造函数只做最基础的赋值操作复杂初始化全部放到显式 init 方法里调用方在拿到实例后手动触发。这样能把 SPI 加载失败的影响范围控制到最小。5.4 注意 ClassLoader 的可见性在使用 ServiceLoader 时loader是一个不可忽视的变量。某些容器环境里线程上下文类加载器和应用类加载器不一致比如在 Java EE 容器中web 应用可能有自己的类加载器。如果你发现明明 classpath 里有配置文件但怎么都加载不到优先查一下Thread.currentThread().getContextClassLoader()是什么。我过去调试过一个诡异问题应用在 Idea 里能跑通打成 war 包部署到容器后SPI 实现完全失效。最后定位到原因是容器里的线程上下文类加载器不是我们预期的那个。解决办法是显式指定ServiceLoader.load(MessageSender.class, MyClass.class.getClassLoader())以自己类的加载器为准绕开容器上下文的影响。5.5 什么时候不该用 SPI虽然 SPI 非常有价值但它也不是银弹。如果你的场景只是固定一两个实现而且短期内不会有扩展需求用简单工厂可能更可控。SPI 的价值在于“运行时才知道实现有哪些”如果实现集合其实是固定的引入 SPI 反而增加了配置文件的维护成本也让代码的“可预测性”变低了。还有一点如果实现对安全要求很高或者上线时要做严格的白名单控制SPI 这种动态发现机制会给审计带来麻烦。你没法轻易知道 classpath 里到底加载进了哪些实现只能通过遍历才能确认。这种“不可见性”是它的天然属性接受它的同时就要设计好监控和兜底。6. 从 SPI 到 Java 模块化现代 JDK 下的服务绑定变化聊完经典 SPI有必要提一下它在 JDK 9 模块化JPMS时期的变化。因为现在很多新项目其实已经在用模块化结构了尤其是基于 Java 17 或更高版本开发时你可能会遇到provides ... with ...这种新写法。在非模块化环境下我们用META-INF/services文件描述实现。在模块化环境下可以换用module-info.java中的provides指令module my.provider.module { exports com.example.spi.impl; provides com.example.spi.MessageSender with com.example.spi.impl.EmailSender; }ServiceLoader在运行时同样可以识别这种声明方式配置文件的机制依然保留了兼容性。也就是说你的旧代码不用改也能加载到模块化下的实现。不过模块化带来一个新问题模块封装性更强。如果一个 jar 没有在module-info.java里显式exports那么即使 SPI 配置指向了它的实现类ServiceLoader 也可能无法访问。这种报错信息往往比较隐晦比较典型的提示是Provider com.example.impl not found或者IllegalAccessError。我的建议是如果项目使用了模块化SPI 提供方要把实现类所在包exports出来同时最好保持META-INF/services配置一致形成双保险。7. 我踩过 SPI 之后的一些心得最后说点个人体会。如果你正在设计一个需要支持第三方扩展的框架SPI 绝对值得你认真掌握。Java 生态里的很多底层机制都在用它java.sql.Driver、javax.imageio的图像编解码、java.nio.file.spi.FileSystemProvider、CDI 里的ServiceLoader用法、甚至日志框架SLF4J也大量借鉴了这种服务发现思想。它的核心理念——接口标准化、实现可插拔、运行时自动发现——比具体 API 本身更具价值。在学习路径上我比较推荐“三步走”第一步先用 ServiceLoader 跑通一个简单 demo感受配置文件到实例化的全过程。这一步能让你把 API 用起来。第二步读一遍 ServiceLoader 源码把你看到的每个细节懒加载、线程上下文类加载器、错误处理方式都跟我这篇文章里的解释对照起来。这一步能让你理解它的设计意图。第三步尝试在自己的小工具里用 SPI 做模块化扩展比如做成一个可插拔的校验器、可切换的消息通道。这一步能让你真正具备架构视野。万字长文讲完核心一句话SPI 就是 Java 给“可扩展性”定下的标准接驳协议。理解它等于打开了一扇通向框架底层设计思维的大门。如果你看完这篇文章后能顺手把 JDBC 驱动加载和 Spring.factories 的加载逻辑都重新审视一遍会发现很多以前觉得“玄学”的东西其实都有明确的规律可循。