Java 杂谈细说JVM程序员

细说JVM（类加载机制）

2018-08-07  本文已影响6人  Jivanmoon

一、类加载的时机

从类被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期分为7个阶段，加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)。其中验证、准备、解析三个部分统称为连接。
7个阶段发生的顺序如下：


20160602122102170.png

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

对于类加载的时机，Java虚拟机规范中并没有进行强制的约束，但是对于初始化阶段，虚拟机规范严格规定了5种情况下必须对类进行初始化（类的加载、验证、准备就在这之前开始），这5中情况分别是：

这五种情况是Java虚拟机规范规定的主动初始化一个类的情况，除此之外的任何其他引用一个类的情况都不会主动初始化这个类，这叫做被动引用。下面以三个例子说明什么是被动引用：

1、通过子类引用父类的静态字段，并不会初始化子类

代码如下：

package temp;
class SuperClass {
    static{
        System.out.println("Super Class init.");
    }
    public static int value=123;
}

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

class Test1 {
    @SuppressWarnings("unused")
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

结果为：


TIM截图20180807155242.png

可以看到，并没有输出SubClass init.，对于静态字段，只有直接定义这个字段的类才会被初始化。

2、通过数组定义来引用类，不会触发此类的初始化

代码如下：

package temp;
class SuperClass {
    static{
        System.out.println("Super Class init.");
    }
    public static int value=123;
}

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

class Test1 {
    @SuppressWarnings("unused")
    public static void main(String[] args) {
        SuperClass[] sca=new SuperClass[10];
    }
}

运行结果是什么也没有打印。

3、调用类中的常量不会触发该类的初始化

代码如下：

package temp;

class ConstClass{
    static{
        System.out.println("ConstClass init.");
    }
    public static final String GREETING="Hello World.";
}

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

运行结果：


TIM截图20180807155902.png

这里的ConstClass里定义了一个常量，运行后也没有ConstClass init.输出，这时因为在编译阶段将这个常量的值存储到了Test1类的常量池中，以后Test1类对这个常量的引用实际上都会被转化为Test类对自身常量池的引用，即使在Java源码中引用了ConstClass的GREETING常量。也就是说，实际上Test1的Class文件中并没有对ConstClass类的符号引用入口，两者在编译成Class文件后就没有关系了。

接口的加载过程和类的加载过程有一些不同，不过接口也有初始化过程，上面的代码都是用静态代码块static{}来输出初始化信息的，而接口中不能使用static{}语句块，但编译器仍然会为接口生成<clinit()>类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是在前面五种情况中的第三种：当一个类在初始化时，它的所有父类都完成了初始化，但对一个接口初始化时，并不要求所有的父接口都完成初始化，只有在真正用药父接口的时候才会初始化。

二、类加载过程

这里详细讲解类加载的全过程，也就是加载、验证、准备、解析和初始化五个阶段所执行的具体操作。

1、加载阶段

这在个阶段，虚拟机要做的事情有如下三个：

这里的二进制字节流并不一定要从Class文件获取，只要一段二进制字节流符合Class文件的规范，都可以当做一个Class文件，例如我们可以从jar包中获取，从网络中获取，运行时生成等，总之获取Class文件的方式非常多。

这里需要注意的是通过一个类的全限定名来获取定义这个类的二进制字节流的动作是有类加载器完成的，对于非数组类的加载，我们可以通过自定义类加载器加载来进行控制。对于数组类就不行，因为它不是通过类加载器创建的，而是由Java虚拟机直接创建的。

但数组类和非数组类也有很大的联系，毕竟组成数组的元素就是非数组类（对于一维数组来说，而对于多维数组来说，可以递归加载），非数组类的创建需要类加载器完成。加载创建一个数组类的过程如下：

加载阶段完成后，原来虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，不过方法区中的数据格式Java虚拟机规范没有规定。在这之后，虚拟机会在内存中实例化一个java.lang.Class类的对象。对于HotSpot虚拟机，虽然这是一个对象，按理说应该在Java堆中创建，不过HotSpot虚拟机是在方法区中创建的。这个对象将作为程序访问方法区中的这些数据类型的外部入口。

需要注意的是，加载阶段与连接阶段的部分内容是交叉进行的。

2、验证阶段

验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。

3、准备阶段

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中需要注意两点，首先，这个时候进行内存分配的仅包括类变量（被static修饰的变量）而不包括实例变量，实例变量就在对象实例化时随着对象一起分配在Java堆中。其次，这里所说的初始值通常是数据类型的零值，比如下面的类变量定义：

public static int value=10;

那么value在准备阶段的初始值是0而不是10，因为这个时候还没开始执行任何Java方法，而将value赋值为10的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法中，所以把value赋值为10的动作将在初始化阶段才会执行。下标列出了所有基本类型的零值：

20140105195119234.png

不过也有特殊情况，将类变量赋值为非零值。如果类字段的字段属性表中存在ConstantValue属性，那么在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，比如：

public static final int value=10;

编译时Javac将会为value生成一个ConstantValue的属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为10。

4、解析阶段

解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。在Class类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里不再赘述。前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。
对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

下面是四中符号符号引用的解析过程：

（1） 类或接口的解析

假设当前代码处于类D中，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，虚拟机将经历如下的过程：

（2）字段解析

要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或借口的符号引用。如果解析这个类或接口时发生异常，都会导致解析字段的失败。如果解析成功，才会继续解析这个字段。具体的规则如下：

（3）类方法解析

类方法解析的第一个步骤和字段解析一样，也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，按照如下步骤继续（同样以C来表示这个类）：

（4）接口方法解析

接口方法也要解析接口方法表的class_index所属的类或接口引用，如果解析成功，用C表示这个类或接口，虚拟机按照如下的规则搜索：

注意：如果你比较细心的话会发现上面中提到的字段、方法、接口方法中都提到了一个class_index属性，可是在相应的"字段表，方法表、接口方法表"中并没有class_index这个属性，我在网上找了很长时间，终于解决了这个疑问。首先这里提到的字段表、方法表、接口方法表并不是字段表集合、方法表集合中的字段表和方法表，而是指常量池中的CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info，在这三个常量项中都有两个引用，一个是class_index：指向该字段（方法、接口方法）所属的类（接口），另一个是name_and_type_index：指向了该字段（方法、接口方法）的描述（等同于字段表集合中的描述），这里限于篇幅，不多做解释，想要深入理解的可以参考：

5、初始化阶段

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

前面已经知道，在准备阶段变量已经赋值过一次系统初始值了，而在初始化阶段，则会根据程序员通过程序制定的主观计划去初始化类变量和其它内容。即，初始化阶段是执行类构造器<clinit>()方法的过程。下面是<clinit>()方法的特点：

这里限于篇幅，把类加载机制中比较重要的最后一部分——类加载器放到下一篇文章中。

上一篇 下一篇

猜你喜欢

热点阅读