Java ServiceLoader 的类加载器选择机制详解

Ja va 的 `ServiceLoader` 是实现 SPI（Service Provider Interface）的核心工具，它的行为高度依赖类加载器的选择。但很多人容易忽略一个关键点：三个静态工厂方法所使用的类加载器其实各不相同，这个差异直接影响服务发现的范围和性能。从 JDK 8 到 JDK 17（甚至 JDK 20），`ServiceLoader` 提供了三个静态方法，它们在类加载器上的选择有本质区别： - `ServiceLoader.load(Class service)`：**使用当前线程的上下文类加载器（Context Class Loader）**。在绝大多数标准应用启动场景中，这个上下文类加载器默认就是**系统类加载器（System Class Loader）**——也就是通过 `-cp` 或 `CLASSPATH` 加载应用类的那个加载器。 - `ServiceLoader.load(Class service, ClassLoader loader)`：**显式使用传入的 ClassLoader 实例**。这给了开发者完全控制权，特别适合多模块、OSGi 或容器化环境这类需要隔离类加载的场景。 - `ServiceLoader.loadInstalled(Class service)`：**固定使用平台类加载器（Platform Class Loader）**（JDK 9+ 引入，取代了旧称“扩展类加载器”/Extension Class Loader）。这个加载器只负责加载 JDK 自身提供的模块（如 `ja va.base`、`ja va.sql` 等），**不扫描应用 classpath，也不读取 `ext/` 目录**（该机制已在模块化中废弃）。 ```php // 示例：三种加载方式的典型用法 ServiceLoader appProviders = ServiceLoader.load(CharsetProvider.class); // → 使用上下文类加载器（通常为 System Class Loader） ServiceLoader customProviders = ServiceLoader.load( CharsetProvider.class, MyCustomClassLoader.getInstance()); // → 显式指定加载器 ServiceLoader jdkProviders = ServiceLoader.loadInstalled(CharsetProvider.class); // → 仅查找 JDK 内置 provider（如 sun.nio.cs.StandardCharsets） ``` 为什么要让 `loadInstalled()` 限定使用平台类加载器？答案其实在于**语义契约与性能优化**：这个方法的设计目标是“仅发现已安装（installed）于 JVM 的服务提供者”，也就是 JDK 原生支持的功能（如 `Charset`、`TimeZoneProvider`、`ScriptEngineManager` 等）。这些实现稳定、全局一致，且不会随应用变更——因此可以安全缓存、跨线程复用，避免重复解析 `META-INF/services/` 文件。就像 `Charset` 类内部做的那样：先调用 `loadInstalled()` 获取 JDK 内置编码器，失败后再 fallback 到 `load()` 查找用户自定义实现。 ⚠️ **注意事项：** - 不要假设 `Thread.currentThread().getContextClassLoader()` 总是系统类加载器；在 Web 容器（Tomcat）、应用服务器或框架（Spring Boot）中，它可能被显式设置为自定义加载器。 - `loadInstalled()` 在模块化环境中严格受限于 `ja va.base` 及其他由平台加载器主导的模块，无法加载应用模块中声明的服务。 - `load(Class)` 的返回值**不应全局缓存**（API 明确警告），因为它的行为与调用方的类加载上下文强绑定；而 `loadInstalled()` 返回的服务实例可以安全缓存——这是它的核心优势。 总结一下，`ServiceLoader` 并不是统一使用某一个类加载器，而是通过方法签名清晰分离职责：`load()` 面向应用扩展，`loadInstalled()` 面向 JDK 内置能力，`load(..., ClassLoader)` 提供底层控制。理解这一设计，是正确使用 SPI、避免类加载冲突与服务发现失败的关键。