深入理解java虚拟机（八）类加载过程详解

类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中，验证、准备和解析统称为连接（Linking）。过程如下图所示。

下面我们来详细讲解Java虚拟机类中加载的5个过程，即加载、验证、准备、解析和初始化五个过程。

第一步：加载

“加载”是虚拟机类加载的第一个阶段，在这个阶段中，虚拟机要完成3件事情：

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

而获取类的二进制流又有很多种方式：

从压缩包中获取，比如 JAR包、EAR、WAR包等
从网络中获取，比如红极一时的Applet技术
从运行过程中动态生成，最出名的便是动态代理技术，在java.lang.reflect.Proxy 中，就是用了 ProxyGenerator.generateProxyClass 来为特定接口生成形式为“$Proxy”的代理类的二进制流
从其它文件生成，如JSP文件生成Class 类
从数据库中读取，比如说有些中间件服务器，通过数据库完成程序代码在集群之间的分发

相对于类加载中的其它阶段，“加载”这一阶段是开发人员可控性最强的阶段。因为“加载”阶段既可以使用系统提供的引导类加载器完成，也可以由用户自定义的类加载器完成。即开发人员可以根据实际需要指定二进制数据流的获取方式。

对于数组类来说，它不是由虚拟机加载得来的，而是在运行过程中直接创建的。其创建过程遵循以下规则：

如果数组的组件类型（数组去掉一个维度的数据类型）是引用类型，就递归使用这些引用类型的类加载器进行加载。
如果组件类型不是引用类型，例如 int[] 数组，Java 虚拟机会将数组标记为与引导类加载器管理
数组的可见性与它的组件类型可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

加载过程完成之后首先会在方法区中建立类的数据结构，然后会在内存中实例化一个 java.lang.Class 对象来作文程序访问方法去中这些类型数据的外部接口。Java规范中并没有规定 Class 对象的存放位置，对于Hot Spot 虚拟机来说，Class 对象虽然是对象，但却是存放在方法区中。

第二步：验证

“验证”是连接阶段的第一步，这一阶段是为了确保 Class 文件内的字节流格式符合Java虚拟机要求，不会危害虚拟机安全。

Java 语言本身是相对安全的语言，但是用纯粹的Java 代码无法做到诸如访问数组边界之外的数据、将对象转型为它未实现的类型、跳转到不存在的代码行之类的事情，如果这么做了，编译器会拒绝编译。但是由于 Class 文件的产生并不强制要求必须是 Java 代码编译而来，你甚至可以自己用十六进制编辑器直接编写 Class 文件。如果不进行 Class 文件校验的话，很有可能会因为载入了有害的字节流导致虚拟机崩溃。

验证总体上分为4个阶段：文件格式验证、元数据验证、字节码验证、符号引用验证。

文件格式验证

这阶段主要是检查字节流是否符合Class 文件的规范，版本是否能够处理，包括下面这些验证点：

是否以魔数开头

主次版本是否在当前虚拟机处理范围之内

常量池的常量中是否有不被支持的常量类型（检查常量tag标志）

指向常量的各种索引中是否有指向不存在的常量或不符合类型的常量

CONSTANT_Utf8_info 型的常量中是否有不符合UTF8 编码的数据

Class 文件中各个部分以及文件本身是否有被删除的或被附加的其它信息

文件格式验证主要是针对字节流进行验证，经过了这一步验证之后，字节流才会进入内存的方法区进行存储，所以后面的3个阶段全部都是基于方法区的存储结构进行的，不会再操作字节流。

元数据验证

这一阶段主要是对字节码描述的信息进行语义分析，验证类的继承关系，验证点如下：

这个类的父类是否允许被继承（final 修饰的类）

这个类如果不是抽象类，是否实现了父类或接口之中要求实现的所有方法

类中的字段、方法是否和父类产生矛盾（如覆盖了父类final 字段，出现了非法的方法重载）

字节码验证

字节码验证是验证过程中最复杂的一个阶段，它的目的是确定程序语义是合法的、符合逻辑的。在元数据验证完成之后，它会对方法体进行验证，确保程序不会做出危害虚拟机安全的行为。

