Java虚拟机：类加载机制详解

大家知道，我们的Java程序被编译器编译成class文件，在class文件中描述的各种信息，最终都需要加载到虚拟机内存才能运行和使用，那么虚拟机是如何加载这些class文件的呢？在加载class文件的过程中虚拟机又干了哪些事呢？今天我们来解密虚拟机的类加载机制。

虚拟机把class文件加载到内存，并对数据进行校验、解析和初始化，最终形成可以被虚拟机直接使用的Java类型（Class对象），这就是虚拟机的类加载机制。

类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。，其中验证、准备和解析3个阶段统称为连接阶段。如图：

前面的5个阶段就是类加载的过程。其中加载、验证、准备和初始化这几个阶段的顺序是确定的，而解析阶段则不一定，在某些情况下它可以在初始化阶段以后才进行。那么，在类加载的每一个步骤中，虚拟机都进行了那些工作呢？

加载

加载是类加载过程的第一个阶段，在这一阶段，虚拟机主要完成了3件事：

1、通过类的全限定名来获取定义这个类的二进制字节流。简单来说就是，通过类的包名加类名来定位到此类的class文件的位置，相当于一个资源定位的过程。

2、将这个字节流代表的静态存储结构转化为方法区的运行时数据结构。也就是将类中定义的静态变量、常量等信息存储在方法区中。

3、在堆内存中生成一个代表这个类的java.lang.Class对象，作为方法区中这个类的各种数据的访问入口。

总结一下，加载阶段的主要工作就是，把class二进制文件加载到内存后，将类中定义的静态变量、常量、类信息等数据存放到方法区，并在堆内存中创建一个代表这个类的Class对象，作为方法区中这个类的数据信息的访问入口，程序猿可以持有这个Class对象。

验证

验证是连接阶段的第一步，验证阶段的目的是确保class文件中包含的信息符合虚拟机的要求，并且不会危害到虚拟机自身的安全。验证的内容主要包含以下几个方面：

1、文件格式验证。主要目的是保证输入的字节流能正确的解析并存储在方法区中，格式上符合一个Java类型信息的要求。这个阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证，字节流才能进入方法区进行存储，所有后面的3个阶段的验证都是基于方法区的存储结构进行的，不会直接操作字节流。

2、元数据验证。这一阶段的主要目的是对类的元数据（定义数据的数据）信息进行语义校验，确保不存在不符合Java语言规范的元数据信息。包括：该类是否有父类、该类的父类是否继承了不允许被继承的类、该类中的字段和方法是否与父类产生矛盾等等。

3、字节码验证。目的是通过数据流和控制流分析，确定程序语义是否合法、符合逻辑。在第二阶段对元数据信息的数据类型做完校验后，这个阶段将对类的方法体进行分析，保证被校验的类的方法在运行时不会危害虚拟机的安全。

4、符号引用验证。符号引用验证发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作是在连接的第三阶段——解析阶段中进行的。符号引用验证的目的是确保解析动作能够正常执行。

对于类加载机制而言，验证阶段是一个非常重要、但不是一定必要的阶段。如果所运行的全部代码都已经被反复使用和验证过了，那么就可以使用虚拟机参数-Xverify:none来关闭大部分的类验证措施，以缩短类加载的时间。

准备

准备阶段的主要工作是为类的静态变量分配内存并设置变量的初始默认值。这些变量所使用的内存都在方法区中分配。这里有两个问题需要说明：

1、这一阶段进行内存分配的仅包括静态变量，而不包括实例变量（静态变量是所有对象共有的，实例变量是对象私有的），实例变量将会在对象实例化时随着对象一起分配在Java堆中。

2、这里说的为对象赋初始值是各数据类型对应的零值。假设有一个静态变量定义为public static int a = 1; 那变量a的初始值就是0而不是1，初始值1在初始化阶段赋给变量a。如果是引用类型初始默认值就是null。

解析

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

符号引用：符号引用以一组符号来描述所引用的目标，符号可以使任何形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用的字面量形式在Java虚拟机规范的Class文件格式中有明确定义。

直接引用：直接引用可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局有关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那么引用的目标必定已经在内存中存在。

解析动作主要针对类或接口、字段、静态方法、接口方法、方法类型、方法句柄和调用点限定符这几类符号引用进行。

初始化

初始化阶段是类加载过程的最后一步。在前面的类加载过程中，除了加载阶段我们可以通过自定义的类加载器参与之外，其余的阶段都是虚拟机自动完成的。到了初始化阶段，才真正开始执行我们程序中定义的Java代码。初始化阶段的主要工作是给类的静态变量赋予我们程序中指定的初始值。也就是上面准备阶段提到的，变量a的值从0变为1的过程。这个阶段我们程序指定初始值包括两种手段：

1、声明静态变量时显式的复制。例如：public static int a = 1; 在初始化阶段会把1赋给变量a。

2、通过静态代码块赋值。例如：static { a = 2 }; 变量a 的初始值赋为2。

这两种方式的赋值顺序是由语句在源文件中出现的顺序来决定的。

以上就是Java虚拟机类加载机制的整个过程以及在每个阶段虚拟机所执行的动作。

双亲委派模型

前面提到过，在类加载的整个过程中，除了加载阶段我们可以通过自定义的类加载器参与之外，其他的阶段都是虚拟机帮我们完成的。虚拟机设计团队把加载这个动作放到Java虚拟机外部去实现，实现这个动作的代码模块称为“类加载器”。这样做的目的是让应用程序自己去决定如何获取所需要的类。

除了我们自己可以定义类加载器，Java虚拟机也为我们提供了系统自带的类加载器。主要可以分为以下三种：

根类加载器（Bootstrap ClassLoader）：这个类加载器负责加载存放在\lib目录中的，或者通过参数-Xbootclasspath所指定的路径中的类。

应用类加载器（Application ClassLoader）：它负责加载用户设置的ClassPath路径上所指定的类库。如果应用程序中没有自定义的类加载器，一般情况下这个就是程序默认的类加载器。

我们的应用程序都是由这3种类加载器相互配合进行加载的，如果有必要，还可以定义自己的类加载器。这些类加载器之间的关系如下：

上图中展示的类加载器之间的层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的根类加载器外，其余的类加载器都应当有自己的父类加载器。双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该传送到根类加载器中，只有当父加载器反馈自己无法完成这个加载请求（搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

类加载器虽然只用于实现类的加载动作，但是它在Java程序中起的作用却不仅仅是进行类加载。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立它在Java虚拟机中的唯一性。简单来说就是，一个类的class文件被不同的两个类加载器加载，那么加载后的这两个类就不“相等”，不是相同的类。

使用双亲委派模型，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object类，它存放在rt.jar中，无论哪一个类加载器要加载这个类，最终都会委派给模型最顶端的根类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类（始终被根类加载器加载）。相反，如果不使用双亲委派模型，由各个类加载器自己去加载的话，假如用户编写了一个称为java.lang.Object的类，并放在ClassPath中，那系统中会出现多个不同的Object类，应用程序也会变的一片混乱。

以上内容总结了Java类加载机制的整个过程以及双亲委派模型的原理，欢迎交流。