标签：特定 error tab jdk1.7 use zip 矛盾 size 校验
前言：前面学习了类Class文件格式和里面具体的内容，也已经学习了运行时数据区的各部分区域的内容。接下来就是学习JVM是如何把Class文件中记录的信息加载到运行时内存中的，以及class文件中各个部分的信息分别存放在运行时数据区的什么地方。从这篇文字中我们能获得什么？
1.虚拟机是如何加载Class文件的
2.Class文件信息进入JVM后有那些变化
3.进一步理解运行时数据区、Class文件信息、以及类加载过程中都做了那些操作、
java语言特性的根基
类加载机制
虚拟机把描述类的数据从Class文件加载到内存中，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是类加载机制。
看到这里我有几个疑问，不知道你们是否有疑问，如下：
1.虚拟机什么时候加载Class文件到内存的？
2.虚拟机具体是用哪些部件加载Class文件到内存的？
3.在利用某些部件加载Class文件时又具体做了那些操作？
类加载时机
一个类从加载进入内存，到从内存卸载的整个生命周期，一共最多需要经历：
加载、验证、准备、解析、初始化、使用、卸载七个阶段。
备注：
验证、准备、解析又统一合称为链接阶段。
加载、验证、准备、初始化、卸载这五个阶段顺序是确定的，而解析阶段则不一定。
它在**某些情况**下可以在初始化之后开始，这就是java为什么支持**动态绑定**。那么我们知道类加载分类这些阶段，那么类加载第一阶段：加载阶段（Loading）是什么时候开始的呢？虚拟机规范中没有强制要求，这一点可以根据虚拟机具体实现来自由把握。但初始化阶段在虚拟机规范中有严格规定了四种情况必须立即开始初始化阶段。
1.遇到new、getstatic、putstatic、invokestatic这四条字节码指令时。如果没有初始化，那
么就必须触发初始化。
2.使用java.lang.reflect包方法对类进行反射调用时，如果没有初始化，必须触发初始化。
3.当初始化一个类时，其父类没有被初始化，那么需先触发父类初始化。
4.当虚拟机启动时，用户需要指定一个要执行的主类（main类，主入口），虚拟机会先
初始化这个主类。
备注：有且只有这四种情况，虚拟机会对一个类**主动引用**。除此之外的所有类的引用，
都不会触发初始化，称为**被动引用**。看到这里，我依然一头雾水，不知道类加载过程的第一阶段：加载阶段是神码时候开始的。那我们再来想想，我们平时是如何运行一个java应用或者程序的？是不是都是从一个主类开始执行run的，因为开发工具帮我们屏蔽了很多底层细节，所以我现在想起来，我们点击主入口run时，是不是就是启动了虚拟机，并指定了该主类为要执行的主类，也就是上面所说的第四中情况。但是虚拟机启动并执行主类的细节我目前也不知道底层做了那些细节操作，具体我先自己在这里挖个坑，自己后面填上。
到这里我就知道整个类加载过程应该就是从第四中情况的主类加载开始的。
加载阶段
加载阶段，虚拟机需要做三件事情：
1.通过一个类的全限定名来获取定义此类的二进制字节流
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3.在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入
口
虚拟机规范中的这三点说的并不具体，很宽泛，比如说获取二进制字节流，并没有说是从哪里获取，可以从class文件中获取，也可以从网络中获取，这就给了开发者极大的灵活性。
从ZIP文件中获取：最终成为JAR,WAR,EAR格式的基础。
从网络中获取：比如说Applet。
运行时计算生成：运用最多的就是动态代理技术，java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成.$proxy的代理类的二进制字节流。
由其他文件生成：如jsp
等等其他的获取方式。同时由谁来加载这个二进制字节流也非常具有灵活性，我们可以使用系统提供的类加载器加载，也可以通过自定义的类加载器进行加载。看到这里我们也就知道是类加载器把字节流加载到内存中的。
验证阶段
虚拟机规范中没有明确规定具体要检查那方面、如何检查、何时检查，不同的虚拟机实现可能会有不同，但大都会完成下列四项验证：
文件格式验证
需要验证字节流是否符合Class文件格式的规范。是否能被当前版本虚拟机处理执行。这一项的验证是根据Class文件格式而来，比如说，魔数是否为0xCAFEBABE？次版本号、主版本号是否当前虚拟机本版可处理范围？常量池中是否有不被支持的常量类型呀（tag检查）等等。该验证是保证输入的字节流能够正确地解析并存储于方法区内。只有通过了文件格式验证的字节流才能被存储到方法区，这一验证是依赖于字节流的。后续的验证都是基于方法区存储结构的验证。
元数据验证
这一阶段验证是对字节码描述的信息进行语义分析，验证是否符合java语言规范。是否有父类，是否继承不可继承的类，如果不是抽象类，是否实现了父类的或者接口的方法，类字段、方法、与父类是否有矛盾等等的校验。
字节码验证
这一阶段验证是最复杂的，它主要进行数据流和控制流分析，保证类方法在运行中不会作出危害虚拟机安全的行为。并且注意没有通过字节码验证的肯定是不安全的，但通过了不能就代表一定安全的。比如说死循环。数据流验证的高复杂性，虚拟机团队为了避免耗费过多时间在字节码校验阶段，给方法体的code属性增加了StackMapTable的属性，该项优化是在jdk1.6之后的javac编译器中进行的，通过-XX:-UseSplitVerifier选项进行开启优化，或者启动-XX:FailOverToOldVerifier要求失败后退回到老版本的类型推导验证。在jdk1.7之后，主版本号大于50的Class文件只能有数据流分析校验这一种方式。
符号引用验证
这一阶段发生在虚拟机将符号引用转化为直接引用时触发，在解析阶段中发生。通常校验：是否能找到类，是否有符合方法的字段描述、简单名称所描述的方法、字段，类，方法，字段的访问修饰是否可以被当前类访问，等等的校验。该阶段验证是为了确保解析动作能正常执行。如果该阶段未通过，那么就会抛出java.lang.IncompatibleClassChangeError异常的子类，比如：非法访问异常，无此字段异常，无此方法异常等。
备注：
验证阶段不是一定要执行的阶段，如果在开发测试期间以及反复验证使用过，那么可以通过设置：-Xverify:none;关闭大部分的类验证措施，缩短类加载的时间。
准备阶段
这一阶段是正式为类变量分配内存设置初始值的阶段，都是在方法区分配。此处的初始值，不是程序中给定的字面量，而是系统给定的初始值（也叫做零值）。
解析阶段
该阶段是将常量池中的符号引用转化为直接引用的阶段。主要针对类或者接口、字段、类方法、接口方法四类的符号引用进行解析。
初始化阶段
这一阶段应该说是开发者很进的，因为这各就是根据java编写字节码设置变量的值，或者引用。从另外一个角度看就是执行构造方法的阶段，这一阶段有些比较细致的行为操作，比如类或者接口他们的父类或者父接口的构造方法，静态语句快的执行顺序等在这里不做详细书写，有兴趣可自行查阅资料，或者看深入java虚拟机第七章的初始化阶段。
那么写到这里类加载过程就已经写完了，最后总结一下：
1.类加载过程包括加载、验证、准备、解析、初始化五个阶段。
2.类的加载是由虚拟机的类加载器或开发者自定义的类加载器加载
3.类加载的各个阶段都有进行一些操作，这些操作都是围绕class文件结构、java语言规范、虚拟机安全而进行的。
讲到这里你是否堆类加载过程有了更全面的理解呢？另外关于虚拟机类加载器、自定义类加载器的深入理解 我也会在后面看完书之后进行总结。上面如果我有表述错误或者理解错误，请留言指正。
标签：特定 error tab jdk1.7 use zip 矛盾 size 校验
原文地址：http://blog.51cto.com/4837471/2158231
