tccl通过线程绑定的上下文类加载器绕过双亲委派限制，使bootstrap加载的spi接口能加载appclassloader管理的第三方实现类；serviceloader等核心机制显式使用tccl完成跨层级类加载。
线程上下文类加载器（TCCL）解决 SPI 问题的核心，在于绕过双亲委派限制，让由 Bootstrap 类加载器加载的 SPI 接口代码，能“看到”并加载由应用类加载器（AppClassLoader）管理的第三方实现类。
SPI 场景下的类加载冲突
SPI 接口（如 java.sql.Driver）在 JDK 核心库中，由 Bootstrap 类加载器加载；而 MySQL、PostgreSQL 等驱动实现类（如 com.mysql.cj.jdbc.Driver）在应用 classpath 下，只能由 AppClassLoader 加载。按双亲委派模型，Bootstrap 加载器无法委托子加载器去加载——它根本没有 parent 指向 AppClassLoader，也无权向下查找。
TCCL 如何打破僵局
TCCL 提供了一个可被显式设置、与线程绑定的“备用加载器”，让高层代码（如 DriverManager 或 ServiceLoader）在需要加载实现类时，不依赖当前类的 classloader，而是主动使用当前线程的上下文加载器：
-
DriverManager 初始化时，调用
Thread.currentThread().getContextClassLoader()获取 TCCL，默认就是 AppClassLoader -
ServiceLoader.load(ServiceInterface.class) 内部正是用 TCCL 去读取
META-INF/services/com.example.ServiceInterface并加载其中列出的实现类名 - 即使调用方是
java.util.ServiceLoader（Bootstrap 加载），只要线程上下文设对了，就能成功加载用户 jar 中的实现
为什么必须是“线程级”的上下文
因为 JVM 不允许类加载器跨层级反向委托，但线程是执行逻辑的载体，天然贯穿整个调用链。把加载器“挂”在线程上，就等于为整条调用路径提供了一个统一、可控、可切换的加载入口：
- 主线程启动时，TCCL 默认继承自系统类加载器（AppClassLoader）
- 容器（如 Tomcat）或框架（如 Spring）可在执行用户逻辑前临时切换 TCCL，确保资源加载走正确的 classpath 范围
- 用完及时还原，避免污染后续任务——这是安全使用的必要习惯
典型代码体现
以 ServiceLoader 源码逻辑为例：
public static <s> ServiceLoader<s> load(Class<s> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return new ServiceLoader(service, cl); // 关键：用 TCCL 构造
}</s></s></s>
后续 iterator() 中解析 META-INF/services/... 并调用 cl.loadClass(className)，就自然命中应用类路径下的实现类。
