JVM-虚拟机类加载机制-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_74763440/article/details/146566109

1.1 类加载的时机

一个类型从被加载到虚拟机内存开始，到卸载出内存为止，他的整个生命周期将会经历加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、准备、解析这三个部分统称为连接。这七个阶段的发生顺序如下：

1.2 类加载的过程

类加载的全过程，即加载、验证、准备、解析和初始化着五个阶段所执行的具体动作。

1.2.1 加载

加载是第一个阶段，这个阶段的针对对像是符合Class文件规范的二进制字节流，正如这句话所说的，这个二进制字节流可以来自Class文件也可以来自于网络、数据、内存或者动态生成等。在这个过程中主要完成一下三件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构【在整个类加载过程中，只有加载过程是处理字节流，之后的过程都是针对方法区中的动态数据结构】
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

相对于类加载过程的其他阶段，非数组类型的加载阶段，是开发人员可控性最强的阶段。加载阶段可以使用Java虚拟机内置的类加载器完成，也可以由用户自定义的类加载器完成，开发人员通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的findClass()和loadClass()方法），实现根据自己的想法莱夫于应用程序获取运行时代码的动态性。

对于数组类【https://zhuanlan.zhihu.com/p/83110138】而言，情况有所不同，数组类本身不通过类加载器创建，他是由Java虚拟机直接在内存中动态构造出来的。但不代表数组类就用不到类加载器，因为数组类的元素类型（Element Type，指的是数组去掉所有维度的类型【例如，对于String[][]数组，其元素类型是String；对于int[]数组，其元素类型是int。】）最终也还是要靠类加载器来完成。

科普：这里Element Type与数组类的关系以及为什么最终也还是要靠类加载器来完成？

