包括7个阶段： 加载、验证、准备、解析、初始化、使用 和 卸载。
（其中验证、准备、解析3个部分统称为连接（Linking））
解析阶段 在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
（规范验证、安全验证）
准备阶段是正式为 类变量 分配内存并设置类变量 初始值 的阶段，这些变量所使用的内存都将在方法区中进行分配。
假设一个类变量的定义为：
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器 < clinit >() 方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
虚拟机将常量池内的符号引用替换为直接引用的过程。
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器 < clinit >() 方法的过程
（该方法为 Class对象的构造方法）
public class Test{
static{
i=0; //给变量赋值可以正常编译通过
System.out.print(i); //这句编译器会提示"非法向前引用"
}
static int i=1；
}
父子类的执行顺序：
对象的构造方法编译为字节码 < init >,也是类似 < clinit > 收集的过程
（收集 成员变量 + 实例代码块 + 构造方法）
类加载器可以分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器。他们的关系一般如下：
这个类将器负责将存放在＜JAVA_HOME＞\lib 目录中的类库加载到虚拟机内存中
这个加载器由sun.misc.Launcher $ExtClassLoader实现，它负责加载＜JAVA_HOME＞\lib\ext 目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
工作过程：
如果一个类加载器收到了类加载的请求，它首先 不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派机制：
实现：
实现双亲委派的代码都集中在 java.lang.ClassLoader 的 loadClass () 方法之中，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的 loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的 findClass（）方法进行加载。
以下为ClassLoader中的代码：
双亲委派的具体逻辑就实现在这个方法之中，JDK1.2 之后已不提倡用户再去覆盖 loadClass（）方法，而应当把自己的类加载逻辑写到findClass（）方法中，在 loadClass（）方法的逻辑里如果父类加载失败，则会调用自己的 findClass（）方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的。
类加载器给⽤用户提供最⼤大的帮助为：可以通过动态的路径进行类的加载操作。
比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。