保证任何时候，操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现int 数据入栈，而却按 long 类型加载如本地变量表中

保证跳转指令不会跳转到方法体外的字节码指令上

保证方法体中类型转换是有效的

符号引用验证

最后一个阶段的验证放生在虚拟机将符号引用转化为直接引用的时候，这个阶段将会在解析阶段发生。符号引用验证可以看做是对类自身以外的信息进行匹配校验。

符号引用中通过字符串描述的权限定名是否能找到相应的类

在指定类中对否存在符合方法的字段描述符以及简单名称所描述的方法和字段

符号引用中的类、字段、方法的访问性是否可被当前类访问

符号引用验证是为了保证解析动作能正常执行。这个阶段可以用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

第三步：准备

“准备”阶段是正式为类变量（仅仅是类变量，即 static 修饰的变量）分配内存并设置类变量初始值（除了 final 变量初始值是数据类型的零值，并不是类构造器<clinit> 方法中的初始值）的阶段，这些变量所使用的内存都将在方法区中进行。

第四步：解析

”解析“阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用以 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Mehodref_info 等类型的常量出现（即类名称，变量名称，方法名称等信息）。那么符号引用与直接引用有什么关联呢？

符号引用（Symbolic References）：即用一组符号来描述所引用的目标。它与虚拟机的内存布局无关，引用的目标不一定已经加载到内存中。
直接引用（Direct References）：直接引用可以是指向目标的指针、相对偏移量或是一个能简介定位到目标的句柄。它是和虚拟机内存布局相关的。

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

类或接口的解析

假如类D 要把一个从未解析过的符号引用N 解析为一个类或接口C 的直接引用，那虚拟机解析过程需要3个过程：

如果C不是一个数组类型，虚拟机会把 N 的全限定名传递给 D 的类加载器去加载这个类C 。由于元数据验证和字节码验证的过程，可能会触发其它相关类的加载动作。

如果C是一个数组类型，并且数组元素类型为对象，那将会按照第一点规则加载数组元素类型。

如果上面步骤没有任何异常，那么 C 已经成为了一个有效的类和接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。否则会抛出java.lang.IllegalAccessError 异常。

字段解析

首先对字段的位于class_index 项中索引的 CONSTANT_Class_info 符号引用，也就是字段所属的类或接口的符号引用进行解析，如果解析顺利的话，虚拟机将按照下列步骤进行字段搜索。

如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

否则，如果C 中实现了接口，会按继承关系从下往上递归搜索其父接口，如果在父接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

否则，如果C 不是 java.lang.Object 的话，将会按继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

否则，查找失败，抛出 java.lang.NoSuchFieldError 异常。

如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出 java.lang.IllegalAccessError 异常。

类方法解析

类方法解析第一步和字段解析是一样的，都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果顺利的话，虚拟机将按下列步骤进行字段搜索。

如果发现class_index 索引的C是个接口，那就抛出 java.lang.IncompatibleClassChangeError 异常。

如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

否则，在类C的父类中递归查找，如果有就直接返回方法的直接引用，查找结束。

否则，在类C 实现的接口列表以及他们的父接口中递归查找，如果存在，则说明C是一个抽象类，查找结束并抛出 java.lang.AbstractMehodError 的异常。

否则，查找失败，抛出 java.lang.NoSuchMethodError 异常.

最后如果查找成功，会进行权限验证。失败会抛出 java.lang.IllegalAccessError

接口方法解析

接口方法解析第一步和字段解析是一样的，都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果顺利的话，虚拟机将按下列步骤进行字段搜索。

如果接口方法表中发现 class_index 中的索引C是个类而不是接口，就直接抛出 java.lang.IncompatibleClassChangeError 异常。

否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束

否则，在几口C 的父接口中递归查找，直到 java.lang.Object 类位置，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

否则，查找失败，抛出 java.lang.NoSuchMethodError 异常。

由于接口方法都是public的，所以不存在访问权限的问题，因此接口方法的符号解析应当不会抛出 java.lang.IllegalAccessError 异常。

第五步：初始化

“初始化”是类加载的最后一步，到了这一步，才是真正开始执行类中定义的Java 程序代码。

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