注:此文是我在读完周志明老师的深入理解Java虚拟机之后总结的一篇文章，请阅读此书获取更加详细的信息．
类加载的时机
遇到new, getstatic, putstatic, invokestatic四条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化．生成这四条指令的最常见的Java代码场景是:使用new关键字实例化对象的时候，读取或设置一个类的静态字段(被final修饰，已在编译器把结果放入常量池的静态字段除外)的时候，以及调用一个类的静态方法的时候．
使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化．
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化．
当虚拟机启动时，用户需要指定一个要执行的主类(包括main()方法的那个类)，虚拟机会先初始化这个主类
当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic, REF_putStatic, REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化．
接口的加载过程和类的加载过程有一些区别，主要体现在上面的第三点，当一个类在初始化时，要求其父类全部都已经初始化过了．而接口在初始化时，并不要求其父接口全部都完成了初始化，仅在使用的时候才会初始化．
类加载过程
类加载分为下面的几个阶段:
- 加载
- 连接
- 验证
- 准备
- 解析
- 初始化
下面我们将会详细介绍每个阶段要做的事情．
需要注意的是，这几个阶段并不是严格按照的按照先后顺序来完成的，比如，验证阶段的最后一个验证过程就是穿插在解析阶段中进行的．
加载阶段
在加载阶段，虚拟机需要完成下面的三件事:
- 通过一个类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
一个非数组类的加载阶段是我们开发人员可以操控的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，所以我们完全可以通过自定义类加载器来实现按照我们想要的方式加载，修改字节码等．
而对于数组类，情况就不是这样的．因为数组类本身不是通过类加载器创建的，它是由Java虚拟机直接创建的．但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终还是要靠类加载器去创建，一个数组类(下面简称为C)的创建过程遵循下面的规则：
如果数组的元素类型是引用类型，那么就递归的先加载这个引用类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识．
如果不是引用类型，而是基本数据类型，那么数组C就会与引导类加载器关联
数组类的可见性与它的元素类型的可见性一致，如果是基本数据类型，那么默认的可见性为public
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构．然后在内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口．
加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序．
验证阶段
我们上面也提到了，可以通过自定义类加载器的方式，来改写字节码，那么万一有不怀好意的人在其中加入了攻击代码怎么办?
所以，我们需要这样一个验证阶段，保证字节码是没有问题的．
验证阶段又分为下面的几个阶段:
- 文件格式验证
- 元数据验证
- 字节码验证
- 符号引用验证
文件格式验证是验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理．
文件格式验证的部分内容是：
- 是否以魔数0xCAFEBASE开头
- 主次版本号是否在当前虚拟机处理范围之内
- 常量池的常量中是否有不被支持的常量类型
- 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
- CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
- Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
文件格式验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区进行存储．后面的三个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流．
元数据验证是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下:
- 这个类是否有父类(除了java.lang.Object之外，所有的类都应当有父类)
- 这个类的父类是否继承了不允许被继承的类(被final修饰的类)
- 如果这个类不是抽象类，是否实现了其父类或接口之后在那个要求实现的所有方法
- 类中的字段，方法是否与父类产生矛盾(例如覆盖了弗雷德final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值参数却不等同)
第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息．
字节码验证将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，例如:
- 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这种情况：在操作数栈中放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中．
- 保证方法跳转指令不会跳转到方法体以外的字节码指令上
- 保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是不能把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系，完全不相干的一个数据类型，则是危险和不合法的．
但是，即使一个方法通过了字节码验证，也不能百分百保证这个方法就是安全的．
符号引用验证发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段－解析阶段中发生．符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性验证，通常需要校验下列内容:
- 符号引用中通过字符串描述的全限定名是否能找到对应的类
- 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
- 符号引用中的类，字段，方法的访问性是否可被当前类访问
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError, java.lang.NoSuchFieldError, java.lang.NoSuchMethodError等．
对于虚拟机的类加载机制来说，验证阶段是一个非常重要的，但不是一定必要的阶段．如果所运行的全部代码都已经被反复使用和验证过，那么实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间．
准备阶段
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中分配．
注意这个阶段分配的变量仅是类变量，不包括实例变量．实例变量会在对象实例化时随着对象一起在堆中分配．
另外，这里说的初始值，一般是对应的数据类型的零值．假设一个类变量的定义为:
public static int value = 123;
在准备阶段，value将会被初始化为int对应的零值0．而把value赋值为123的动作将在初始化阶段才会执行．
在通常情况下会被初始化为零值，当然也有特殊情况：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，假设上面类变量value的定义为:
public static final int value = 123;
编译时Javac将会为value生成ConstantValue属性值，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值给123.
解析阶段
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程．那么什么是符号引用，什么是直接引用呢?
符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可．符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中．各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中．
直接引用：直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄．直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同．如果有了直接引用，那引用的目标必定已经在内存中存在．
简单来说，就是符号引用就是一个字符串，如类的全限定名．而直接引用就是一个reference类型．可以通过句柄或者直接引用的方式实现．
针对类，方法和字段，解析又分为好几种不同的类型：
-
类或接口解析：假设当前代码所处的类为D,如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用
- 如果C不是一个数组类型，那么虚拟机将会把代表N的全限定名传给D的类加载器去加载这个类C．在加载过程中，由于元数据验证，字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现接口．一旦这个加载过程出现了任何异常，解析过程就宣告失败．
- 如果C是一个数组类型，并且数组的元素类型为对象，那么先按照第一条规则加载数据的元素类型，接着由虚拟机生成一个代表次数组维度和元素的数组对象．
- 如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限．如果发现不具备访问权限，将抛出java.lang.IllegalAccessError.
-
字段解析：要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index项张索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用．如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析失败．如果解析成功，那将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的搜索
- 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束
- 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符斗鱼目标相匹配的字段，则返回这个字段的直接引用，查找结束
- 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束．
- 否则，查找失败，抛出java.lang.NoSuchFieldError异常
- 如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常．
-
类方法解析：类方法解析的第一个步骤与字段解析一样，也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，我们依然用C表示这个类，接下来虚拟机将按照如下步骤进行后续的类方法搜索
- 类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C是个接口，那就直接抛出java.lang.IncompatibleClassChangeError异常．
- 如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束
- 否则，在类C的父类中递归查找是否有简单名称和描述符都与目标匹配的方法，如果有则返回这个方法的直接引用，查找结束．
- 否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C是一个父类，这时查找结束，抛出java.lang.AbstractMethodError异常
- 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError
-
接口方法解析：先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，依然用C表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索
- 与类方法解析不同，如果在接口方法表中发现class_index中的索引C是个类而不是接口，那就直接抛出java.lang.IncompatibleClassChangeError异常
- 否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束
- 否则，在接口C的父接口中递归查找，直到java.lang.Object为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束
- 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常．
初始化阶段
在初始化阶段中，对象按照程序员的意愿进行初始化．在准备阶段，已经为类变量赋值过一个零值，这个阶段则是将类变量初始化为程序员指定的值．换句话说，初始化阶段是执行
那么
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成
虚拟机会保证一个类的
去执行这个类的
类加载器
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立骑在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间．比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等．
双亲委派模型
上图中的展示的这种类加载器之间的这种层次关系，就被称为类加载器的双亲委派模型．双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器．这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都采用组合关系来复用类加载器的代码．
我们下面详细介绍上面提到的三个主要的类加载器:启动类加载器(Bootstrap ClassLoader), 扩展类加载器(Extension ClassLoader), 应用程序类加载器(Application ClassLoader).
启动类加载器(Bootstrap ClassLoader)：这个类加载器负责将存放在
\lib 目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的(仅按照文件名识别，如rt.jar.名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中．启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可．扩展类加载器(Extension ClassLoader)：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载
\lib\ext 目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器加载．应用程序类加载器(Application ClassLoader)：这个类加载器由sun.misc.Launcher$AppClassLoader实现．由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器．它负责加载用户类路径上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器．
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当附加在其反馈自己无法完成这个加载请求(它的搜索范围没有找到搜索的类)时，子加载器才会尝试自己去加载．
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种具有优先级的层次关系．例如类java.lang.Object,它存放在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类．相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个成为java.lang.Object的话，并放在程序的ClassPath中，那系统将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一篇混乱．
双亲委派模型也只是JVM规范中推荐我们使用的方式，在必要的时候，我们完全可以打破这种规则．比如OSGI的实现．