类加载器的双亲委派,看这篇就够了

原文链接: mp.weixin.qq.com

本文阅读时间大约9分钟。

在上一篇文章中,我们梳理了类加载器的基本概念:类的生命周期、类加载器的作用、类的加载和卸载的时机等等,这篇文章我们接着前文继续复习类加载器的知识,主要包括: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的类加载器就是应用类加载器。

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

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

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

    上述代码的运行结果如下:

    例子3:Arthas中的classloader命令

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

    1. 输入classloader后展示的表格汇总了当前应用的类加载器、每个类加载器的实例个数、每个类加载器加载的类的个数。

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

    双亲委派模型的工作过程

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

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

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

      破坏双亲委派模型

      线程上下文加载器

      如上所述,双亲委派模型很好得解决了各个类加载器的基础类的统一问题(越基础的类由越上层的加载器进行加载),如果基础类又要回调用户的类该怎么办?一个非常经典的例子就是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驱动加载的入口。

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

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

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

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

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

          总结

          这篇文章我们复习了类加载器的双亲委派模型、双亲委派模型的工作过程,以及打破双亲委派模型的必要性和源码分析。在第一部分的结尾,我们还演示了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参数最佳实践:元空间的初始大小和最大大小

          彻底搞懂JVM类加载器:基本概念

          为什么Java进程使用的RAM比Heap Size大?

          一个MySQL时间戳精度引发的血案

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

          让我知道你“在看”