一、 概述
虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
二、 类加载的时机
类从加载到虚拟机内存开始，到卸载出内存为止，整个生命周期包括：加载 、验证 、 准备 、 解析 、 初始化 、 使用和卸载 这7个阶段。验证、准备和解析部分统称连接，如下图：
类加载的过程包括加载、验证、准备、解析和初始化这5个阶段，其中加载、验证、准备、初始化的顺序是确定的，类加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。注意，这里是按部就班地开始，而不是按步就班地进行或完成，这是因为这些阶段都是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段。
在Java虚拟机中对初始化阶段规定了有且只有5种情况必须对类进行初始化（而加载、验证、准备自然需要在此之前开始 ）：
1.遇到 new(创建类实例)、getstatic(访问类变量)、putstatic(访问类变量)或invokestatic(调用类方法)这4条字节码指令时，如果类 没有进行过初始化，则需要先触发其初始化。
2.使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3.当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类初始化。
4.当虚拟机启动时，用户需要制定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5.当使用JDK 1.7的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄(使用MethodHandle对类变量的操作或者对类方法的调用)，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
三、 类加载的过程
如上面所说类加载的过程包括加载、验证、准备、解析和初始化5个阶段，接下来介绍这5个阶段所执行的具体动作。
（1） 加载
“加载” 是 “类加载” 过程中的一个阶段，在这个阶段中，虚拟机需要完成以下3件事情：
1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
在虚拟机规范中对这3点要求其实并不算具体，因此虚拟机实现与具体应用的灵活度都是相当大的。例如上面的第一点中没有指明 二进制字节流要从一个Class文件中获取，它可以是从ZIP、JAR等格式中读取、或者是从网络（最典型的应用就是Applet）等方式获取。
相对于类加载过程的其他阶段，一个非数组类的加载阶段是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式。而对于数组类来说，数组类本身不通过类加载器创建，它是由Java虚拟机直接创建，但是数组类的元素类型最终要靠类加载器去创建。
加载完成后，虚拟机外部的二进制字节流就按照虚拟机所需要的格式存储在方法区之中（数据存储格式由虚拟机自行定义），然后会在内存中实例化一个java.lang.Class类的对象，存放在方法区之中。
说到加载，就应该说说实现类的加载动作的类加载器。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，也就是说即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的 “相等” 指的是类的Class对象的 equals()、isAssignableFrom() 方法、isInstance() 方法的返回结果，也包括用instanceof关键字做对象所属关系判定等情况。
从虚拟机的角度来讲，只存在以下两种不同的类加载器：
1. 启动类加载器： 使用C++语言实现，是虚拟机自身的一部分；
2. 所有其他的类加载器： 这些类加载器都由Java语言实现，独立于虚拟机外部，并且都继承自抽象类 java.lang.ClassLoader；
从Java开发人员的角度来看，类加载器还可以划分得更细致一些，绝大部分Java程序都会使用到以下3中系统提供的类加载器：
启动类加载器： 这个类加载器负责加载 <JAVA_HOME>\lb目录中的，或者被 -Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar, 名字不符合的类库即使放在lib目录中也不会被加载）的类库加载到虚拟机内存中。
扩展类加载器： 这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext 目录中的，或者是被 java.ext.dirs 系统变量所指定的路径中的所有类库。
应用类加载器： 这个类加载器由sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是 ClassLoader中的 getSystemClassLoader() 方法的返回值，所以一般称它为系统类加载器。它负责加载用户类路径上所指定的类库，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
我们的应用程序都是由这3中类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系一般如下图所示。
如上图展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。
什么是双亲委派模型？
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父类加载器。
双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去架子啊
双亲委派模型的好处：Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object， 它存放在rt.jar 之中， 无论哪一种类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器加载，因此Objet类在程序的各种类加载器环境中都是同一个类。
（2） 验证
验证的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致上会完成4个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。
1） 文件格式验证：这一阶段是验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。该阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。
2） 元数据验证：这一阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。
3） 字节码验证：这一阶段主要对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。
4） 符号应用验证： 这一阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么会抛出一个 java.lang.IncompatibleClassChangeError 异常的子类，如 java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等.
（3） 准备准备阶段是正式为类变量分配内存并设置类变量的初始值的阶段，这些类变量所用的内存都将在方法区中分配。首先，这里进行内存分配的只是类变量（用static修饰的变量），而不包括实例变量。其次，这里所说的初始值“通常情况” 下是数据类型的零值，假设一个类变量的定义为：
public static int value = 2;
那这个类变量在准备阶段过后value为0而不是2，而将value赋值为2的动作是在初始化阶段才会执行。下表列出Java所有基本数据的零值。
上面所说在“通常情况” 下初始值是零值，那相对的会有一些 “特殊情况”：如果在该类变量同时被 static 和 final 修饰，也就是该类字段的字段属性表中存在ContantValue属性，那在准备阶段变量value就会被初始化为ContantValue属性所指定的值，如下：
public static final int value = 2；
上面代码在编译时会为value生成ContantValue属性，然后在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为2
（4） 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，其中包括对类与接口的解析、字段解析、类方法解析、接口方法解析。
1）类与接口的解析：判断直接引用是指向数组类型，还是指向普通类型，然后进行不同的解析。
2）字段解析：对字段进行解析时，首先会查找本类中是否包含了简单名称和字段描述符都与目标相匹配的字段，有则返回这个字段的直接应用并且查找结束。没有的话则按照继承关系从下往上递归搜索各个接口和它的父接口，还没有的话就按照继承关系从下往上搜索其父类。所以查找顺序为 本类 --> 接口 --> 父接口 。。。 --> 父类 --> 祖父类 。。
在实际应用中，虚拟机的编译器实现可能比上述的规范要求得更加严格，如果有一个同名字段同时出现在类的接口和父类中，或者同时在自己或父类的多个接口中出现，那编译器将可能拒绝编译，如下面代码，编译器将提示 "The field Sub.A is ambiguous"。
public class FieldResolution {
interface Interface0{
int A = 0;
}
interface Interface1 extends Interface0{
int A = 1;
}
interface Interface2 {
int A = 2;
}
static class Parent implements Interface1{
public static int A = 3;
}
static class Sub extends Parent implements Interface2{
//public static int A = 4;
}
public static void main(String[] args) {
System.out.println(Sub.A);
}
}
3）类方法解析：类方法解析和字段解析差不多，只不过要分 类方法 和 接口方法 进行解析，而且类方法解析是先查询父类，再查询接口 。
4）接口方法解析：接口方法解析和字段解析差不多，区别是接口方法不需要查询父类，只需查询父接口。
（5） 初始化
类初始化阶段是类加载过程的最后一步，前面类加载过程中除了加载阶段中应用程序可以自定义类加载器参与之外，其他都有虚拟机主导和控制。而到了初始化阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>() 方法的过程。
接下来介绍<clinit>()方法以及它在执行过程中一些可能会影响程序运行行为的特点和细节：
1.<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{} 块) 中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
2. <clinit>方法与类的构造函数不同，它不需要显示调用父类构造器，虚拟机会保证在子类的<clinit>() 方法执行之前，父类的<clinit>() 方法已经执行完毕。
3.由于父类的<clinit>()方法先执行，也就意味父类定义的静态语句块优先于子类的变量赋值操作，如下代码：
public class Test
{
static class Parent
{
public static int A = 1;
static {
A = 2;
}
}
static class Sub extends Parent
{
public static int B = A;
}
public static void main(String[] args)
{
System.out.println(Sub.B);
}
}
上面代码的执行结果是 2 ，因为根据第一条规则，类变量和静态语句块的执行顺序是按照编译器收集语句的顺序，也就是源代码中出现的顺序，所以 A 先赋值为 1， 再赋值为 2， 由于上面所说父类的静态语句块优先于子类的变量赋值，所以 B 等于 A 等于 2。
4. <clinit> 方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>() 方法.
5. 接口中不能使用静态语句块，但是仍有变量初始化操作，所以也会生成<clinit>() 方法。但是与类不同的是，执行接口<clinit>() 方法不需要先调用父接口的<clinit>方法，只有使用到父接口定义的变量时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>() 方法。
6. 虚拟机会保证一个类的<clinit>() 方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行<clinit>() 方法完毕