线程上下文类加载器（TCCL）是线程级可变类加载器，不依赖当前执行类的加载器；需通过Thread.currentThread().getContextClassLoader()获取，设置时必须遵循“保存→切换→使用→finally还原”闭环，否则在线程池等复用场景下将导致类加载错乱或内存泄漏。
线程上下文类加载器（Thread Context ClassLoader，简称 TCCL）是当前线程持有的、用于加载类和资源的类加载器，它**不依赖于当前正在执行的类的类加载器**，而是由线程自身维护的一个可变引用。设置与获取它非常直接，但关键在于**何时设、设成谁、用完是否恢复**。
如何获取当前线程的上下文类加载器
调用静态方法即可：
ClassLoader cl = Thread.currentThread().getContextClassLoader();
返回值可能为 null（极少见，如某些特殊环境或显式设为 null），多数情况下是继承自父线程的加载器：主线程默认是 AppClassLoader，Web 容器中常为 WebappClassLoader 等。
如何安全地设置上下文类加载器
使用 setContextClassLoader(ClassLoader) 方法，但必须配合 try-finally 保证恢复，否则会污染线程复用场景（如线程池）：
立即学习“Java免费学习笔记（深入）”；
- 先保存原始值：
ClassLoader original = Thread.currentThread().getContextClassLoader(); - 再设置新值：
Thread.currentThread().setContextClassLoader(customClassLoader); - 在
finally块中强制还原：Thread.currentThread().setContextClassLoader(original);
示例代码结构：
ClassLoader original = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(pluginClassLoader);
doSomethingThatNeedsCustomLoading(); // 如 ServiceLoader.load()、插件类实例化
} finally {
Thread.currentThread().setContextClassLoader(original);
}
为什么不能直接用 Class.forName() 替代 TCCL
Class.forName(String) 默认使用**当前类的类加载器**（即定义该调用语句的类所属的加载器），而 TCCL 是线程级的、可动态切换的。两者来源不同：
- JDBC 场景中：
java.sql.Connection由启动类加载器加载，但com.mysql.cj.jdbc.Driver由应用类加载器加载；核心库无法委托子加载器，只能靠线程设置 TCCL 让ServiceLoader找到实现类 - 插件系统中：主程序接口由 AppClassLoader 加载，插件实现由 URLClassLoader 加载；若不设 TCCL，
ServiceLoader.load()就会找不到插件类
常见误用与注意事项
以下做法容易引发 ClassCastException 或 NoClassDefFoundError：
- 在线程池中提交任务前未设 TCCL，导致复用线程沿用旧的加载器
- 设了 TCCL 却忘记在 finally 中恢复，造成后续任务类加载错乱
- 误以为
Thread.currentThread().getContextClassLoader().getResource("xxx")总能拿到当前类所在路径的资源——实际查的是 TCCL 的 classpath，不是当前类的 classpath - Java 9+ 模块环境下，未配置
--add-opens或模块声明opens，导致 TCCL 无法访问目标包内资源
