java类加载器—ContextClassLoader类加载器

心已赠人 2022-09-03 15:12 273阅读 0赞

ContextClassLoader是一种与线程相关的类加载器,类似ThreadLocal,每个线程对应一个上下文类加载器.在实际使用时一般都用下面的经典结构:

ClassLoader targetClassLoader = null;// 外部参数
    
    ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
    try {
        Thread.currentThread().setContextClassLoader(targetClassLoader);
        // TODO
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        Thread.currentThread().setContextClassLoader(contextClassLoader);
    }

1.  首先获取当前线程的线程上下文类加载器并保存到方法栈,然后将外部传递的类加载器设置为当前线程上下文类加载器
2.  doSomething则可以利用新设置的类加载器做一些事情
3.  最后在设置当前线程上下文类加载器为老的类加载器

上面的使用场景是什么?Java默认的类加载机制是委托机制,但是有些时候需要破坏这种固定的机制

具体来说,比如Java中的SPI(Service Provider Interface)是面向接口编程的,服务规则提供者会在JRE的核心API里面提供服务访问接口,而具体的实现则由其他开发商提供.我们知道Java核心API,比如rt.jar包,是使用Bootstrap ClassLoader加载的,而用户提供的jar包再由AppClassLoader加载.并且我们知道一个类由类加载器A加载,那么这个类依赖类也应该由相同的类加载器加载.那么Bootstrap ClassLoader加载了服务提供者在rt.jar里面提供的搜索开发上提供的实现类的API类(ServiceLoader),那么这些API类里面依赖的类应该也是有Bootstrap ClassLoader来加载.而上面说了用户提供的Jar包有AppClassLoader加载,所以需要一种违反双亲委派模型的方法,线程上下文类加载器ContextClassLoader就是为了解决这个问题。

下面使用JDBC来具体说明,JDBC是基于SPI机制来发现驱动提供商提供的实现类,提供者只需在JDBC实现的jar的META-INF/services/java.sql.Driver文件里指定实现类的方式暴露驱动提供者.例如:MYSQL实现的jar如下:

![è¿éåå¾çæè¿°][70]

其中MYSQL的驱动如下实现了java.sql.Driver

public class Driver extends NonRegisteringDriver implements java.sql.Driver

引入MySQL驱动的jar包,测试类如下:

import java.sql.Driver;
    import java.util.Iterator;
    import java.util.ServiceLoader;
    
    public class MySQLClassLoader {
    
        public static void main(String[] args) {
            ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class);
            Iterator<Driver> iterator = loader.iterator();
            while (iterator.hasNext()) {
                Driver driver = (Driver) iterator.next();
                System.out.println("driver:" + driver.getClass() + ",loader:" + driver.getClass().getClassLoader());
            }
    
            System.out.println("current thread contxtloader:" + Thread.currentThread().getContextClassLoader());
    
            System.out.println("ServiceLoader loader:" + ServiceLoader.class.getClassLoader());
        }
    
    }

执行结果如下:

driver:class com.mysql.jdbc.Driver,loader:sun.misc.Launcher$AppClassLoader@2a139a55
    driver:class com.mysql.fabric.jdbc.FabricMySQLDriver,loader:sun.misc.Launcher$AppClassLoader@2a139a55
    driver:class com.alibaba.druid.proxy.DruidDriver,loader:sun.misc.Launcher$AppClassLoader@2a139a55
    driver:class com.alibaba.druid.mock.MockDriver,loader:sun.misc.Launcher$AppClassLoader@2a139a55
    current thread contxtloader:sun.misc.Launcher$AppClassLoader@2a139a55
    ServiceLoader loader:null

从执行结果中可以知道ServiceLoader的加载器为Bootstrap,因为这里输出了null,并且从该类在rt.jar里面,也可以证明.

当前线程上下文类加载器为AppClassLoader.而com.mysql.jdbc.Driver则使用AppClassLoader加载.我们知道如果一个类中引用了另外一个类,那么被引用的类也应该由引用方类加载器来加载,而现在则是引用方ServiceLoader使用BootStartClassLoader加载,被引用方则使用子加载器APPClassLoader来加载了.是不是很诡异.

下面来看一下ServiceLoader的load方法源码:

public static <S> ServiceLoader<S> load(Class<S> service,
                                            ClassLoader loader)
    {
        return new ServiceLoader<>(service, loader);
    }
    
    public static <S> ServiceLoader<S> load(Class<S> service) {
        // 获取当前线程上下文加载器,这里是APPClassLoader
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

上述代码获得了线程上下文加载器(其实就是AppClassLoader),并将该类加载器传递到下面的ServiceLoader类的构造方法loader成员变量中:

private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }

上述loader变量什么时候使用的?看一下下面的代码:

public S next() {
        if (acc == null) {
            return nextService();
        } else {
            PrivilegedAction<S> action = new PrivilegedAction<S>() {
                public S run() { return nextService(); }
            };
            return AccessController.doPrivileged(action, acc);
        }
    }

private S nextService() {
        if (!hasNextService())
            throw new NoSuchElementException();
        String cn = nextName;
        nextName = null;
        Class<?> c = null;
        try {
            // 使用loader类加载器加载
            // 至于cn怎么来的,可以参照next()方法
            c = Class.forName(cn, false, loader);
        } catch (ClassNotFoundException x) {
            fail(service,
                 "Provider " + cn + " not found");
        }
        if (!service.isAssignableFrom(c)) {
            fail(service,
                 "Provider " + cn  + " not a subtype");
        }
        try {
            S p = service.cast(c.newInstance());
            providers.put(cn, p);
            return p;
        } catch (Throwable x) {
            fail(service,
                 "Provider " + cn + " could not be instantiated",
                 x);
        }
        throw new Error();          // This cannot happen
    }

到目前为止:ContextClassLoader的作用都是为了破坏Java类加载委托机制,JDBC规范定义了一个JDBC接口,然后使用SPI机制提供的一个叫做ServiceLoader的Java核心API(rt.jar里面提供)用来扫描服务实现类,服务实现者提供的jar,比如MySQL驱动则是放到我们的classpath下面.从上文知道默认线程上下文类加载器就是AppClassLoader,所以例子里面没有显示在调用ServiceLoader前设置线程上下文类加载器为AppClassLoader,ServiceLoader内部则获取当前线程上下文类加载器(这里为AppClassLoader)来加载服务实现者的类,这里加载了classpath下的MySQL的驱动实现.

可以尝试在调用ServiceLoader的load方法前设置线程上下文类加载器为ExtClassLoader,代码如下:

Thread.currentThread().setContextClassLoader(ContextClassLoaderTest.class.getClassLoader().getParent());

然后运行本例子,设置后ServiceLoader内部则获取当前线程上下文类加载器为ExtClassLoader,然后会尝试使用ExtClassLoader去查找JDBC驱动实现,而ExtClassLoader扫描类的路径为:JAVA\_HOME/jre/lib/ext/,而这下面没有驱动实现的Jar,所以不会查找到驱动.

总结下,当父类加载器需要加载子类加载器中的资源时,可以通过设置和获取线程上下文类加载器来实现.

[70]: /images/20220829/046139e961f5419eacea83b2b02aec63.png