JVM笔记6：JVM类加载机制

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

从类被加载到虚拟机内存中开始，到卸载出内存为止，类的生命周期包括加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段

其中验证、准备和解析三部分称为连接，在Java语言中，类型的加载和连接过程都是在程序运行期间完成的（Java可以动态扩展的语言特性就是依赖运行期动态加载、动态连接这个特点实现的），这样会在类加载时稍微增加一些性能开销，但是却为Java应用程序提供高度的灵活性

加载、验证、准备、初始化和卸载这5个阶段的顺序是固定的（即：加载阶段必须在验证阶段开始之前开始，验证阶段必须在准备阶段开始之前开始等。这些阶段都是互相交叉地混合式进行的，通常会在一个阶段的执行过程中调用或激活另一个阶段），解析阶段则不一定，在某些情况下，解析阶段有可能在初始化阶段结束后开始，以支持Java的动态绑定

加载（Loading）

start time:

“加载”阶段是“类加载过程”的一个阶段，虚拟机规范并没有强制约束什么时候开始类加载过程的第一个阶段：加载，而是交由虚拟机的具体实现自由把握，但是虚拟机规范严格规定有且只有4种情况（这4种情况将在后面初始化部分进行介绍）必须立即对类进行初始化，相应的加载、验证和准备阶段自然要在初始化阶段开始之前开始

task:

在加载阶段，虚拟机需要完成以下三件事（虚拟机规范对这三件事的要求并不具体，因此虚拟机实现与具体应用的灵活度相当大）：

1，通过一个类的全限定名获取定义这个类的二进制流

可以从jar包、ear包、war包中获取，可以从网络中获取（Applet），可以运行时生成（动态代理），可以通过其它文件生成（Jsp）等

虚拟机规范并没有指明二进制流要从从一个Class文件中获取，准确的说是没有指明从哪里获取及如何获取（完全可以通过使用自己实现的类加载器读入一二进制流来完成加载阶段，但是一般情况下二进制流的来源还是Class文件，jar中保存的是Class文件，Jsp也是首先被编译成Class文件）

2，将这个字节流代表的静态存储结构转化为方法区的运行时数据结构

虚拟机规范并未规定方法区存储数据的具体数据结构，数据存储格式由虚拟机实现自行定义

3，在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口

验证（Verification）

start time:

加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段还未结束，连接阶段可能已经开始，这部分夹杂在加载阶段进行的动作，依然属于连接阶段的内容，并且加载阶段必定早于连接阶段开始

task:

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

Java语言本身是相对安全的语言（相对于C/C++），使用纯粹的Java代码无法做到诸如访问数组边界之外的数据、将一个对象转型为它未实现的数据类型、跳转到不存在的代码行等，如果这样做了，编译器将拒绝编译，但是Class文件不一定由Java源码编译而来，完全可以使用任何途径，如：用十六进制编辑器直接编写来产生Class文件，在字节码层面上，上述Java代码无法做到的事情都是可以实现的，此时虚拟机如果不检查输入的字节流，很有可能因为载入了有害的字节流而导致系统崩溃，所以验证时虚拟机对自身保护的一项重要工作

虚拟机规范对该阶段的规定非常笼统，仅要求如果验证到输入的字节流不符合Class文件的存储格式，就抛出一个java.lang.VerifyError异常（JDK1.6的API文档对该异常类的描述为：当“校验器”检测到一个类文件虽然格式正确，但包含着一些内部不一致问题或安全性问题时，抛出该错误）或其子类