Thread.currentThread().getContextClassLoader() 可能为 null 或非预期值，因其默认继承父线程且受 JVM 启动环境、框架（如 ForkJoinPool）及线程池影响；SPI 加载必须依赖 TCCL 而非 getClass().getClassLoader()，因 JDK 核心类需通过它发现应用级实现类。
为什么 Thread.currentThread().getContextClassLoader() 总是 null 或不是你预期的那个？
因为线程上下文类加载器（TCCL）默认继承自父线程，而主线程的 TCCL 通常由 JVM 启动时设置——比如在 Tomcat 中是 WebAppClassLoader，在普通 Java SE 程序中则大概率是 AppClassLoader；但如果你手动新建线程且没显式设置，它会继承创建时主线程的 TCCL，而某些框架（如 Spring Boot 的 ForkJoinPool）会重置为 null 或系统类加载器。
- 显式设置前务必检查：
Thread.currentThread().getContextClassLoader()可能为null，直接调用loadClass()会抛NullPointerException - 不要假设“主线程设过，子线程就一定有”，尤其是使用线程池、CompletableFuture 或 ForkJoinTask 时
- 常见错误现象：
ServiceConfigurationError或ClassNotFoundException在 SPI 加载时突然出现，但单独跑 main 方法却正常
SPI 服务加载必须用 TCCL 而不是 getClass().getClassLoader()？
是的。SPI 规范（META-INF/services/xxx）要求服务发现逻辑使用当前线程的上下文类加载器，而不是调用方类的类加载器。这是因为服务提供方（比如数据库驱动 mysql-connector-java）往往放在应用 classpath 下，而调用方（比如 JDBC DriverManager）可能在 rt.jar 里——它的类加载器是 BootstrapClassLoader，根本看不到应用里的实现类。
-
DriverManager内部用的是Thread.currentThread().getContextClassLoader()去查java.sql.Driver实现 - 如果你在 Servlet 容器里写了个工具类，用
this.getClass().getClassLoader().getResources("META-INF/services/com.example.MySpi")，很可能返回空枚举——因为这个类加载器是容器的，不是当前 Web 应用的 - 正确姿势：先判空，再 fallback：
ClassLoader cl = Thread.currentThread().getContextClassLoader(); if (cl == null) { cl = MyClass.class.getClassLoader(); // 仅作兜底，不保证能加载 SPI 实现 }
什么时候必须手动 setContextClassLoader？
当你启动新线程、切换执行上下文，且该线程需要加载当前应用级别的资源（配置、SPI 实现、模板文件等）时，就必须干预。典型场景是异步任务、定时任务、RPC 回调线程。
- 使用
new Thread()：在 start 前设置，例如Thread t = new Thread(() -> doWork()); t.setContextClassLoader(MyClass.class.getClassLoader()); t.start();
- 线程池：用
ThreadFactory包装，避免每次手动设；Spring 的SimpleAsyncTaskExecutor默认会继承，但ThreadPoolTaskExecutor不会 - 不要在
Runnable开头临时 set + 结尾 restore，容易漏异常路径；更稳的方式是封装成装饰器或使用 try-with-resources 风格的上下文管理（需自定义） - 注意：setContextClassLoader 是线程私有的，对其他线程无影响，但频繁 set/get 有轻微性能开销（JVM 内部是 volatile 字段）
双亲委派被“打破”只是表象，本质是类加载器职责划分
TCCL 不是绕过双亲委派，而是给类加载加了一层“策略选择”：由线程决定“此刻该信任谁”。JDBC、JNDI、XML 解析这些跨容器场景，需要让高层模块（如 JDK 自带的 DriverManager）能回调到底层模块（如用户引入的 postgresql-42.x.jar）的代码，而双亲委派天然阻止这种反向可见性。
立即学习“Java免费学习笔记（深入）”；
- 所谓“打破”，只是把类加载决策权从“静态继承链”移交到“动态线程上下文”，不是废掉委派机制本身
- 你不能靠 TCCL 加载
java.*或javax.*类（Bootstrap 和 Extension 类加载器仍拦截），否则会报SecurityException - 容易踩的坑：在 OSGi、模块化（Java 9+）或 GraalVM Native Image 环境中，TCCL 行为更不可靠，部分 SPI 实现会主动忽略 TCCL 改用模块查找
真正难处理的从来不是怎么设 TCCL，而是当多个框架（比如 Dubbo + ShardingSphere + 自定义 SPI）各自 setContextClassLoader 且互相覆盖时，你得知道哪一层该信谁、在哪一刻该冻结上下文——这种耦合藏得深，出问题时堆栈里连类加载器名都看不到。
