细说JVM（类加载机制）

一、类加载的时机

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

20160602122102170.png

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

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

• 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类没有进行过初始化，就需要进行类的初始化。这些场景包括：使用new关键字实例化对象时、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）时，以及调用一个类的静态方法时；
• 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，就需要先进行类的初始化；
• 当初始化一个类的时候，如果发现父类还没有进行过初始化，则需要先初始化父类；
• 当虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类；
• 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化；

这五种情况是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、加载阶段

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

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

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

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

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

• 如果数组的元素类型是引用类型，就递归加载这个元素类型，这个数组将在加载该元素类型的类加载器的类名称空间上被标识；
• 如果数组的元素类型不是引用类型（比如int[]数组），Java虚拟机将会把数组标记为与引导类加载器关联；
• 数组类的可见性与元素类型的可见性一致，如果元素类型是不引用类型，那么数组的可见性默认是public；

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

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

2、验证阶段

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

• 文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
• 元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
• 字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
• 符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

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的直接引用，虚拟机将经历如下的过程：

• 如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器区加载这个类。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载，比如这个类的父类或实现的接口。如果加载过程出现异常，解析过程就失败。
• 如果C是一个数组类型，并且数组的元素类型是对象，就会按照第一点加载数组元素类型。接着由虚拟机生成一个代表着数组维度和元素的数组对象。
• 如果上面的步骤没有异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。

（2）字段解析

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

• 如果类或接口C本身就包含了简单名称和字段描述符都与目标匹配的字段，则返回这个字段的直接引用，查找结束；
• 否则，如果在C中实现了接口，将会按照继承关系从下到上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标匹配的字段，则返回这个字段的直接引用，查找结束；
• 否则，如果C不是Object的话，将会按照继承关系从下到上递归搜索父类，如果父类中包含了简单名称和字段描述符都与目标匹配的字段，返回这个字段的直接引用，查找结束；
• 否则，查找失败。
• 之后，还会对返回的字段进行权限验证，如果不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

（3）类方法解析

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

• 类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C是一个接口，直接失败；
• 然后，会在类C中查找这个方法；
• 否则，在类C的父类中递归查找这个方法；
• 否则，在类C实现的接口列表中递归查找这个方法。如果找到一个匹配的方法，说明类C是一个抽象类，查找结束，抛出java.lang.AbstractMethodError异常；
• 否则，查找失败，抛出java.lang.NoSuchMethodError异常。
• 同样，成功返回后还要进行权限验证。

（4）接口方法解析

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

• 与类方法解析不同，如果在接口方法表中发现class_index是一个类而不是接口，直接抛出java.lang.IncompatibleClassChangeError异常；
• 否则，在接口C中查找这个方法；
• 否则，在接口C的父接口中递归查找；
• 否则，查找失败，抛出java.lang.NoSuchMethodError异常。
  返回成功后不会验证权限，因为接口的方法都是public的。

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

• 《Java虚拟机原理图解》 1.2.3、Class文件中的常量池详解（下）
• CONSTANT_Fieldref_info和字段表中的field_info的区别？

5、初始化阶段

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

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

• <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序由语句块在源文件中的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在之后的变量不能访问，但能赋值。
• <clinit>()方法与类构造器<init>()不同，它不需要显式调用父类的<clinit>()方法，虚拟机保证在子类<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。
• 由于父类的<clinit>()方法先执行，意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
• <clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变脸的赋值操作，那么编译器就不会生成<clinit>()方法。
• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。即，只有使用一个接口中的变量时，才会执行这个接口的<clinit>()方法。
• 虚拟机会保证一个类的<clinit>()方法在多线程环境下中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只有一个线程会去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

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