发表更新读书笔记 / 深入理解Java虚拟机39 分钟读完 (大约5915个字)0次访问

虚拟机类加载机制

“代码编译的结果从本地机器码转变为字节码，是存储格式发展的一小步，却是编程语言发展的一大步。”

—— 周志明 《深入理解Java虚拟机：JVM高级特性与最佳实践（第2版）》

以下内容整理自周志明《深入理解Java虚拟机：JVM高级特性与最佳实践（第2版）》

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

类加载时机

类的生命周期

类的生命周期

  • 加载 Loading
  • 连接 Linking
    • 验证 Verification
    • 准备 Preparation
    • 解析 Resolution
  • 初始化 Initialization
  • 卸载 Unloading

其中，加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序开始（并非进行 或 完成）。解析阶段在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定。

必须对类进行初始化的情况

虚拟机严格规定有且只有以下5种情况必须立即对类进行[初始化](#初始化)（而加载、验证、准备自然需要在此之前开始）：

  1. 遇到new、getstatic、putstatic或invokestatic这4条字节码指令，如果类没有进行过初始化，则需要先触发其初始化。典型场景：
    • 使用new关键字实例化对象时
    • 读取或设置一个类的静态字段时（被final修饰的静态字段除外）
    • 调用一个类的静态方法时
  2. 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
  3. 初始化一个类时，如果其父类还没有进行过初始化，则需要先触发其父类的初始化。
  4. 当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类。
  5. 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

主动引用和被动引用

  • 主动引用：以上五种场景中的行为称之为对一个类进行主动引用
  • 被动引用：除主动引用外，所有引用类的方式称为被动引用，不会触发类初始化，常见例子：
    • 通过子类引用父类的静态字段，不会导致字类初始化
    • 通过数组定义来引用类，不会触发此类初始化
    • 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，不会触发定义常量的类的初始化

接口与类加载过程的区别

  • 接口也有初始化过程
  • 在第3种类需要开始初始化的场景中，接口在初始化时，并不要求其父接口全部都完成了初始化，只有在用到父接口的时候才会初始化。

类加载过程

加载

在加载阶段，虚拟机需要完成以下3件事情：

  1. 通过一个类的全限定名获取定义此类的二进制字节流
    • 未指明从何处、怎样获取。应用实例：
      • 从ZIP包中读取：JAR、EAR、WAR
      • 从网络中获取：Applet
      • Proxy，代理类的二进制字节流
      • 由其它文件生成：JSP
      • 从数据库中读取
    • 对于非数组类，开发人员可以通过自定义的类加载器控制字节流的获取方式。
    • 对于数组类，由Java虚拟机直接创建。遵循以下规则：
      • 数组组件类型是引用类型，递归采用加载过程加载组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识
      • 数组组件类型不是引用类型，Java虚拟机会把数组C标记为与引导类加载器关联
      • 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，数组类的可见性默认为public
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
    • 二进制字节流按照虚拟机所需格式存储在方法区中
    • 方法区中的数据存储格式由虚拟机实现自行定义
  3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
    • 并未明确规定存储在Java堆中
    • 对于HotSpot虚拟机，Class对象存放在方法区中

注：加载阶段与连接阶段的部分内容是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证阶段的目的：确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

Java语言本身是相对安全的语言（相对于C/C++），但Class文件不一定由Java源码编译而来，在字节码语言层面上，可能会因为载入有害字节流导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

验证阶段大致会完成4个阶段的检验动作

  1. 文件格式验证
    • 验证字节流是否符合Class文件格式的规范，并且能被当前版本虚拟机处理
    • 可能包括的验证点：
      • 是否以魔数 0xCAFEBABE 开头
      • 主、次版本号是否在当前虚拟机处理范围之内
      • 常量池中是否有不被支持的常量类型
      • 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
      • …
    • 通过这个阶段验证后，字节流进入内存方法区中进行存储，后面3个验证阶段全部是基于方法区的存储结构进行的
  2. 元数据验证
    • 对字节码描述的信息进行语义分析，保证其描述的信息符合Java语言规范的要求
    • 可能包括的验证点：
      • 这个类是否有父类（除了java.lang.Object之外）
      • 这个类的父类是否继承了不允许被继承的类（被final修饰的类）
      • 如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法
      • 类中的字段、方法是否与父类产生矛盾
      • …
  3. 字节码验证
    • 通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的
    • 对类的方法体进行的校验分析，例如：
      • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
      • 保证跳转指令不会跳转到方法体以外的字节码指令上
      • 保证方法体中的类型转换是有效的
      • …
  4. 符号引用验证
    • 发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在[解析](#解析)阶段中发生
    • 目的是确保解析动作能正常执行
    • 对类自身之外（常量池中的各种符号引用）的信息进行匹配性校验
    • 通常需要检验的内容：
      • 符号引用中通过字符串描述的全限定名是否能找到对应的类
      • 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
      • 符号引用中的类、字段、方法的访问性是否可被当前类访问
      • …
    • 如果无法通过验证，将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如：
      • java.lang.IllegalAccessError
      • java.lang.NoSuchFieldError
      • java.lang.NoSuchMethodError
      • …

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。

  • 进行内存分配的仅包括类变量（被static修饰的变量）
  • 关于初始值
    • 通常情况下是数据类型的零值
    • 特殊情况：类字段的字段属性表中存在ConstantValue属性，变量会被初始化为ConstantValue属性所指定的值

解析

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

直接引用与符号引用

  • 符号引用（Symbolic References）
    • 以一组符号描述所引用的目标
      • 符号可以是任意形式的字面量
      • 满足使用时能无歧义地定位到目标即可
    • 与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中
  • 直接引用（Direct References）
    • 直接引用可以是：
      • 直接指向目标的指针、相对偏移量
      • 能间接定位到目标的句柄
    • 与虚拟机实现的内存布局相关，引用的目标必定已经在内存中存在

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。后面3种与JDK 1.7新增的动态语言相关。

前4种引用的解析过程

  • 类或接口的解析

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

    1. 如果C不是一个数组类型，虚拟机会把代表N的全限定名传递给D的类加载器去加载类C
    2. 如果C是一个数组类型，并且数组的元素类型为对象，会按照第1点的规则加载数组元素类型，接着由虚拟机生成一个代表此数组维度和元素的数组对象
    3. 如果上面步骤没有出现任何异常，C在虚拟机中实际上已经成为一个有效的类或接口，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。如果发现不具备访问权限，将抛出java.lang.IllegalAccessError异常

  • 字段解析

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

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

    2. 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束

    3. 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束

    4. 否则，查找失败，抛出java.lang.NoSuchFieldError异常

      如果查找过程中成功返回了引用，将会对这个字段进行权限验证，如果不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

      在实际应用中，虚拟机的编译器实现可能会比上述规范要求更加严格。
      如果有一个同名字段同时出现在C的接口和父类中，或者同时在自己或父类的多个接口中出现，编译器将可能拒绝编译。

  • 类方法解析

    类方法解析的第一个步骤与字段解析相同。如果解析成功，将这个方法所属的类用C表示，接下来虚拟机会按照如下步骤进行后续类方法搜索：

    1. 类方法和接口方法符号引用的常量定义是分开的，如果在类方法表中发现class_index中索引的C是个接口，直接抛出java.lang.IncompatibleClassChangeError异常

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

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

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

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

      如果查找过程成功返回了直接引用，将会对这个进行权限验证，如果不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

  • 接口方法解析

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

    1. 与类方法解析不同，如果在接口方法表中发现class_index中的索引C是类而不是接口，直接抛出java.lang.IncompatibleClassChangeError异常

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

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

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

      由于接口中的所有方法默认都是public的，所以不存在访问权限的问题，因此接口方法的符号引用解析应当不会抛出java.lang.IllegalAccessError异常

初始化

在前面的类加载过程中，除了在[加载](#加载)阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中的字节码。

在准备阶段，变量已经赋过一次初始值，在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源。（执行类构造器<clinit>()方法的过程）。

关于<clinit>()方法

  • <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并生成的

    • 收集顺序是由语句在源文件中出现的顺序决定的
    • 静态语句块只能访问到定义在静态语句块之前的变量
    • 静态语句块对定义在它之后的变量可以赋值，但不能访问
      1
      2
      3
      4
      5
      6
      7
      8
      9
      public class Test {
      	static {
      		// 给变量赋值可以正常编译通过
      		i = 0;
      		// 这句话编译器会提示"非法向前引用"
      		System.out.print(i);
      	}
      	static int i = 1;
      }

  • <clinit>()方法与实例构造器<init>()方法不同

    • 不需要显式地调用父类构造器，虚拟机会保证父类的<clinit>()方法已经执行完毕

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

    • 下例中，字段B的值是2
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      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>()方法的异同

    • 接口中不能使用静态语句块，但有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法
    • 接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，只有当父接口中定义的变量使用时，父接口才会初始化
    • 接口的实现类在初始化时一样不会执行父接口的<clinit>()方法

  • 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步

    • 如果多个线程同时去初始化一个类，只会有一个线程去执行这个类的<clinit>()方法，其他线程需要阻塞等待，直到活动线程执行<clinit>()方法完毕
    • 如果一个类的<clinit>()方法中有耗时很长操作，可能造成多个线程阻塞

类加载器

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

类与类加载器

类加载器虽只用于实现类的加载动作，但它在Java程序中起到的作用远远不限于类加载阶段。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。每个类加载器，都拥有一个独立的类名称空间。

这也就是说，比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。这里说的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判断等情况。

类加载器的种类

从Java虚拟机的角度来讲，只存在两种类加载器：

  • 启动类加载器（Bootstrap ClassLoader）
    • 使用C++实现（仅限于HotSpot）
    • 虚拟机自身的一部分
  • 所有其他的类加载器
    • 虚拟机外部
    • 继承自抽象类java.lang.ClassLoader

从Java开发人员角度来看，类加载器可以划分得更细致一些，绝大部分Java程序都会使用到以下3种系统提供的类加载器：

  • 启动类加载器（Bootstrap ClassLoader）
    • 将<JAVA_HOME>/lib目录中的，或者被-Xbootclasspath参数指定的路径中的虚拟机识别的类库加载到虚拟机内存中，
    • 无法被Java程序直接引用
      • 如果需要把加载请求委派给引导类加载器，直接使用null即可
  • 扩展类加载器（Extension ClassLoader）
    • 由sun.misc.Launcher $ExtClassLoader实现
    • 负责加载<JAVA_HOME>/lib/ext目录中的，或被java.ext.dirs系统变量所指定的路径中的所有类库
    • 开发者可以直接使用
  • 应用程序类加载器（Application ClassLoader）
    • 由sun.misc.Launcher $AppClassLoader实现
    • 一般也称为系统类加载器
    • 负责加载用户类路径（ClassPath）上所指定的类库
    • 开发者可以直接使用
    • 如果应用程序没有自定义过自己的类加载器，一般默认情况下使用此类加载器

双亲委派模型

加载器之间的关系
双亲委派模型

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。类加载器之间的关系不会以继承关系来实现，而是都使用组合关系来复用父加载器的代码。

工作过程：
如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。只有当父类加载器反馈自己无法完成这个加载请求时，自类加载器才会尝试自己去加载。

意义：

  • Java类随着类加载器一起具备了带有优先级的层次关系
  • 保证Java程序稳定运作
  • 实现简单，实现双亲委派的代码集中在java.lang.ClassLoader的loadClass()方法之中

破坏双亲委派模型

双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。

到目前为止，双亲委派模型出现出3次较大规模的被破坏的情况。

  1. JDK 1.2发布之前
    • 双亲委派模型在JDK 1.2之后才被引入，而类加载器在JDK 1.0已经存在，需要向前兼容
    • 添加了新的protected方法findClass()
  2. 模型自身缺陷
    • 基础类可能需要调用回用户代码（JNDI）
    • 解决：线程上下文类加载器（Thread Context ClassLoader）
  3. 对程序动态性追求
    • 动态性：代码热替换、模块热部署等

虚拟机类加载机制

http://huangxiao.info/2018/05/11/class-loader/

作者

Shawn Huang

发布于

2018-05-11

更新于

2021-12-08

许可协议

#

评论

归档

标签

Algorithm1
Arch1
Interview2
JVM3
Linux2
Original5
Streaming Systems4
×