为什么需要线程上下文类加载器

线程上下文类加载器基础

线程上下文类加载器是一种类加载器传递机制。为什么叫作“线程上下文类加载器”呢，因为这个类加载器保存在线程私有数据里，只要是同一个线程，一旦设置了线程上下文加载器，在线程后续执行过程中就能把这个类加载器取出来用。

线程上下文加载器其实是线程私有数据，跟线程绑定的属性。

站在开发者角度，其他线程都是由main线程，也就是main函数所在的线程派生的，它是其他线程的父线程或者祖先线程。

currentThread().getContextClassLoader()

为什么要有线程上下文类加载器呢？这就与JVM类加载器双亲委托机制自身的缺陷有关。

案例1：JDK SPI机制

问题

JDK的核心库中提供了很多SPI（Service Provider Interface），常见的SPI包括jdbc等。java使用JDBC这个SPI完全透明了应用程序与第三方数据库驱动的具体实现，这样做的好处是JDBC提供了高度抽象，应用程序则只需要面向接口编程。

但问题在于java.lang.sql中的所有接口都是由JDK提供，加载这些接口的类加载器是根加载器，第三方厂商提供的类库驱动则是由系统类加载器加载的。由于JVM类加载器是双亲委托机制，比如Connections、Statement、ResultSet等都是由根加载器加载，根加载器不会加载到第三方的JDBC驱动包中的实现，如何解决这个问题呢？

“根据JVM规范的规定，在类的加载过程中，所有参与的类加载器，即便没有亲自加载过该类，也都会被标识为该类的初始类加载器。JVM会在每一个类加载器维护的列表上添加该class类型。”

我的理解是：

在 JVM 的实现中有一条隐含的规则，默认情况下，如果一个类由类加载器 A 加载，那么这个类的依赖类也是由相同的类加载器加载。

当系统中使用Connection的时候，其仅仅会通过根加载器加载了jdk中的Connnection接口，比如MysqlConnection是Connection的依赖类，其也应该由根加载器来加载，当然rt.jar中并没有这个类，这个类在classpath下面。

解决方案

为了解决这个困境，JDK只好提供一种不太优雅的设计—线程上下文类加载器，有了线程上下文类加载器，根加载器反倒需要委托系统类加载器去加载厂商提供的SPI具体实现。父委托变成了子委托的方式，这也打破了双亲委托机制的模型，

java.sql.DriverManager#getConnection(java.lang.String, java.util.Properties, java.lang.Class<?>)

在这里获取当前线程的上下文类加载器，该类就是调用Class.forName(“x”)所在线程的上下文类加载器，通常是系统类加载器

我的理解就是调用Class.forName()就是设置当前线程的上下文类加载器

/*
 * When callerCl is null, we should check the application's
 * (which is invoking this class indirectly)
 * classloader, so that the JDBC driver class outside rt.jar
 * can be loaded from here.
 */
ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
if (callerCL == null) {
    callerCL = Thread.currentThread().getContextClassLoader();
}

迭代DriverManager中已经注册的驱动类，然后验证该数据库驱动是否可以被指定的类加载器加载（线程上下文类加载器），如果验证通过则返回Connnection，此刻返回的Connnection则是数据库厂商提供的实例。

for (DriverInfo aDriver : registeredDrivers) {
    // If the caller does not have permission to load the driver then
    // skip it.
    if (isDriverAllowed(aDriver.driver, callerCL)) {
        try {
            println("    trying " + aDriver.driver.getClass().getName());
            Connection con = aDriver.driver.connect(url, info);
            if (con != null) {
                // Success!
                println("getConnection returning " + aDriver.driver.getClass().getName());
                return (con);

java.sql.DriverManager#isDriverAllowed(java.sql.Driver, java.lang.ClassLoader)

Class.forName(driver.getClass().getName(),true,classLoader)

其使用上下文类加载器进行数据库驱动的加载以及初始化

private static boolean isDriverAllowed(Driver driver, ClassLoader classLoader) {
    boolean result = false;
    if (driver != null) {
        Class<?> aClass = null;
        try {
            aClass =  Class.forName(driver.getClass().getName(), true, classLoader);
        } catch (Exception ex) {
            result = false;
        }

         result = ( aClass == driver.getClass() ) ? true : false;
    }

    return result;
}

自此几乎所有涉及SPI加载的动作都是采取这种方式。当然这可能是由于早期java开发者没有考虑那么周全的原因所导致的。

案例2：tomcat中spring加载业务类

问题

Spring 作为共享的第三方 JAR 包，它本身是由Tomcat的 SharedClassLoader 来加载的，Spring 又要去加载业务类，按照前面那条规则，

在 JVM 的实现中有一条隐含的规则，默认情况下，如果一个类由类加载器 A 加载，那么这个类的依赖类也是由相同的类加载器加载。

加载 Spring 的类加载器也会用来加载业务类。

但是业务类在 Web 应用目录下，不在 SharedClassLoader 的加载路径下，这该怎么办呢？

解决方案

于是线程上下文类加载器登场了，Tomcat 为每个 Web 应用创建一个 WebAppClassLoader 类加载器，并在启动任何一个Web 应用的线程里设置线程上下文加载器，这样 Spring 在启动时就将线程上下文加载器取出来，用来加载 Bean。

Spring 取线程上下文加载的代码如下：

cl = Thread.currentThread().getContextClassLoader();

setContextClassLoader(ClassLoader cl)，这个方法可以打破java类加载器的父委托机制，这个方法也
被成为java类加载器的后门。这个后门也是有作用的。

补充：facade模式类加载问题

比如日志门面slf4j，metrics门面micrometer，其门面是怎么绑定/适配/桥接到实现组件呢？
具体参考：Slf4j适配日志原理

总结来说，

slf4j的适配原理是通过适配包的org/slf4j/impl/StaticLoggerBinder来做转承，适配包通过继承和使用slf4j-api的ILoggerFactory和Logger来完成适配，类加载使用同一个类加载器。