SilverLining's Blog

JVM 类加载机制

SilverLining

类加载的时机

一个 Class 从被加载到 JVM 内存中开始，到卸载出内存位置，整个生命周期历经七个阶段：

其中，验证、准备和解析三个部分统称为连接（Linking）。

什么情况下虚拟机需要开始加载一个类，在虚拟机规范中并没有对此进行强制约束，这点可以交给虚拟机的具体实现来自由把握。

加载 Loading

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

对于非数组类型，获取类的二进制字节流的阶段是我们 JAVA 开发人员最关注的阶段，也是操控性最强的一个阶段。

在这个阶段我们可以通过重载 ClassLoader 的 findClass()或 loadClass()方法来实现自定义类加载器完成加载，或者通过 JAVA Agent 来完成字节码增强操作。

加载阶段结束后，Java 虚拟机外部的二进制字节流就已经按照虚拟机所设定的格式存储在方法区之中了。

方法区：类信息，静态变量，常量
堆：代表被加载类的 java.lang.Class 对象

即时编译（JIT）生成的热点代码并不在这个阶段进入方法区。

验证 Verification

验证阶段大致包含四个步骤：

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响。如果所引用的类经过反复验证，那么可以考虑采用-Xverif:ynone 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备 Preparation

准备阶段是正式为类变量（static 修饰的静态变量）分配内存并设置类变量初始值（零值）的阶段，这些变量所使用的内存都将在方法区中进行分配。

需要注意的是，方法区本身是一个逻辑区域。在 JDK 7 之前，HotSpot 使用永久代来实现方法区；而在 JDK 8 及之后，类变量则随着 Class 对象一起分配在堆中，“类变量在方法区” 就完全是对逻辑概念的表述了。

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

public static int value = 123;

变量 value 在准备阶段过后的值为 0 而不是 123，因为这时候尚未开始执行任何 java 方法，而把 value 赋值为 123 的 putstatic 指令是程序被编译后，存放于类构造器方法<clinit>()之中，所以把 value 赋值为 123 的动作将在初始化阶段才会执行。

至于 “特殊情况” 是指：当类字段的字段属性是 ConstantValue 时，会在准备阶段初始化为指定的值。如：

public static final int value = 123;

编译时 javac 会为 value 生成 ConstantValue 属性，在准备阶段虚拟机就会根据 ConstantValue 的设置将其赋值为 123 而非 0 。

解析 Resolution

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符 7 类符号引用进行。

直接引用是与虚拟机内存布局实现相关，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般
不会相同。

如果有了直接引用，那引用的目标必定存在内存中。

同一符号引用进行多次解析请求是很常见的，除了 invokedynamic 指令以外，虚拟机实现可以对第一次解析结果进行缓存，来避免解析动作重复进行。无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个引用符号之前已经被成功解析过，那么后续的引用解析请求就应当一直成功；同样的，如果第一次解析失败，那么其他指令对这个符号的解析请求也应该收到相同的异常。

invokedynamic 是 JDK 7 引入的一条新的虚拟机指令，它允许由应用级的代码来决定方法解析。这是自 JDK 1.0 以来第一次引入新的虚拟机指令。

到了 JDK 8，有了 Lambda 表达式和接口的默认方法，这条指令才用在 Java 语言中应用，用在 lambda 表达式中。

初始化

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

在准备阶段，静态变量已经赋过零值；而在初始化阶段，则根据程序猿通过程序制定的主观计划去初始化类变量和其他资源，或者更直接地说：初始化阶段是执行类构造器<clinit>()方法的过程。

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

静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。

public class Test {
    static {
        i = 0;  // 给变量赋值可以通过编译
        System.out.println(i);  // illegal forward reference
    }
    static int i = 1;
}

类构造器<clinit>()与实例构造器<init>()不同，它不需要程序员进行显式调用，虚拟机会保证在子类类构造器<clinit>()执行之前，父类的类构造<clinit>()执行完毕。

由于父类的构造器<clinit>()先执行，也就意味着父类中定义的静态语句块的初始化要优先于子类的静态语句块的初始化执行。

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

Java 虚拟机必须保证一个类的类构造器<clinit>()在多线程环境中被正确的加锁同步。如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的类构造器<clinit>()，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

在这种情形下，其他线程虽然会被阻塞，但如果执行<clinit>()方法的那条线程退出后，其他线程在唤醒之后不会再次执行<clinit>()方法。在同一个类加载器下，一个类型只会被初始化一次。

如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。

static class DeadLoopClass {
    static {
        // Cannot compile without if：initializer must be able to complete normally
        if (true) {
            System.out.println(Thread.currentThread() + "init DeadLoopClass");
            while (true) {
            }
        }
    }
}

public class Test {
    public static void main(String[] args) {
        Runnable script = new Runnable() {
            @Override
            public void run() {
                System.out.println(Thread.currentThread() + "start");
                DeadLoopClass dlc = new DeadLoopClass();
                System.out.println(Thread.currentThread() + "run over");
            }
        };

        Thread t1 = new Thread(script);
        Thread t2 = new Thread(script);
        t1.start();
        t2.start();
    }
}

// 输出
// Thread[Thread-1,5,main]start
// Thread[Thread-0,5,main]start
// Thread[Thread-1,5,main]init DeadLoopClass

类加载器

No related posts.