深入探索JVM类加载机制 — 类加载的过程之加载、验证

类加载的过程

加载、验证、准备、解析和初始化这五 个阶段所执行的具体动作

加载

“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，希望读者没有混淆 这两个看起来很相似的名词。在加载阶段，Java虚拟机需要完成以下三件事情：

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

相对于类加载过程的其他阶段，非数组类型的加载阶段（准确地说，是加载阶段中获取类的二进 制字节流的动作）是开发人员可控性最强的阶段。加载阶段既可以使用Java虚拟机里内置的引导类加 载器来完成，也可以由用户自定义的类加载器去完成，开发人员通过定义自己的类加载器去控制字节 流的获取方式（重写一个类加载器的findClass()或loadClass()方法），实现根据自己的想法来赋予应用 程序获取运行代码的动态性。

对于数组类⽽⾔，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟

机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类

的元素类型(Element Type，指的是数组去掉所有维度的类型)最终还是要靠类加载器来完

成加载，⼀个数组类(下⾯简称 为C)创建过程遵循以下规则:

如果数组的组件类型(Component Type，指的是数组去掉⼀个维度的类型，注意和前⾯

的元素类型区分开来)是引⽤类型，那就递归采⽤本节中定义的加载过程去加载这个组件

类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上(这点很重要，在7.4

节会介绍，⼀个类型必须与类加载器⼀起确定唯⼀性)。

如果数组的组件类型不是引⽤类型(例如int[]数组的组件类型为int)，Java虚拟机将会把数

组C标记为与引导类加载器关联。

数组类的可访问性与它的组件类型的可访问性⼀致，如果组件类型不是引⽤类型，它的数

组类的可访问性将默认为public，可被所有的类和接⼝访问到

加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中 了，方法区中的数据存储格式完全由虚拟机实现自行定义，《Java虚拟机规范》未规定此区域的具体 数据结构。类型数据妥善安置在方法区之后，会在Java堆内存中实例化一个java.lang.Class类的对象， 这个对象将作为程序访问方法区中的类型数据的外部接口。

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段 尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部 分，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚 拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节 码验证和符号引用验证

1.文件格式验证

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

·是否以魔数0xCAFEBABE开头。

·主、次版本号是否在当前Java虚拟机接受范围之内。

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

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

·CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。

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

·……实际上第一阶段的验证点还远不止这些，上面所列的只是从HotSpot虚拟机源码中摘抄的一小部分内容，该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了

2.元数据验证

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要 求，这个阶段可能包括的验证点如下：

·这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。

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

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

·类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方 法重载，例如方法参数都一致，但返回值类型却不同等）。

 ·…… 第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相 悖的元数据信息。 

1. 字节码验证

第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定 程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后，这阶段就要 对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害 虚拟机安全的行为，例如：

·保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于“在操作 栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中”这样的情况。

·保证任何跳转指令都不会跳转到方法体以外的字节码指令上。

·保证方法体中的类型转换总是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全 的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个 数据类型，则是危险和不合法的。

 ·…… 如果一个类型中有方法体的字节码没有通过字节码验证，那它肯定是有问题的；但如果一个方法 体通过了字节码验证，也仍然不能保证它一定就是安全的。即使字节码验证阶段中进行了再大量、再 严密的检查，也依然不能保证这一点。这里涉及了离散数学中一个很著名的问题——“停机问题”（Halting Problem），即不能通过程序准确地检查出程序是否能在有限的时间之内结束运行。在 我们讨论字节码校验的上下文语境里，通俗一点的解释是通过程序去校验程序逻辑是无法做到绝对准 确的，不可能用程序来准确判定一段程序是否存在Bug

如果⼀个类型中有⽅法体的字节码没有通过字节码验证，那它肯定是有问题的;但如果⼀

个⽅法体通过了字节码验证，也仍然不能保证它⼀定就是安全的。即使字节码验证阶段中

进⾏了再⼤量、再严密的检查，也依然不能保证这⼀点。

1. 符号引用验证

最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在 连接的第三阶段——解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号 引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部 类、方法、字段等资源。本阶段通常需要校验下列内容：

·符号引用中通过字符串描述的全限定名是否能找到对应的类。

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

·符号引用中的类、字段、方法的可访问性（private、protected、public、<package>）是否可被当 前类访问。

·…… 符号引用验证的主要目的是确保解析行为能正常执行，如果无法通过符号引用验证，Java虚拟机 将会抛出一个java.lang.IncompatibleClassChangeError的子类异常，典型的如： java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但却不是必须要执行的阶段，因为 验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运行期没有任何影响了。如果 程序运行的全部代码（包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码）都 已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的 类验证措施，以缩短虚拟机类加载的时间。