JVM之类加载机制（八）

类加载机制

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

类加载的时机

类加载机制的整个生命周期将经历：

加载
验证
准备
解析
初始化
使用
卸载

其中验证，准备，解析三部分统称为连接。
加载，验证，准备，初始化，卸载这五个阶段的顺序是确定的，而解析阶段则不一定，他在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或者晚期绑定）。

关于在什么情况下进行类加载的第一个过程，JVM规范并没有强制约束，这点交给虚拟机的具体实现来自由把握，但是对于初始化阶段，JVM严格规定了有且仅有六种情况必须立即对类进行初始化（加载验证准备自然在此之前）：

遇到new，getstatic，putstatic或invokestatic四条字节码指令时，如果类型没有进行初始化，则需要先出发其初始化阶段，主要场景有：
- 使用new关键字实例化对象的时候
- 读取或设置一个类型的静态字段（被final修饰，已在编译期把结果放入常量池的静态字段除外）
- 调用一个类型的静态方法的时候
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要触发初始化
当初始化类的时候，如果发现其父类没有进行初始化，则需要先对父类进行初始化
当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类
当使用JDK 7新加入的动态语言支持时，如果使用一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类还没初始化，则需要先触发其初始化。
当一个接口定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那么该接口要在其之前被初始化

这六种场景中的行为被称为对一个类型的主动引用，除此之外，所有引用类型的方式不会触发初始化，称为被动引用。

被动引用的Demo

/**
 * 被动引用 Demo1:
 * 通过子类引用父类的静态字段，不会导致子类初始化。
 */
 
class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init!");
    }
}

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(SubClass.value);
        // SuperClass init!
    }

}

对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

/**
 * 被动引用 Demo2:
 * 通过数组定义来引用类，不会触发此类的初始化。
 */

public class NotInitialization {

    public static void main(String[] args) {
        SuperClass[] superClasses = new SuperClass[10];
    }

}

这段代码不会触发父类的初始化，但会触发“[L 全类名”这个类的初始化，它由虚拟机自动生成，直接继承自 java.lang.Object，创建动作由字节码指令 newarray 触发。

/**
 * 被动引用 Demo3:
 * 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
 */
class ConstClass {
    static {
        System.out.println("ConstClass init!");
    }

    public static final String HELLO_BINGO = "Hello Bingo";

}

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO_BINGO);
    }

}

编译通过之后，常量存储到 NotInitialization 类的常量池中，NotInitialization 的 Class 文件中并没有 ConstClass 类的符号引用入口，这两个类在编译成 Class 之后就没有任何联系了。

接口的加载过程

接口的加载过程与类加载过程稍有不同。
当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部完成了初始化，当真正用到父接口的时候才会完成初始化。

类加载的过程

加载

在加载过程，JVM需要完成以下三件事情：

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

获取二进制字节流

从zip包中读取，jar，war，ear
从网络中读取，Web Applet
运行时计算生成，使用最多的是动态代理技术
由其他文件生成，典型场景是JSP应用，由JSP生成对应的Class文件
从数据库中读取
从加密文件中获取

非数组类型与数据类加载比较

非数组类型的加载阶段可以使用JVM内置的引导类加载器，也可以使用用户自定义的类加载器，开发人员通过定义自己的类加载器区控制字节流的获取方式（重写一个类加载器的findClass()或loadClass()）
数组类本身不通过类加载器创建，它通过JVM直接在内存中动态构造出来的，再由类加载器创建数组中的元素类

验证

目的是确保Class文件的字节流中包含的信息符和JVM规范中的全部约束要求。保证这些信息被当作代码运行后不会危害JVM自身的安全。

验证的过程

