《深入理解Java虚拟机》：类加载的过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。
下面详细讲述类加载过程中每个阶段所做的工作.

加载

加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：

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

注意，这里第1条中的二进制字节流并不只是单纯地从class文件中获取，比如它还可以从Jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。

相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.class类的对象，这样便可以通过该对象访问方法区中的这些数据。

验证

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

1、文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括以下验证点：

• 魔数的验证
• 版本号的验证，判断虚拟机能否处理
• 常量池中的常理是否有不被支持的常量类型。
• ………..

该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。

2、元数据验证：对字节码描述的信息进行语义分析，保证不存在不符合Java语法规范的元数据信息。例如：

• 这个类是否有父类
• 这个类的父类是否继承了不允许被继承的类（被final修饰的类）
• 如果这个类不是抽象类，是否实现了其父类或接口之中的抽象方法。
• 类中的字段、方法是否与父类产生冲突（例如出现了不符合规则的方法重载等）

3、字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
例如

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
• 保证跳转指令不会跳转到方法体以外的字节码指令上。
• 保证方法体中的类型转换是有效的。（例如把一个子类对象赋值给父类对象，这是正确的，但是把父类对象赋值给子类数据对象就是不正确的。）
  ……..

4、符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。
例如

• 符号引用中的类、方法和字段的访问性是否可以被当前类访问。
• 符号引用中沟通过字符串描述的全限定名是否能找到对应的类、方法、字段。
• ……..

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。下面有几点需要解释
第一点：这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
第二点：这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

例如一个类变量的定义为：public static int value = 123；
那么变量value在准备阶段过后的初始值为0，而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是在程序编译后，存放于类构造器（）方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

第三点：第二点提到的是“通常情况下”初始化为零值，相对特殊的情况如下：如果类字段的字段属性表中存在ConstantValue属性（即同时被final和static修饰的变量），那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

假设上面的类变量value被定义为： public static final int value =123；
编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123

再次强调：准备阶段是正式为类变量（static）分配内存并设置类变量初始值（即默认的零值）的阶段。

下面为上面提及到的各个基本类型的零值，注意，下面括号中的值为零值

• int （0）
• long(0L)
• short(（short）0)
• char(‘\u0000’)
• byte((byte)0)
• boolean(false)
• float(0.0f)
• double(0.0d)
• reference(null)

关于类变量、实例变量以及局部变量，我这里要说几点：

• 1、对基本数据类型来说，对于类变量（static）和实例变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过，这里是我的一篇博客提到的几个面试题就考到了此知识点。
• 2、对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
• 3、对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
• 4、如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。

解析

解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。

这里说明下符号引用和直接引用的区别与关联：

• 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到了内存中。
• 直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那说明引用的目标必定已经存在于内存之中了。

前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。

对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符七类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info等七种常量类型。由于后面3种是JDK1.7新增的与动态语言支持息息相关，将在后面讲解，下面主要讲解前面4种。

1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。具体过程如下：

假设当前代码所处的类是D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成整个解析的过程需要以下3个步骤。
（1）如果C不是一个数组类型，按虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就宣告失败。
（2）如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似“[Ljava/lang/Integer”的形式，那将会按照第1点的规则加载数组元素类型。如果N的描述如前面所假设的形式，需要加载的元素类型就是”java.lang.Integer”,接着由虚拟机生成一个代表此数组维度和元素的数组对象。
（3）如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但是在解析完成之前还要进行符号引用验证，确认D是都具备对C的访问权限。

2、字段解析：
要解析一个未被解析过的字段符号时，首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用进行解析，参考类或接口解析。若对类或接口解析成功，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。
3、类方法解析和接口方法解析：和字段解析类似。

初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

这里说明下<clinit>（）方法的产生过程和执行过程:

• 1、<clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。例子如下

package org.wrh.classupload;

public class TestClassDemo03 {

    static{
        i=0;//在前面的static块可以赋值，但是不可以引用
        //System.out.println(i);//错误提示：Cannot reference a field before it is defined

    }
    public static int i=1;

}

• 2、<clinit>（）方法与类的构造函数（实例构造器<init>( )方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>（）方法的类肯定是java.lang.Object。例子如下

package org.wrh.classupload;

class Parent{
    public static int value=1;
    static{
        System.out.println("Parent init");
        value=2;
    }
}

class Son extends Parent{
    public static int value_1=value;
    static{
        System.out.println("Son init");
    }

}
public class TestInit {
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        System.out.println(Son.value_1);

    }

}

程序运行结果如下：

Parent init
Son init
2

• 3、<clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>（）方法。
• 4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>（）方法。但是接口与类不同的是：执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。
• 5、虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>（）方法完毕。如果在一个类的<clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。
• 关于类的初始化还可以看《深入Java虚拟机》：类的初始化这篇博文