线程上下文类加载器（ContextClassLoader）是为解决双亲委派模型下SPI等场景中父加载器无法加载子类加载器可见类的问题而设计的临时切换机制，典型用于JDBC驱动加载、框架插件扩展和模块隔离环境，使用时须严格遵循保存→设置→恢复三步。
线程上下文类加载器（ContextClassLoader）不是用来替代默认类加载流程的，而是为了解决双亲委派模型在特定场景下“无法反向加载”的问题。它的核心用法是：临时切换当前线程的类加载器，让本该由父类加载器调用的代码（比如 JDK 内部 SPI 实现），能加载到子类加载器（如应用类加载器）可见的类。
为什么需要 ContextClassLoader
Java 的双亲委派模型规定：类加载请求必须先交给父加载器，只有父加载器无法加载时，子加载器才尝试。这保证了核心类（如 java.lang.Object）不被污染，但也带来一个问题：JDK 提供的 SPI 接口（如 java.sql.Driver）由 Bootstrap 类加载器加载，而其实现类（如 com.mysql.cj.jdbc.Driver）在应用 classpath 下，Bootstrap 加载器根本看不见——它没法委托给子加载器。ContextClassLoader 就是为此设计的“绕过通道”。
典型使用场景
-
JDBC 驱动加载：DriverManager 在内部通过
Thread.currentThread().getContextClassLoader()去读取META-INF/services/java.sql.Driver并加载实现类，而不是用自身类所在的 Bootstrap 加载器。 - 框架插件扩展：Spring、Tomcat 等容器在执行用户自定义逻辑（如 Servlet、Bean 初始化）前，会把当前线程的 ContextClassLoader 切换为 Web 应用专属的类加载器，确保能正确加载用户 jar 中的类。
- 模块隔离环境：OSGi、Jigsaw 或自定义插件系统中，不同模块拥有独立类加载器，通过 ContextClassLoader 可在跨模块调用时指定目标模块的加载能力。
安全设置与恢复方式
手动设置 ContextClassLoader 必须严格遵循“保存 → 设置 → 恢复”三步，否则可能污染后续线程行为（尤其在线程池中后果严重）：
正确写法示例：
立即学习“Java免费学习笔记（深入）”；
ClassLoader originalCl = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(customClassLoader);
doSomethingThatNeedsCustomLoading(); // 如 ServiceLoader.load()、解析插件 JAR
} finally {
Thread.currentThread().setContextClassLoader(originalCl);
}
- 不要省略
finally块，避免异常导致上下文残留 - 不要直接传
null，除非明确知道影响范围；默认值通常是 AppClassLoader - 在异步任务（如
CompletableFuture、线程池提交）中，新线程不会自动继承修改后的 ContextClassLoader，需显式传递或重设
如何获取和验证当前值
主线程（main 方法）启动时，默认 ContextClassLoader 就是系统类加载器（AppClassLoader）：
System.err.println(Thread.currentThread().getContextClassLoader());
输出类似：sun.misc.Launcher$AppClassLoader@4e0e2f2a
子线程默认继承父线程的 ContextClassLoader，除非显式设置。可通过 Thread#init 源码确认其继承逻辑。
