虚拟机类加载机制【类加载过程（二）验证】

是连接阶段的第一步，目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并不会危害虚拟机自身的安全。

• Java语言本身是相对安全的（相对C/C++），但是Class文件并不一定要求用Java源码编译而来，可使用任何途径产生（靠键盘0和1），甚至包括用十六进制编辑器直接编写来产生Class文件。在字节码语言层面上，Java代码无法做到的事情，至少语义上是可以表达出来的。虚拟机如果不检查输入的字节流，完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机堆自身保护的一项重要 工作。
• 验证阶段是否严谨，直接决定了Java虚拟机是否能承受恶意代码的攻击，从执行性能上讲，验证阶段的工作量在类加载子系统占了相当大的一部分。
• 从整体上看，验证阶段大致上会完成4个阶段的校验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

2.1 文件格式验证

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

1. 是否以魔数0xCAFEBABE开头。
2. 主、次版本号是否在当前虚拟机处理范围之内。
3. 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
4. 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
5. CONSTANT_Utf8_info型常量中是否有不符合UTF8编码的数据。
6. Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
7. ......

• 此验证阶段的主要目的是保证输入的字节流能正确解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流的，只有通过验证后，字节流才会进入内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。

2.2 元数据验证

第二阶段是对字节码描述的信息进行语义分析，以确保求描述的信息符合Java语言规范要求，验证点如下：

1. 这个类是否有父类（除了java.lang.Object，其余都有父类）。
2. 这个类的父类是否继承不允许被继承的类（final修饰的类）。
3. 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的方法。
4. 类中的字段、方法是否与父类产生矛盾（如覆盖父类的final字段，或出现不符合规则的方法重载（方法参数一致，返回值不一致））。
5. ......

• 该阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。

2.3 字节码验证

第三阶段是最复杂的阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法符合逻辑的。这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件：

1. 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似在一个操作数栈放置了一个int类型数据，使用却按long类型来加载到本地变量表中。
2. 保证跳转指令不会跳转到方法体以外的字节码指令上。
3. 保证方法体中的类型转换是有效的，如可把一个子类对象赋值给父类数据类型，但不能把父类对象赋值给子类数据类型，甚至把对象赋值给毫不相干的数据类型。
4. ......

• 通过程序去校验程序逻辑是无法做到绝对准确的，不能通过程序准确地检查出程序是否能在有限的时间之内结束运行。
• 由于数据流验证高复杂性，为避免高耗时，在JDK1.6之后的Javac编译器和Java虚拟机进行了一项优化，把尽可能多的校验辅助措施挪到Javac编译器里进行，给方法体的Code属性的属性表中增加了一项“StackMapTable”的属性（描述了方法体中的所有的基本块（Basic Block,按照控制流拆分的代码块）开始时本地变量表和操作栈应有的状态），在字节码验证期间，只需要检查StackMapTable属性中的记录是否合法即可。这样将字节码验证的类型推导转变为类型检查从而节省一些时间。
• 理论上StackMapTable属性也存在错误或篡改的可能，所有是否有可能在恶意篡改了Code属性的同时，也生成相应的StackMapTable属性来骗过虚拟机的类型校验则是虚拟机设计者值得思考的问题。
• 在JDK1.6的HotSpot虚拟机中提供“-XX:UseSplitVerifier”选项来关闭这项优化，或使用参数“-XX:+FailOverToOldVerifier”要求在类型校验失败的时候退回到旧的类型推导方式进行校验。而在JDK1.7，对于主版本号大于50的Class文件，使用类型检查来完成数据流分析校验则是唯一的选择，不允许再退回到类型推导的校验方式。

2.4 符号引用验证

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

1. 符号引用中通过字符串描述的全限定名是否能找到对应的类。
2. 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
3. 符号引用中的类、字段、方法的访问性（private、protected、public、<package>）是否可被当前类访问。
4. ......

• 目的在于确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

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