线程上下文类加载器基础
线程上下文类加载器是一种类加载器传递机制。为什么叫作“线程上下文类加载器”呢,因为这个类加载器保存在线程私有数据里,只要是同一个线程,一旦设置了线程上下文加载器,在线程后续执行过程中就能把这个类加载器取出来用。
线程上下文加载器其实是线程私有数据,跟线程绑定的属性。
站在开发者角度,其他线程都是由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
来完成适配,类加载使用同一个类加载器。