JVM 系列(6) —— JVM 类加载机制

类加载机制

Java 虚拟机把描述类的数据从 class 文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用。

类加载的时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期将会经历加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段。其中验证、准备和解析三个部分称为连接(Linking)。

其中加载、验证、准备、初始化、卸载 这五个阶段的顺序是确定的。

Java 虚拟机规定有且只有以下 6 中情况必须立即对类进行初始化：

1. 遇到 new、getstatic、putstatic、或 invokestatic 者四条字节码指令时，如果类型没有初始化，则需要先触发其初始化阶段。
   • 使用 new 关键字的时候
   • 获取静态字段的时候
   • 调用静态方法的时候
2. 使用 java.lang.reflect 包方法进行反射调用的时候，如果没有进行初始化，则需要先触发其初始化
3. 当类初始化时，如果发现其父类还没有初始化，则需要先触发其父类初始化。
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 的那个方法），虚拟机会先初始化这个主类
5. 当 JDK 7 新加入的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial 四个类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化
6. 当一个接口中定义了 JDK 8 新加入的默认方法（被 default 关键字修饰的接口方法） 时，如果这个接口的实现类发生了初始化，那该接口要在其之前进行初始化。

加载

加载是整个 “类加载” 过程中的一个阶段。在加载阶段，Java 虚拟机需要完成以下三件事情。

1. 通过一个类的全限定名来获取定义此类的二进制流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问接口

验证

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流包含的信息符合 《Java 虚拟机规范》 的全部约束需求， 保证这些信息被当做代码运行后不会危害虚拟机自身安全。

验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证

1. 文件格式验证 该阶段主要验证字节流是否符合 Class 文件规范，并且能够被当前版本的虚拟机进行处理。 该阶段的验证主要包含：

• 魔术开头
• 主次版本号是否在当前 Java 虚拟机的接受范围之内
• 常量池中是否有不被支持的常量类型
• 指向常量池中的各种索引值是否有指向不存在的常量或不符合了下的常量
• COUNST_utf8_info 型的常量中是否有不符合 utf8 编码的数据
• Class 文件中各个部分及文本文件是否有被删除或附加的其他信息

2. 元数据验证 该阶段是对字节码的描述进行语义分析，以保证其描述信息符合 《Java 语言规范要求》

该阶段会验证如下内容：

• 这个类是否有父类
• 这个类的父类是否继承了不允许被继承的父类
• 类中的字段，方法是否与父类产生矛盾

3. 字节码验证 该阶段主要通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的。该阶段会对方法体进行校验，保证被校验类的方法在运行时不会作出伤害虚拟机的行动

该阶段会验证如下内容：

• 任何指令都不会跳转到方法体以外的字节码指令上
• 保证方法体中类型转换总是有效的。

4. 符号引用验证 该阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将连接的第三阶段 —— 解析阶段中发生。符号引用验证可以看做是对类自身以外的各类信息进行匹配性校验，通俗来说就是该类是否缺少或者被禁止访问他依赖的某些外部类、方法、字段等资源。

该阶段会验证如下内容：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类
• 在指定类中是否存在符合方法的字段描述符及简单名称所描述的字段和方法
• 符号引用中的类、字段、方法的可访问属性(private、 protected、public、) 是否可被当前类访问。

准备

准备阶段是正式为类中的变量（即静态变量、被 Static 修饰的变量）分配内存并设置类变量初始值的阶段。 从概念上说所使用的内存都应当在方法区中进行分配，但必须到方法区本身是一个逻辑上的区域，在 JDK 1.7 及之前，HotSpot 使用永久代来实现方法区时，实现是完全符合这种逻辑的。在 JDK 1.8 之后，类变量则会随着class 对象一起存放在 Java 堆中。

在准备阶段，进行内存分配的仅包括类变量，而不包括实例变量。实例变量将会随着对象一起分配在 Java 堆中。实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。

解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程

• 符号引用 符号引用以一组符号来描述所引述的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。
• 直接引用 直接引用可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。

1. 类或接口的解析

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

