JVM：类加载器的双亲委派模型

Posted 2021-04-18 漫步君

什么是类加载器？

通过一个类的全限定名来获取描述此类的二进制字节流，这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为类加载器。

比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使这两个类来源于同一个class文件、被同一个虚拟机加载，只要加载他们的类加载器不同，这两个类就必定是不相等的。

这里的相等是指类的equals()、isAssignableForm()和isInstance()方法的返回结果，也包括使用instanceof关键字进行对象所属关系判定等情况。

 

从Java虚拟机角度来说，只存在两种不同的类加载器

>启动类加载器：使用C++实现，是虚拟机的一部分（BootstrapClassLoader）

>所有其他的类加载器：由Java实现，独立于虚拟机外部，兵器而全部继承抽象类java.lang.ClassLoader

也可以分析更细致的3种

>启动类加载器（BootstrapClassLoader）：与上文相同，负责将存放在<JAVA_HOME>/lib目录中的或被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别（仅按照文件名如rt.jar识别，不符合规范的不会被加载）的类库加载到虚拟机内存中。

>扩展类加载器（ExtensionClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>/lib/ext目录中的，或者被java.ext.dirs系统变量指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

>应用程序类加载器（ApplicationClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader实现，也称为系统加载器。他负责加载用户类路径ClassPath上所指定的类库，开发者可以直接使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下它就是程序中默认的类加载器。

我们的应用程序都是由这三种类加载器互相配合进行加载的。如果有必要，还可以加入自己自定义的类加载器。这些类加载器都有一种层次关系，我们称之为：类加载器的双亲委派模型。

这种模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。父子关系不以Java中的继承实现，而以组合关系来复用父加载器代码。

工作流程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。因此所有加载器请求最终都应该传送到顶层的启动类加载器中；只有当父加载器反馈自己无法完成这个加载请求的时候，子加载器才会尝试自己去加载。如：java.lang.Object存放在rt.jar中，无论哪个加载最后都会委派给启动类加载器进行加载。因此Object在程序各种类加载器环境中都是同一个类。如果不是这样设计就会有多个不同的Object类。Java类型体系最基础的行为就无法得到保证，程序也将一片混乱。

实现原理其实很简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法中：

>先检查是否已被加载，若没有则调用父加载器的loadClass()；

>若父加载器为空则默认使用启动类加载器作为父加载器；

>如果父类也加载失败（抛出ClassNotFoundException异常，会在子类中catch住），再使用自身加载器findClass()进行加载；

>如果均加载失败则抛出ClassNotFoundException异常。

随笔，是记忆的一种延伸