spi机制通过线程上下文类加载器（tccl）绕过双亲委派，使bootstrapclassloader能委托appclassloader加载jdbc等第三方实现类，属有意设计妥协而非破坏。
Java 的 SPI（Service Provider Interface）机制本身并不直接“破坏”双亲委派模型，而是通过一种**绕过默认类加载器委托链**的方式，实现由当前线程上下文类加载器（Thread Context ClassLoader, TCCL）来加载服务实现类，从而在特定场景下规避了双亲委派的约束。这不是 Bug，而是设计上的有意妥协，用于解决框架与应用之间类加载隔离带来的服务发现难题。
为什么需要绕过双亲委派？
典型场景：JDK 的 java.sql.DriverManager 在初始化时要加载第三方 JDBC 驱动（如 MySQL 的 com.mysql.cj.jdbc.Driver）。该驱动 jar 通常放在应用 classpath（由 AppClassLoader 加载），而 DriverManager 是 rt.jar 中的类（由 BootstrapClassLoader 加载）。按双亲委派，BootstrapClassLoader 无法委托 AppClassLoader 去加载应用类——它根本看不到那些类。
解决方案就是：让 DriverManager 不用自己的类加载器去加载驱动，而是读取当前线程的 TCCL，用它去加载服务实现。
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
SPI 的核心加载逻辑依赖 TCCL
以 java.util.ServiceLoader 为例：
- 当你调用
ServiceLoader.load(MyService.class)，它默认使用Thread.currentThread().getContextClassLoader()来加载META-INF/services/xxx文件及对应的服务实现类； - 这个 TCCL 通常由容器（如 Tomcat、Spring Boot）或启动代码显式设置为应用类加载器（AppClassLoader 或自定义 ClassLoader），而非调用方（如 rt.jar 中的 ServiceLoader）的类加载器；
- 因此，即使
ServiceLoader是 BootstrapClassLoader 加载的，它也能通过 TCCL 成功加载应用层提供的实现类。
如何主动利用这一机制？
你可以在关键操作前手动设置 TCCL，确保 SPI 能正确发现服务：
- 在框架入口（如 Servlet 初始化、Spring Bean 创建前）设置：
Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); - 使用带 ClassLoader 参数的重载方法（更安全，不依赖 TCCL）：
ServiceLoader.load(MyService.class, MyService.class.getClassLoader()); - 避免在静态上下文（如 static 块）中直接调用
ServiceLoader.load()，因为此时 TCCL 可能未初始化或不可控。
这不是“破坏”，而是协作式类加载解耦
SPI 并没有修改 JVM 的双亲委派规则，也没有让 BootstrapClassLoader 去加载应用类。它只是把类加载的决策权从“调用方类的加载器”转移到“当前业务上下文的加载器”。这种转移由开发者或容器控制，本质上是一种约定优于配置的类加载协作模式，解决了跨层级（系统 API ↔ 应用实现）的服务集成问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