文件格式验证：验证字节流是否符和Class规范，并且能被当前版本的虚拟机处理，这一阶段包括以下验证点：
- 是否以魔数0xCAFEBABE开头
- 主次版本号是否在当前JVM处理范围内
- 常量池的常量是否有不被支持
- 指向常量的索引值中是否有不存在的常量或不符合类型的常量
- CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据
- Class文件中各个部分以及文件本身是否有被删除的或附加的其他信息
元数据验证：对字节码描述的信息进行语义分析，以保证其描述信息符和Java语言规范
- 这个类是否有父类（除Object之外，所有的类都有父类）
- 这个类是否继承了不被允许继承的类（被final修饰的类）
- 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
- 类中的字段、方法是否与父类产生矛盾
字节码验证：通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的。
- 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
- 保证任何跳转指令都不会跳转到方法体意外的字节码指令上
- 保证方法体中的类型转换总是有效的
符号引用验证：发正在解析阶段，可以看作是对类自身以外的各类信息进行匹配性验证，确定该类是否缺少或者被禁止访问它以来的某些外部类、方法、字段等资源，本阶段需要校验以下内容：
- 符号引用中通过字符串描述的全限定名是否能找到对应的类
- 在指定类中是否存在符和方法的字段描述符以及简单名称所描述的方法和字段
- 符号引用中的类、字段、方法的可访问性是否可被当前类访问

准备

准备阶段是正式为类中定义的变量（静态变量）分配内存并设置类变量初始值的阶段。这些变量（不包括实例变量）所使用的内存都在方法区中进行分配。
初始值“通常情况下”是数据类型的零值（0, null…），假设一个类变量的定义为：

public static int value = 123;

那么变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时候尚未开始执行任何 Java 方法。

存在“特殊情况”：如果类字段的字段属性表中存在 ConstantValue 属性，那么在准备阶段 value 就会被初始化为 ConstantValue 属性所指定的值，假设上面类变量 value 的定义变为：

public static final int value = 123;

那么在准备阶段虚拟机会根据 ConstantValue 的设置将 value 赋值为 123。

解析

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

类或接口的解析
字段解析
方法解析
接口方法解析

初始化

初始化阶段就是执行内构造器<clinit>()方法的过程，此方法是由Javac自动生成的。

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而产生的。收集顺序由语句在源代码中出现的顺序决定

静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但不能访问。如下方代码所示：

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

<clinit>()方法与类的构造方法不同，它不需要显式地调用父类构造器，JVM会保证在子类地<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。

由于父类的<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); // 输出 2
}

<clinit>()方法不是必需的，如果一个类中没有静态代码块，也没有对类变量的赋值操作，那么编译器将不生成<clinit>()方法。

接口中不能使用静态代码块，但接口也需要通过 <clinit>() 方法为接口中定义的静态成员变量显式初始化。但接口与类不同，接口的<clinit>() 方法不需要先执行父类的<clinit>() 方法，只有当父接口中定义的变量使用时，父接口才会初始化。

JVM必须保证一个类的<clinit>()方法在多线程环境中能被正常的加锁同步，如果多个线程区执行<clinit>()方法，那么只会有一个线程能执行<clinit>()方法，其他线程需要阻塞等待。直至活动线程执行完毕。

类加载器

任意一个类，都必须由类加载器和这个类本身共同确立其在JVM中的唯一性。每个类加载器都有一个独立的类名称空间。

因此要比较两个类是否相等，只有在这两个类是同一个类加载器加载的前提下才有意义，否则即使两个类来源于同一个Class文件，被同一个JVM加载，只要类加载器不同，这两个类就必定不相等。

这里的相等代表类的Class对象的equals方法，isAssignableFrom()方法，inInstance()方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定的各种情况。

双亲委派模型

JVM存在三层类加载器：

启动类加载器（Bootstrap ClassLoader）
- 负责加载存放在<JAVA_HOME>\lib目录，或被-Xbootclasspath参数指定的目录存放的，而且能被JVM识别的（如rt.jar,tools.jar）类库加载到内存中
扩展类加载器（Extension Classloader）
- 负责加载<JAVA_HOME>\lib\ext目录中，或被java.ext.dirs系统变量所指定的路径中所有的类库
应用程序类加载器（Application Classloader）
- 也称为系统类加载器，负责加载用户类路径上的所有类库。

类加载器之间的层次关系被称为类加载器的双亲委派模型，双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应有自己的父类加载器。

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

使用双亲委派模型的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如Object类由启动类加载器加载，同时也是所有类的父类。

Java > JVM

#Java #JVM

JVM之类加载机制（八）

https://l1n.wang/2020/JVM/jvm08-class-load/

作者

Lin Wang

发布于

2020年3月28日

许可协议

JVM之字节码执行引擎（九）上一篇

JVM之字节码指令（七）下一篇