1. 加载。
加载阶段，虚拟机主要完成3件事：
(1) 通过一个类的全限定名来获取此类的二进制字节流。
(2) 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
(3) 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
这里二进制字节流的来源（虚拟机没有做规定）：
(1) 从ZIP、JAR、EAR、WAR中读取；
(2) 从网络中获取
(3) 运行时计算生成（动态代理）
(4) JSP文件生成
(5) 从数据库中读取
……
一个非数组类的加载既可以使用系统提供的引导类加载器完成，也可以由用户自定义类加载器去完成（即重写一个类加载器的loadClass()方法）
（PS：为什么会有自定义类加载器？
一方面是由于java代码很容易被反编译，如果需要对自己的代码加密的话，可以对编译后的代码进行加密，然后再通过实现自己的自定义类加载器进行解密，最后再加载。另一方面也有可能从非标准的来源加载代码，比如从网络来源，那就需要自己实现一个类加载器，从指定源进行加载。）
而数组类的加载情况则不同，它不通过类加载器创建，而是由Java虚拟机直接创建。但是数组类中的单个元素最终还是要靠类加载器去创建。一个数组类（下面称为数组C）的创建过程遵循以下规则：
(1) 如果数组的组件类型（指数组去掉一个维度的类型）是引用类型，那就按照这些规则递归地加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识（一个类必须与类加载器一起确定唯一性）
(2) 如果数组的组件类型不是引用类型（如int[]数组），Java虚拟机将会把数组C标记为与引导类加载器关联。
(3) 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。
加载阶段完成之后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中。然后在内存中实例化一个java.lang.Class类的对象（没有明确规定是在Java堆中，对于HotSpot来说，Class对象很特殊，它虽然是对象，但存放在方法区），这些对象将作为程序访问方法区中的这些类型数据的外部接口。
加载阶段与连接阶段的部分内容（如部分字节码文件格式的验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但两者的开始时间仍然保持固定的先后顺序。
2. 验证
验证的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。这个阶段很重要，但却不是一定必要，如果运行的全部代码已经被反复使用和验证过，可以使用参数-Xverify:none来关闭验证，缩短类加载时间。
验证过程大致分为以下4个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。
(1) 文件格式验证
验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
该阶段的目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中存储，所以后面的3个验证阶段全部是基于方法区的存储结构进行，而不是直接操作字节流。
可能的验证点有：
是否以魔数0xCAFEBABE开头；
主次版本号是否在当前虚拟机处理范围内；
常量池中的常量是否有不被支持的常量类型；
……
(2) 元数据验证
对类的元数据信息进行语义校验，保证其描述的信息符合Java语言规范。
可能的验证点有：
这个类是否有父类（除了java.lang.Object类之外，所有的类都应当有父类）；
这个类的父类是否继承了不允许被继承的类（被final修饰的类）；
如果这个类不是抽象类，是否实现了其父类或者接口中要求实现的所有方法；
……
(3) 字节码验证
最复杂的一个阶段，通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的。这个阶段对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，如：
保证跳转指令不会跳转到方法体以外的字节码指令上；
保证方法体中的类型转换是有效的；
……
PS：方法体即使通过了字节码验证，也不是绝对安全的。（通过程序去检验程序，无法做到绝对准确）
(4) 符号引用验证
该验证发生在虚拟机将符号引用转化为直接引用的时候，它将在连接的第三阶段——解析阶段中发生。目的是保证解析动作能正常执行，通常的验证点如：
通过字符串描述的全限定名是否能找到对应的类；
符号殷勇忠的类、字段、方法的访问性（public、protected、private、default）是否可被当前类访问；
……
3. 准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。
PS：
(1) 这里进行内存分配的仅包括类变量（被static修饰的变量），不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中；
(2) 这里所说的初始值通常是指数据类型的零值，如 public static int value = 123;那么变量value在准备阶段过后的初始值是0，而不是123。但也有特殊情况，假设 public static final int value = 123；那么编译时，会为value生成ConstantValue属性，在准备阶段就会为value赋值为123。
4. 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
(1) 符号引用：
符号引用以一组符号来描述所引用的目标，符号引用可以是任何形式的字面量，符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经在内存中。
(2) 直接引用：
直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般都不相同，如果有了直接引用，那引用的目标必定已经在内存中存在。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行，这里讲解前面4种引用的解析过程（后面3种与JDK1.7新增的动态语言支持相关，这里先不讲）：
(1) 类或接口的解析
判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。
(2) 字段解析
对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。
(3) 类方法解析
对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。
(4) 接口方法解析
与类方法解析步骤类似，只是接口不会有父类，因此，只递归向上搜索父接口就行了。
5. 初始化
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了加载（Loading）阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码。
初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：
①声明类变量时指定初始值
②使用静态代码块为类变量指定初始值
JVM初始化步骤
(1) 假如这个类还没有被加载和连接，则程序先加载并连接该类
(2) 假如该类的直接父类还没有被初始化，则先初始化其直接父类
(3) 假如类中有初始化语句，则系统依次执行这些初始化语句
初始化阶段是执行类构造器<clinit>()方法的过程，其中的特点的细节如下：
(1) <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序所决定。
(2) <clinit>()方法与类的构造函数不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕，因此在虚拟机中第一个执行的<clinit>()方法的类一定是java.lang.Object。
(3) 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
(4) <clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
(5) 接口中不能使用静态语句块，但可能会有变量赋值操作，因此接口也会生成<clinit>()方法。但是接口与类不同，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也不会执行接口的<clinit>()方法。
(6) 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步。如果有多个线程去同时初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其它线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那么就可能造成多个进程阻塞。