JVM之类加载机制

       在上一篇文章中我们了解了Class文件存储格式的具体细节，在Class文件中描述的各种信息，最终都要加载到虚拟机中之后才能运行和使用。而虚拟机如何加载这些Class文件？Class文件中的信息进入到虚拟机后会发生什么变化？这些都是本文所需要解决的问题！

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

类加载的时机

      类从北加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析三个部分统一称为Linking（）链接。其中加载、验证、准备、初始化和卸载这五个阶段的顺序是确定过的，类加载的过程必须按照这种顺序执行，但是解析则不一定：解析有时候会在初始化阶段之后再开始。

     那么什么时候需要开始类加载、验证····初始化完全呢？有以下五种情况类就必须要初始化：

   （1）遇到new、getstatic、putstatic和invokestatic这4条指令时，翻译过来就是：使用new创建对象时、读取或者调用设置使用一个static字段时、以及调用static方法时。

   （2）使用反射时

   （3）当初始化一个类的时候，如果发现其父类没有初始化，则需要先触发其父类的初始化。

   （4）当虚拟机启动时，用户需要指定一个要执行的主类（有main（）方法的类），虚拟机会先初始化这个类。

   （5）当使用JDK1.7的动态语言支持时，如果一个MethodHandler实例后的解析结果REF_getstatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先初始化。

    JVM规范中规定，只有以上5种场景才会触发类的初始化，这五种行为被称为主动行为，初次之外，所有引用类的方式都不会触发初始化，被称为被动引用，有两个典型的被动引用例子：

   （1）在子类中引用父类的静态字段，不会导致子类初始化。

   （2）常量在编译阶段会存储调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。简单点就是当调用static final定义的字段时，不会导致类的初始化。

类加载的过程

      接下来就详细讲解一下Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这五个过程以及其具体的动作。

加载

      “加载”是“类加载”过程的一个阶段，而这不能混淆，在加载过程中，虚拟机要完成以下三件事情：

    （1）通过一个类的全限定名来获取定义此类的二进制字节流。

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

    （3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法去这个类的各种数据的访问入口。

     相对于类加载过程的其它阶段，一个非数组类的加载阶段（准确的说，是加载阶段中获取类的二进制字节流的）是开发人员可控制性最强的，因为加载阶段金额可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的loadClass（）方法即可）。

     对于数组类而言，情况就有所不同，数组泪本身不通过类加载器创建，它是由虚拟机直接创建的，但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建，一个数组类创建过程需要遵循以下规则：

    （1）如果数组的组建类型（指的是数组去掉一个维度的类型）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将在加载该组建的类加载器的类名称空间上被标识。

    （2）如果数组的组建类型不是引用类型（例如int[] arr），Java虚拟机将会把数组C标记为与引导加载器一起确定唯一性。

    （3）数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

     类加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需要的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义。然后在内存中实例化一个Class类的对象，Class对象比较特殊，它虽然是对象，但是存放在方法区里，这个对象将作为程序访问方法区中的这些类型数据的外部接口。

验证

      验证时链接阶段的第一部，这一阶段的目地市确保Class文件的字节流中包含的信息符号当前虚拟机的要求，并且不会危害虚拟机自身安全。

      验证阶段是非常重要的，这个阶段是否严谨，直接决定了Java虚拟机是否能陈寿恶意代码的攻击，从执行性能的角度来说，验证阶段的工作量在虚拟机的类加载子系统中又占类相当大的一部分，从整体来说，验证阶段主要包括以下四个阶段。

文件格式的验证

    （1）是否以魔术0xCAFEBABY开头

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

    （3）常量池的常量是否有不被支持的常量类型

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

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

       实际上，第一阶段的验证点远远不止这一点，这个恶阶段的验证时基于二进制字节流进行的，只有通过了这个阶段的验证之后，字节流才会进入内存的方法区中进行存储，所以后面三个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。

元数据验证

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

   （1）这个类是否有父类

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

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

   （4）类中的字段、方法是否与父类产生矛盾

       这个阶段的主要目的是对类的元数据进行语义检查，保证不存在不符合Java语言规范的元数据信息。

字节码验证

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

    （1）保证任意时刻操作数栈的数据类型与质量代码序列都能配合工作，例如不会出现类似这样的情况：在操作数栈放类一个int类型数据，使用时却按long类型来加入本地变量表

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

    （3）保证方法体重的类型转换时有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，这是危险并且不合法的/。

       如果一个类方法体字节码没有通过字节码验证，那肯定是有问题的：但如果一个方法体通过类字节码验证不一定就是安全的/。

符号引用验证

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

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

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

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

     符号引用验证的目地市确保解析动作能正常执行，如果无法通过符号引用验证。那么将会抛出如下异常：java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等

     对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要的阶段。

准备

     准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中static类型的变量只是初始化为“零”值，并不是初始化为程序员指定的值。而实例变量在此时不会被初始化，它会被随着对象一起分配在Java堆中。比如：public static int value =123,此时value被初始化为0，而不是123。

解析

      解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用在前面讲Class文件格式的时候讲过：

     （1）符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用雨虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存，各种虚拟机实现的内存布局可以各不相同，但是他们能接受的符号引用必须都是一致的。

     （2）直接引用：直接引用可以是直接指向目标的指针，相对便宜量或者是一个能简介定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关，所以同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。

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

初始化

      类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除类在加载阶段用户应用程序可以通过自定义类加载器参与外，其余动作完全由虚拟机主导完成。在准备阶段变量已经赋值过一次系统要求的值，而在初始化阶段，则根据程序员指定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始阶段是执行类构造器方法的过程。

类加载器

      虚拟机设计团队把类加载阶段中的”通过一个类的全限定名来获取描述此类的二进制字节流“这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称为“类加载器”。

 类与类加载器

      类加载器虽然只用于实现类的加载动作，但是它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在JVM中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。即：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使这两个类来源于同一个文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类就一定不相同。

双亲委派模型

      从Java虚拟机的角度来说，只存在两种不同的类加载器：一种是启动类加载器，这个类加载器使用C++语言实现，是虚拟机自身的一部分，另一种是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自ClassLoader类。

     双亲委派模型是这样的：如果一个类加载器收到了类加载的请求，它首先不会对自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子类加载器才会尝试自己去加载。更多的关于类加载器参考：http://www.cnblogs.com/lanxuezaipiao/p/4138511.html