Java类加载器之ContextClassLoader详解
作者：先说好不能骂我
ContextClassLoader
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);
}- 首先获取当前线程的线程上下文类加载器并保存到方法栈,然后将外部传递的类加载器设置为当前线程上下文类加载器
- doSomething则可以利用新设置的类加载器做一些事情
- 最后在设置当前线程上下文类加载器为老的类加载器
上面的使用场景是什么?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如下:
其中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,所以不会查找到驱动.
总结下,当父类加载器需要加载子类加载器中的资源时,可以通过设置和获取线程上下文类加载器来实现.
到此这篇关于Java类加载器之ContextClassLoader详解的文章就介绍到这了,更多相关ContextClassLoader详解内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！