Java虚拟机类加载机制-双亲委派模型

向右看齐 2023-06-24 04:49 12阅读 0赞

**目录**

•写在前面

•类加载的时机

•类加载的过程

加载

验证

准备

解析

初始化

•类加载器

--------------------

# •写在前面 #

其实类加载机制并不是很神秘，可以说我们无时无刻不在是由类加载，只是很多时候我们不需要关注类加载机制会给我们带来啥影响，不过如果你深入了解类加载机制的原理，你就会发现，原来我们日常代码是这样运行的，甚至对代码编写的各类继承、本地库方法、网络间方法，来点以前没敢尝试过的骚操作。类加载为啥有这么有意思，它是啥？如果我们有接触过C/C++语言，咋没有人重视类加载机制，原因是因为C/C++是属于在编译时需要连接工作的语言，而java的类型加载、连接和初始化过程都是在运行期间完成的，这种策略虽然令类加载时稍微增加了一些性能开销，但是为java应用程序提供高度的灵活性，java天生可以动态扩展的语言特性就是依赖运行期动态加载和加载连接这个特点实现的。给你举个例子，如果我们将一个类型序列化储存在服务端或者数据库中，这个时候，我们可以通过程序获得这个字节流，在java运行时，将字节流反序列化并加载进程序中，从而将这个类加载进程序中，这个方式你在C++中敢想嘛。java的这种方式已经非常广泛的运用了，而且特别好用（这里没有说C++不好，毕竟java的加载器是用C++实现的，哈哈哈）。

# •类加载的时机 #

类从被加载到虚拟机内存中开始，到写在出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用、卸载这七个阶段。其中验证、准备、解析3个部分统称为连接，大概如下面的这个图。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70][]

值得一提的是，加载、验证、准备、初始化和写在这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的开始，而解析阶段则不一定。注意了，只保证了五个阶段按顺序开始，并不保证它们按顺序完成。虚拟机什么情况下需要开始类加载过程的第一个阶段呢？在这里大致提一下，java虚拟机规范严格规定了有且只有5种情况必须立即对类警醒“初始化”（而加载、验证、准备自然需要在这之前开始），其他不进行强制约束，哪5种情况？

•遇到new、genstatic、pustatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发初始化（不了解字节码的可以看看我另一篇文章，[java类文件结构][java]），至于我们在代码中生成这4条指令的场景：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候、以及调用一个类的静态方法的时候。

•使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发初始化。

•当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

•当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类。

•当使用动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF\_getStatic，REF\_putStatic、REF\_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

# •类加载的过程 #

接下来我们详细讲解一下java虚拟机中类加载的全过程，也就是加载、验证、准备、解析、初始化这个5个阶段。

## 加载 ##

首先要明确的是，不要混淆了“加载”和“类加载”，加载只是类加载的一个阶段，而在加载阶段，虚拟机规范中规定了虚拟机需要完成一下三件事儿：

1、通过一个类的全限定名来获取定义此类的二进制字节流（啥是全限定名，看我另一篇文章[类文件结构][java]）；

2、将这个字节流所代表的的今天存储结构转化为方法区的运行时数据结构；

3、在内存中生成一个代表这个类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口;

由于java虚拟机定义的这个规范并不具体，像没有明确规定我们从哪里读取这个二进制字节流，所以这个使得我们可以使用很多方便牛逼的技术，比如我们可以从ZIP包中读取（经常使用的JSR、EAR、WAR格式就是这个）、我们还可以从网络中获取（如果你听说过Applet的话），我们还可以在运行时计算生成（动态代理技术就是这个），还有比如JSP文件生成对应的Class类，还有从数据库中读取等等。

值得一提的是，一个非数组类的加载阶段是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成（类加载器后面将）。而数据类是不通过类加载器创建，而是由java虚拟机直接创建的（不过要提醒的是，这里数据类指的是如String\[\]，而不是里面存的String，里面存的String还是通过类加载器完成的）。

