您现在的位置是:首页 > 文章详情

类加载器中的双亲委派模型详解

日期:2019-10-12点击:396

在上一篇文章中,我们梳理了类加载器的基本概念:类的生命周期、类加载器的作用、类的加载和卸载的时机等等,这篇文章我们接着前文继续复习类加载器的知识,主要包括:JVM中有哪些类加载器?它们之间是什么关系?什么是双亲委派机制?

双亲委派模型

四种类加载器

从JVM的角度看,类加载器主要有两类:Bootstrap ClassLoader和其他类加载,Bootstrap ClassLoader是C++语言实现,是虚拟机自身的一部分;其他类加载器都是Java语言实现,不属于虚拟机,全部继承自抽象类java.lang.ClassLoader。

从Java开发者的角度看,需要了解类加载器的双亲委派模型,如下图所示:

双亲委派模型

  • Bootstrap ClassLoader:启动类加载器,这个类加载器将负责存放在/lib目录中、被-Xbootclasspath参数所指定的路径中,并且是虚拟机会识别的jar类库加载到内存中。更直白点说,就是我们常用的java.lang开头的那些类,一定是被Bootstrap ClassLoader加载的。
  • Extension ClassLoader:扩展类加载器,这个类加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载/lib/ext目录中的、或者被java.ext.dirs系统变量指定的路径中的所有类库。
  • Application ClassLoader:应用程序类加载器,这个类加载器由sun.misc.Launcher$AppClassLoader实现,它负责加载用户CLASSPATH环境变量指定的路径中的所有类库。如果应用程序中没有自定义过自己的类加载器,这个就是一个Java程序中默认的类加载器。
  • 用户自定义的类加载器:用户在需要的情况下,可以实现自己的自定义类加载器,一般而言,在以下几种情况下需要自定义类加载器:(1)隔离加载类。某些框架为了实现中间件和应用程序的模块的隔离,就需要中间件和应用程序使用不同的类加载器;(2)修改类加载的方式。类加载的双亲委派模型并不是强制的,用户可以根据需要在某个时间点动态加载类;(3)扩展类加载源,例如从数据库、网络进行类加载;(4)防止源代码泄露。Java代码很容易被反编译和篡改,为了防止源码泄露,可以对类的字节码文件进行加密,并编写自定义的类加载器来加载自己的应用程序的类。

例子1:不同的类加载器

在下面的代码中,java.util.HashMap是rt.jar包中的类,因此它的类加载器是null,DNSNameService类是放在ext目录下的jar包中的类,因此它的类加载器是ExtClassLoader;MyClassLoaderTest的类加载器就是应用类加载器。

import java.util.HashMap; import sun.net.spi.nameservice.dns.DNSNameService; public class MyClassLoaderTest { public static void main(String[] args) { System.out.println("class loader for HashMap: " + HashMap.class.getClassLoader()); System.out.println( "class loader for DNSNameService: " + DNSNameService.class.getClassLoader()); System.out.println("class loader for this class: " + MyClassLoaderTest.class.getClassLoader()); System.out.println("class loader for Blob class: " + com.mysql.jdbc.Blob.class.getClassLoader()); } }

运行上述代码的接入过下图所示:

image-20191013141845449

例子2:不同类加载器管理的文件路径

通过下面的这个程序,可以看到,每个类加载器负责的jar文件路径都不一样:

public class JVMClassLoader { public static void main(String[] args) { System.out.println("引导类加载器加载路径:" + System.getProperty("sun.boot.class.path")); System.out.println("扩展类加载器加载路径:" + System.getProperty("java.ext.dirs")); System.out.println("系统类加载器加载路径:" + System.getProperty("java.class.path")); } }

image-20191013140720888

例子3:Arthas中的classloader命令

Arthas中提供了classloader命令,可以用来查看当前应用中的类加载器相关的统计信息,如下图所示,

  1. 输入classloader后展示的表格汇总了当前应用的类加载器、每个类加载器的实例个数、每个类加载器加载的类的个数。
  2. 输入classloader -t后,展示了当前应用中类加载器的层次结构,可以看出,BootStrap ClassLoader确实在类加载器体系的顶层,接下来是扩展类加载器,再然后是应用类加载器,这里还有一个ArthasClassLoader,是Arthas自己实现的一个自定义类加载器。

image-20191013135633962

双亲委派模型的工作过程

如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。

使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object,它存放在rt.jar之中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。相反,如果没有使用双亲委派模型,由各个类加载器自行去加载的话,如果用户自己编写了一个称为java.lang.Object的类,并放在程序的Class Path中,那系统中将会出现多个不同的Object类,Java类型体系中最基础的行为也就无法保证,应用程序也将会变得一片混乱。