数组类（如[Ljava.lang.String;【[L -> long; [I -> int;】）由JVM在运行时直接创建，但JVM需要根据Element Type生成对应的数组类结构。例如，String[]的类对象是JVM动态生成的，但其元素类型String必须由类加载器加载到内存中才能被正确解析。

一个数组类的创建过程遵循以下规则：
如果数组的组件类型为因引用类型，那就要递归加载这个组件类型，并且数组C及那个被标识在加载该组件类型的类加载器的类名称空间上。

如果数组的组件类型不是引用类型（就是int等），虚拟机将会把数组C标记为与启动类加载器关联。

数组类的可访问性与他的组件类型的可访问性一致，如果组件类型不是引用类型，他的数组类的可访问性默认为public，可被所有的类和接口访问到。

加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储再方法区之中了。类型数据加载如方法区之后，会在Java堆中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

其实再加载阶段与连接阶段的部分动作是交叉进行的【比如连接阶段的验证部分（字节码文件格式验证动作还是对二进制字节流的验证）】，但是这并不改变他们的执行先后顺序问题。

1.2.2 验证

简单点来说，他作为连接的第一步，最重要的作用就是防止有人通过二进制字节流直接恶意共计虚拟机，打个比方，我们有一个数组，当我们尝试再java程序中访问数组内存之外的【也就是数组边界溢出】的数据时，java会给你拦截下来报越界异常，这个二进制字节流根本没机会进入虚拟机执行，这是属于java程序编译就拦下来了，但是我们的二进制字节流不一定就来自于java程序，有可能是网络、数据库、内存等，甚至可能是有人可以编出来的，所以为了保护虚拟机的安全，这一步至关重要。

它分为四个阶段：

文件格式验证：主要是验证字节码文件是否合法【比如判断魔数、主次版本号、是否有非法常量类型、编码等等】，只有通过了这层验证，这个字节流才有机会再方法区存储。所以后面的三个阶段都是基于方法去的存储结构上进行的。

元数据验证：针对类的元数据信息进行语义校验【比如有没有父类（除了Object，其他都要有）、有没有继承final修饰的类等等类层面的语义错误或者访问权限错误】。

字节码验证：上面元数据验证针对的是类信息，而这里针对的则是方法体，这一块很耗费性能，所以JDK6以后这部分内容尽量移动至编译器时期判断，并将结果存再StackMapTable中，在这个阶段只需要做类型校验即可。

符号引用验证：针对符号引用转化为直接引用【比如能否通过字符串描述的全限定名找到对应的类、符号引用中类、方法、字段的访问性等】。这个验证主要是确保解析阶段的正常运行。

补充：

什么是符号引用？什么是直接引用？

符号引用：

以一组符号来描述所引用的目标；

符号引用可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可，符号引用和虚拟机无关；

在编译的时候每个java类都会被编译成一个class文件，但在编译的时候虚拟机并不知道所引用类的地址，所以就用符号引用来代替，而在解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。

并不规定虚拟机内存中必须要有引用对应的目标。

直接引用：

直接引用和虚拟机的布局有关，同样的符号引用在不同的虚拟机上翻译过来的直接引用可能是不同的。直接引用可以想象成指针，是直接指向内存中的某块具体区域的，所以有直接引用，那么内存中就肯定存在这个目标。

1.2.3 准备

准备阶段是正式为类中定义的变量（即静态变量【被static修饰的变量】）分配内存并设置变量的初始值的阶段。从概念上讲这些所使用的变量的内存应该都在方法去完成分配，但是在JDK7之前，Hotspot使用永久代来实现方法区的时候确实是这样的，但是在那之后方法区类变量随着Class对象一起存放进了Java堆中，所以这里体到的方法区就是一个逻辑概念的表述了。

在这里进行的内存分配仅仅包括类变量，不是实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次这里说的初始值在“通常情况”下都是数据类型的零值，比如：

public static int value = 123；

其实在准备阶段value会被赋值为int的零值0，而不是123，123实在初始化的阶段才会执行。

但是也有另外，如果是类常量【被final static修饰的常量】的话，就直接赋值，例如：

public final static int value = 123；

这里的value就是123；

注：基本数据类型零值

1.2.4 解析

解析就是讲符号引用替换为直接引用的过程；在《Java虚拟机规范》之中并未规定解析阶段发生的具体时间，只要求在一部分指定的用于操作符号引用的字节码指令之前，先对他们所使用的符号进行解析。所以解析阶段的发生时机可以是类被加载器加载时就对常量池的符号引用进行解析，或者等到第一个符号引用将要被使用前才去解析，这个取决于虚拟机根据需要自行判断。

除了一种“invokedynamic指令”例外情况，所有的可触发解析的指令都是“静态”的，即可以在刚刚完成加载阶段还没有开始执行代码时就提前解析。

刚刚提到的“invokedynamic指令”【invokedynamic详解：【JVM】字节码指令简介(四)-invokedynamic详解大家好，我是林师傅。本篇文章给大家介绍方法调用与返回指令第 - 掘金】，当碰到某个前面已经invokedynamic指令出发过解析的符号引用时，并不意味着这个解析结果对于其他invokedynamic指令也同样生效，因为invokedynamic指令的目的本来就是用于动态语言支持，他对应的引用称为“动态调用点限定符”，这里的动态就是指必须等到程序实际运行到这条指令时，解析动作才能进行。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7类符号引用。主要讲前面四种先。

1.2.4.1 类或接口的解析

假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机的完整解析包含以下三个步骤：

如果C不是一个数组类型，那么虚拟机会将代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中可能会触发其他相关的类的加载动作，比如加载这个类的父类等，有一个失败整个解析过程宣告失败。

如果C时一个数组类型，并且数组的元素类型为对象，也就是N的描述符会时类似“[Ljava/lang/Integer”【注：这里的[表示数组维度（[: 一维；[[：二维），L表示对象类型，分号;是类型终止符】的形式，那么就会按照第一点的规则先加载数组元素类型，如果N的描述符如前面锁枷社的形式，需要加载的元素类型就是“java.lang.Integer”，接着由虚拟机生成一个代表该数组维度和元素的数组类型。【这句话的核心是：数组类型是JVM动态生成的，但其元素类型的加载仍需遵循类加载规则。】

若代码中定义了Integer[] arr = new Integer[10]；
JVM检测到数组元素类型是java.lang.Integer（引用类型）。
通过类加载器加载java.lang.Integer类（若未加载过）。
JVM动态生成[Ljava/lang/Integer;类型的元数据，并分配内存空间

如果上述两步没有异常，最后一步就是检查D是否具备对C的访问权限。【JDK9以后引入模块化概念，还需要检查模块间的访问权限】。

1.2.4.2 字段的解析

要解析一个未被解析过的字段符号引用，首先会将字段表内的class_index像中的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用，解析成功，那把这个字段所属的类或接口用C表示，并按照如下步骤对C进行后续字段的搜索：

如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则直接返回这个字段的直接引用。

否则，如果C中实现了接口那么按照继承从下往上递归搜索各个接口和他的父接口有没有匹配的，有则返回。

否则，如果他不是java.lang.Object的话就按照继承关系由下向上递归搜索父类，有则返回。

否则查找失败，抛出NoSuchFieldError异常。

如果查找成功还需要访问权限验证。

1.2.4.3 方法的解析

方法解析的第一个步骤与字段解析一样，也是需要先解析出方法表的class_indexe项:索引的方法所属的类或接口的符号引用，如果解析成功，那么我们依然用C表示这个类接下来虚拟机将会按照如下步骤进行后续的方法搜索:

1)由于Class文件格式中类的方法和接口的方法符号引用的常量类型定义是分开的。如果在类的方法表中发现classindex中索引的C是个接口的话，那就直接抛出java.langIncompatibleClassChangeError 异常。

2)如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

3)否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用，查找结束。

4)否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C是一个抽象类，这时候查找结束，抛出AbstractMethodError 异常。

5)否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError最后，如果查找过程成功返回了直接引用，将会对这个方法进行权限验证，如果发现不具备对此方法的访问权限，将抛出IllegalAccessError 异常。

1.2.4.4 接口方法的解析

接口方法也是需要先解析出接口方法表的class_indexe项中索引的方法所属的类或接口的符号引用，如果解析成功，依然用C表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索:

1)与类的方法解析相反，如果在接口方法表中发现class_index中的索引C是个类而不是接口，那么就直接抛出java,lang.IncompatibleClassChangeError 异常。

2)否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

3)否则，在接口C的父接口中递归查找，直到java.lang.0bject类(接口方法的查找范围也会包括 Object类中的方法)为止，看是否有简单名称和描述符都与目标相匹配的方法如果有则返回这个方法的直接引用，查找结束。

4)对于规则3，由于Java的接口允许多重继承，如果C的不同父接口中存有多个简单名称和描述符都与目标相匹配的方法，那将会从这多个方法中返回其中一个并结束查找(Java虚拟机规范》中并没有进一步规则约束应该返回哪一个接口方法。但与之前字段查找类似地，不同发行商实现的Javac编译器有可能会按照更严格的约束拒绝编译这种代码来避免不确定性。

5)否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。