## 验证 ##

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。java语言本身是相对安全的语言，使用纯粹的java代码无法做到像访问数组边界以外的数据、将一个对象转型为它并未实现的类型、跳转不存在的代码行之类的事情，如果这样做了，编译器将拒绝编译。不过前面已经说了，class文件并不一定要求用java源码编译而来，可以使用任何途径产生，甚至直接用十六进制编辑器直接编写来产生class文件，在字节码语言层面上，上述java代码无法做到的事情都是可以实现的，至少语义上是可以表达出来的，虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入有害的字节流而导致系统崩溃。那一般验证什么呢？无非验证class文件是否符合Class文件格式的约束（Class文件有哪些约束，看文章[类文件结构][java]），包含格式检验总共是四样，分别是文件格式检验、元数据检验、字节码验证、符号引用验证。

值得一提的是，对于虚拟机类加载机制来说，验证阶段是一个非常重要的，但不是一定必要的阶段，如果所运行的全部代码都已经被反复使用和验证过了，那么在实施阶段就可以考虑关闭大部分的类验证措施，以缩短虚拟机类加载的时间（可以使用-Xverify:none参数来关闭）

## 准备 ##

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区进行分配。这个阶段中又两个容易产生混淆的概念需要强调一下，首先，这时候进行内存分配的仅仅包括类变量（被static修饰的变量）而不包括实例变量，实例变量将会在对象实例化是随着对象一起分配在Java堆中，其次，这里所说的初始值“通常情况”下是数据类型的零值。举个简单的例子，假设一个类变量的定义如下:public static int value = 123;那变量的value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何java方法，而把value值赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

当然啦，这些都是在“通常情况”，那相对的会有一些“特殊情况”，如果类字段的字段属性表中存在ConstantValue属性，那再准备阶段变量value会被初始化为ConstantValue属性所指定的值，假设上面类变量value的定义变为：public static final int value = 123;编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123.

## 解析 ##

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用可看[类文件结构][java]，对同一个符号引用进行多次解析请求是非常常见的事情，出了invokedynamic指令以外，虚拟机实现可以对第一次解析的结果进行缓存（在运行常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。无论是否真正执行了多次解析动作，那么后续的引用解析请求就应当一直成功，同样的，如果第一次解析失败了，那么其他指令对这个符号解析请求也应该收到相同的异常。

符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。

直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在。

## 初始化 ##

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义加载器参与之外，其余动作完全由虚拟机主导和控制，到了初始化阶段，才真正开始执行类中定义的java程序代码。初始化阶段是执行类构造器<client>方法的过程。<client>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证<client>方法执行之前，父类的<client>方法已经执行完毕。p.s: 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成<client>()方法。

# •类加载器 #

类加载器虽然只用于实现类的加载动作，但它在java程序中起到作用却远远不限于类加载阶段，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一点，比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。这里所指的相等，包括代表类的class对象的equals方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。类加载的有四种，如下。

启动类加载器(Bootstrap ClassLoader)：负责加载 JAVA\_HOME\\lib 目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类；扩展类加载器(Extension ClassLoader)：负责加载 JAVA\_HOME\\lib\\ext 目录中的，或通过java.ext.dirs系统变量指定路径中的类库；应用程序类加载器(Application ClassLoader)：负责加载用户路径（classpath）上的类库；当然我们也可以通过继承java.lang.ClassLoader实现自定义的类加载器。

![20191220194848645.png][]

值得一提的是，从java虚拟机的角度来讲，只存在两种不同的类加载器，一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分。另一种就是所有其他的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且都继承自抽象类java.lang.ClassLoader。

别小看上面的图，上面的图表现了类加载器之间的层次关系，成为类加载器的双亲委派模型，注意，这里的类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。大概逻辑和下面代码差不多。

protected synchronized Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException {
        // First, check if the class has already been loaded
        Class c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClass0(name);
                }
            } catch (ClassNotFoundException e) {
                // If still not found, then invoke findClass in order
                // to find the class.
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }

当一个类加载器收到类加载任务，会先交给其父类加载器去完成，因此最终加载任务都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，才会尝试执行加载任务。采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。

注意哦，双亲委派模型并不是一个强制性的约束模型，而是案卷设计者推荐给开发者的类加载器实现方式，大部分的类加载器都遵循的这个模型。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191220165450568.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE=,size_16,color_FFFFFF,t_70
[java]: https://blog.csdn.net/DBC_121/article/details/103615254
[20191220194848645.png]: https://img-blog.csdnimg.cn/20191220194848645.png