1. 如果 C 不是一个数组类型，那虚拟机将会把代表 N 的全限定名传递给 D 的类加载器去加载类 C。在加载过程中，可能由于元数据验证或者字节码验证的需要，又可能触发其他类的相关动作。一旦加载过程中出现异常，解析过程将会宣告失败。
2. 如果 C 是一个数组类型，并且数组的元素类型为对象，也就是 N 的描述符会是类似 ‘[Ljava/lang/Integer’ 的形式。那将会按照第一点的规则加载数组的元素类型。接着由虚拟机生成一个代表该数组的维度和元素的数组对象。
3. 如果上两步没有任何异常，那么 C 在虚拟机中实际上已经称为了一个有效的类或接口了，但在解析完成前，还要进行符号引用验证，确认 D 是否对 C 具有访问权限。如果不具备访问权限，将抛出 java.lang.IllegalAccessError 异常

如何确定 D 对 C 的访问权限：

• C 是 public 的，且 D 与 C 处于同一模块
• C 是 public 的，且 D 与 C 不处于同一模块，但是 C 的模块允许被 D 访问
• C 不是 public 的，但是 C 与 D 处于同一个包中。

2. 字段解析

要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index 项中索引的 CONSTANT_Class_info 符号引用进行解析，也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析的失败。如果解析成功完成，那把这个字段所属的类或接口用C表示，《Java虚拟机规范》要求按照如下步骤对C进行后续字段的搜索：

1. 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
2. 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
3. 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
4. 否则，查找失败，抛出java.lang.NoSuchFieldError异常。

3. 方法解析

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

1. 由于Class文件格式中类的方法和接口的方法符号引用的常量类型定义是分开的，如果在类的方法表中发现class_index中索引的C是个接口的话，那就直接抛出java.lang.IncompatibleClassChangeError异常。
2. 如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3. 否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4. 否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C是一个抽象类，这时候查找结束，抛出java.lang.AbstractMethodError异常。
5. 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError。

4. 接口方法解析

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

1. 与类的方法解析相反，如果在接口方法表中发现class_index中的索引C是个类而不是接口，那么就直接抛出java.lang.IncompatibleClassChangeError异常。
2. 否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3. 否则，在接口C的父接口中递归查找，直到java.lang.Object类（接口方法的查找范围也会包括Object类中的方法）为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4. 对于规则3，由于Java的接口允许多重继承，如果C的不同父接口中存有多个简单名称和描述符都与目标相匹配的方法，那将会从这多个方法中返回其中一个并结束查找，《Java虚拟机规范》中并没有进一步规则约束应该返回哪一个接口方法。但与之前字段查找类似地，不同发行商实现的Javac编译器有可能会按照更严格的约束拒绝编译这种代码来避免不确定性。
5. 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。

初始化

初始化阶段就是执行类构造器 () 方法的过程。在初始化阶段，Java 虚拟机真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。在初始化阶段，虚拟机会根据程序员通过程序编码指定的主观计划去初始化类变量和其他资源。

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

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

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

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

Java虚拟机必须保证一个类的（）方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的（）方法，其他线程都需要阻塞等待，直到活动线程执行完毕（）方法。如果在一个类的 （）方法中有耗时很长的操作，那就可能造成多个进程阻塞[2]，在实际应用中这种阻塞往往是很隐蔽的。

类加载器

类加载器能够通过一个类的全限定名来获取该类的二进制字节流。该功能是 Java 外部进行实现的，以便让虚拟机自己决定如何获取所需要的类。

在 Java 虚拟机中每一个类加载器都有独立的名称空间。如果一个类被不同的类加载器加载，那么这两个类就不相等。

三层类加载器

• 启动类加载器（Bootstrap Class Loader） 前面已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
• 扩展类加载器（Extension Class Loader）： 这个类加载器是在类sun.misc.LauncherSExtClassLoader中以Java代码的形式实现的。它负责加载 \lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。
• 应用程序类加载器（Application Class Loader）： 这个类加载器由sun.misc.LauncherSAppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader（）方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

JDK9 之前的 Java 应用都是由这三种类加载器互相配合来完成加载的，如果用户认为有必要，还可以加入自定义的类加载器来进行拓展，典型的如增加除了磁盘位置之外的Class文件来源，或者通过类加载器实现类的隔离、重载等功能。

双亲委派模型

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

使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是 Java 中的类随着它的类加载器一起具备了一种带有优先级的层次关系。