双亲委派模型的实现非常简单,实现双亲委派的代码在java.lang.ClassLoader的loadClass()方法之中,如下面的代码所示:

 protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 首先,检查该类是否已经被加载 Class<?> c = findLoadedClass(name); if (c == null) { long t0 = System.nanoTime(); try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 如果父类加载器抛出ClassNotFoundException, // 说明父类加载器无法完成加载请求 } if (c == null) { // 在父类加载器无法加载的时候,再调用本类的findClass方法进行类加载请求 long t1 = System.nanoTime(); c = findClass(name); // this is the defining class loader; record the stats // 当前类加载器是该类的define class loader sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); sun.misc.PerfCounter.getFindClasses().increment(); } } if (resolve) { resolveClass(c); } return c; } }

破坏双亲委派模型

线程上下文加载器

如上所述,双亲委派模型很好得解决了各个类加载器的基础类的统一问题(越基础的类由越上层的加载器进行加载),如果基础类又要回调用户的类该怎么办?一个非常经典的例子就是SQL的驱动管理类——java.sql.DriverManager。

java.sql.DriverManager是Java的标准服务,该类放在rt.jar中,因此是由启动类加载器加载的,但是在应用启动的时候,该驱动类管理是需要加载由不同数据库厂商实现的驱动,但是启动类加载器找不到这些具体的实现类,为了解决这个问题,Java设计团队提供了一个不太优雅的设计:线程上下文加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置,如果创建线程时候它还没有被设置,就会从父线程中继承一个,如果再应用程序的全局范围都没有设置过的话,那这个类加载器就是应用程序类加载器。

有了线程上下文加载器,就可以解决上面的问题——父类加载器需要请求子类加载器完成类加载的动作,这种行为实际上就是打破了双亲委派的加载规则。

线程上下文加载器

源码分析

接下来,我们以java.sql.DriverManager为例,看下线程上下文加载器的用法,在java.sql.DriverManager类的下面这个静态块中,是JDBC驱动加载的入口。

 /** * Load the initial JDBC drivers by checking the System property * jdbc.properties and then use the {@code ServiceLoader} mechanism */ static { loadInitialDrivers(); println("JDBC DriverManager initialized"); }

顺着loadInitialDrivers()方法往下看,使用线程上下文加载器的地方在ServiceLoader.load里

 private static void loadInitialDrivers() { // ……省去别的代码 AccessController.doPrivileged(new PrivilegedAction<Void>() { public Void run() { ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class); Iterator<Driver> driversIterator = loadedDrivers.iterator(); try{ while(driversIterator.hasNext()) { driversIterator.next(); } } catch(Throwable t) { // Do nothing } return null; } }); //…… 省去别的代码

ServiceLoader.load方法的代码如下,JDBC的sqlDriverManager就是这里获得的上下文加载器来驱动用户代码加载指定的类的。

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

那么这个上下文加载器是什么时候设置进去的呢?前面我们提到了:

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置,如果创建线程时候它还没有被设置,就会从父线程中继承一个,如果再应用程序的全局范围都没有设置过的话,那这个类加载器就是应用程序类加载器。

看下setContextClassLoader()方法别谁调用了,最终我们在Launcher中找到了如下代码:

public class Launcher { //……省去别的代码 public Launcher() { Launcher.ExtClassLoader var1; try { var1 = Launcher.ExtClassLoader.getExtClassLoader(); } catch (IOException var10) { throw new InternalError("Could not create extension class loader", var10); } try { this.loader = Launcher.AppClassLoader.getAppClassLoader(var1); } catch (IOException var9) { throw new InternalError("Could not create application class loader", var9); } Thread.currentThread().setContextClassLoader(this.loader); //……省去别的代码 } }

总结

这篇文章我们复习了类加载器的双亲委派模型、双亲委派模型的工作过程,以及打破双亲委派模型的必要性和源码分析。在第一部分的结尾,我们还演示了Arthas中关于类加载器的命令的用法,在实际排查问题时可以考虑使用。

参考资料

  1. https://www.journaldev.com/349/java-classloader#java-classloader-hierarchy
  2. https://www.cnblogs.com/joemsu/p/9310226.html
  3. 《深入理解Java虚拟机》
  4. 《码出高效Java开发手册》

本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题,为读者提供一线开发者的工作和成长经验,期待你能在这里有所收获。

原文链接:https://yq.aliyun.com/articles/720695
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章