1.2.5 初始化

类的初始化阶段是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。我们也可以从另外一种更直接的形式来表达：

初始化阶段就是执行类构造器<clinit>()方法的过程。<clinit>()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物，但我们非常有必要了解这个方法具体是如何产生的，以及<clinit>()方法执行过程中各种可能会影响程序运行行为的细节，这部分比起其他类加载过程更贴近于普通的程序开发人员的实际工作。

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如下面代码所示。

非法前向引用变量：

public class Test {
    static {
        i = 0;  //  给变量复制可以正常编译通过
        System.out.print(i);  // 这句编译器会提示“非法向前引用”
    }
    static int i = 1;
}

<clinit>()方法与类的构造函数（即在虚拟机视角中的实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，Java虚拟机会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。因此在Java虚拟机中第一个被执行的<clinit>()方法的类型肯定是java.lang.Object。

由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作，

如下面代码中，字段B的值将会是2而不是1。

<clinit>()方法执行顺序：

static class Parent {
    public static int A = 1;
    static {
        A = 2;
    }
}
static class Sub extends Parent {
    public static int B = A;
}

public static void main(String[] args) {
    System.out.println(Sub.B);

<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

init和clinit方法

init和clinit方法执行时机不同

　 init是对象构造器方法，也就是说在程序执行 new 一个对象调用该对象类的 constructor 方法时才会执行init方法，而clinit是类构造器方法，也就是在jvm进行类加载—-链接—–初始化，中的初始化阶段jvm会调用clinit方法。init是instance实例构造器，对非静态变量解析初始化，而clinit是class类构造器对静态变量，静态代码块进行初始化。