类加载器的双亲委派模型

类加载器的知识，主要包括：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中关于类加载器的命令的用法，在实际排查问题时可以考虑使用。