Java 类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中，验证、准备和解析统称为连接（Linking）。过程如下图所示。

图1 类加载过程

一、加载（Loading）

“加载”是虚拟机类加载的第一个阶段，在这个阶段中，虚拟机要完成3件事情：
1、通过类的完全限定名，查找此类字节码文件，获取类的二进制字节流；
2、将字节流的静态数据结构转化为方法区的运行时数据结构；
3、在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区中这个类数据结构的访问入口。

二、验证（Verification）

“验证”是连接阶段的第一步，这一阶段是为了确保 Class 文件内的字节流格式符合当前Java虚拟机的要求，不会危害虚拟机安全。
Java 语言本身是相对安全的语言，但是用纯粹的Java 代码无法做到诸如访问数组边界之外的数据、将对象转型为它未实现的类型、跳转到不存在的代码行之类的事情，如果这么做了，编译器会拒绝编译。但是由于 Class 文件的产生并不强制要求必须是 Java 代码编译而来，你甚至可以自己用十六进制编辑器直接编写 Class 文件。如果不进行 Class 文件校验的话，很有可能会因为载入了有害的字节流导致虚拟机崩溃。

验证总体上分为4个阶段： 文件格式验证 、 元数据验证 、 字节码验证 、 符号引用验证 。
1、文件格式验证
这阶段主要是检查字节流是否符合Class 文件的规范，版本是否能够处理，包括下面这些验证点：
（1）是否以魔数开头
（2）主次版本是否在当前虚拟机处理范围之内
（3）常量池的常量中是否有不被支持的常量类型（检查常量tag标志）
（4）指向常量的各种索引中是否有指向不存在的常量或不符合类型的常量
（5）CONSTANT_Utf8_info 型的常量中是否有不符合UTF8 编码的数据
（6）Class 文件中各个部分以及文件本身是否有被删除的或被附加的其它信息
文件格式验证主要是针对字节流进行验证，经过了这一步验证之后，字节流才会进入内存的方法区进行存储，所以后面的3个验证阶段全部都是基于方法区的存储结构进行的，不会再操作字节流。
2、元数据验证
这一阶段主要是对字节码描述的信息进行语义分析，验证类的继承关系，验证点如下：
（1）这个类的父类是否允许被继承（final 修饰的类）
（2）这个类如果不是抽象类，是否实现了父类或接口之中要求实现的所有方法
（3）类中的字段、方法是否和父类产生矛盾（如覆盖了父类final 字段，出现了非法的方法重载）
3、字节码验证
字节码验证是验证过程中最复杂的一个阶段，它的目的是确定程序语义是合法的、符合逻辑的。在元数据验证完成之后，它会对方法体进行验证，确保程序不会做出危害虚拟机安全的行为。
（1）保证任何时候，操作数栈的数据类型与指令代码序列都能配合工作
（2）保证跳转指令不会跳转到方法体外的字节码指令上
（3）保证方法体中类型转换是有效的
4、符号引用验证
最后一个阶段的验证发生在虚拟机将符号引用转化为直接引用的时候，这个阶段将会在解析阶段发生。符号引用验证可以看做是对类自身以外的信息进行匹配校验。
（1）符号引用中通过字符串描述的类的完全限定名是否能找到相应的类
（2）在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
（3）符号引用中的类、字段、方法的访问性是否可被当前类访问
符号引用验证是为了保证解析动作能正常执行。这个阶段可以用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

三、准备（Preparation）

“准备”阶段是正式为类变量（仅仅是类变量，即 static 修饰的变量， 不包含final修饰的静态变量,因为final变量在编译时分配 ）分配内存并设置类变量初始值（0或null）的阶段，这些变量所使用的内存都将在方法区中进行。

四、解析（Resolution）

“解析”阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用以 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Mehodref_info 等类型的常量出现（即 类名称，变量名称，方法名称等信息）。那么符号引用与直接引用有什么关联呢？
符号引用 （Symbolic References）：即用一组符号来描述所引用的目标。它与虚拟机的内存布局无关，引用的目标不一定已经加载到内存中。
直接引用 （Direct References）：直接引用可以是指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。它是和虚拟机内存布局相关的。
解析动作主要针对 类或接口、字段、类方法、接口方法、方法类型、方法句柄 和 调用限定符7类符号引用进行。
1、类或接口的解析
假如类D 要把一个从未解析过的符号引用N 解析为一个类或接口C 的直接引用，那虚拟机解析过程需要3个过程：
（1）如果C不是一个数组类型，虚拟机会把 N 的完全限定名传递给 D 的类加载器去加载这个类C 。由于元数据验证 和 字节码验证 的过程， 可能会触发其它相关类的加载动作。
（2）如果C是一个数组类型，并且数组元素类型为对象，那将会按照第一点规则加载数组元素类型。
（3）如果上面步骤没有任何异常， 那么 C 已经成为了一个有效的类和接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。否则会抛出java.lang.IllegalAccessError 异常。
2、字段解析
首先对字段的位于class_index 项中索引的 CONSTANT_Class_info 符号引用，也就是字段所属的类或接口的符号引用进行解析，如果解析顺利的话，虚拟机将按照下列步骤进行字段搜索。
（1）如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（2）否则，如果C 中实现了接口，会按继承关系从下往上递归搜索其父接口，如果在父接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（3）否则，如果C 不是 java.lang.Object 的话，将会按继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
（4）否则，查找失败，抛出 java.lang.NoSuchFieldError 异常。
如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出 java.lang.IllegalAccessError 异常。
3、类方法解析
类方法解析第一步和字段解析是一样的，都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果顺利的话，虚拟机将按下列步骤进行字段搜索。
（1）如果发现class_index 索引的C是个接口，那就抛出 java.lang.IncompatibleClassChangeError 异常。
（2）如果通过了第一步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（3）否则，在类C的父类中递归查找，如果有就直接返回方法的直接引用，查找结束。
（4）否则，在类C 实现的接口列表以及他们的父接口中递归查找，如果存在，则说明C是一个抽象类，查找结束并抛出 java.lang.AbstractMehodError 的异常。
（5）否则，查找失败，抛出 java.lang.NoSuchMethodError 异常.
最后如果查找成功，会进行权限验证。失败会抛出 java.lang.IllegalAccessError
4、接口方法解析
接口方法解析第一步和字段解析是一样的，都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用，如果顺利的话，虚拟机将按下列步骤进行字段搜索。
（1）如果接口方法表中发现 class_index 中的索引C是个类而不是接口，就直接抛出 java.lang.IncompatibleClassChangeError 异常。
（2）否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束
（3）否则，在接口C 的父接口中递归查找，直到 java.lang.Object 类位置，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
（4）否则，查找失败，抛出 java.lang.NoSuchMethodError 异常。
由于接口方法都是public的，所以不存在访问权限的问题，因此接口方法的符号解析应当不会抛出 java.lang.IllegalAccessError 异常。

五、初始化

“初始化”是类加载的最后一步，到了这一步，才是真正开始执行类中定义的Java 程序代码。
（1）类构造器<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句快可以赋值，但是不能访问。
（2）类构造器<clinit>()方法与类的构造函数(实例构造函数<init>()方法)不同，它不需要显式调用父类构造，虚拟机会保证在 子类<clinit>()方法执行之前，父类的<clinit>()方法已经执行 完毕。 因此在虚拟机中的第一个执行的<clinit>()方法的类肯定是java.lang.Object。
（3）由于父类的<clinit>()方法先执行，也就意味着 父类中定义的静态语句快要优先于子类的变量赋值操作 。
（4）<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句，也没有变量赋值的操作，那么编译器可以不为这个类生成<clinit>()方法。
（5）接口中不能使用静态语句块，但接口与类不同的是， 执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法 。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
（6） 虚拟机会保证一个类的<clinit>()方法在多 线程 环境中被正确加锁和同步 ，如果多个线程同时去初始化一个类，那么只会有一个线程执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果一个类的<clinit>()方法中有耗时很长的操作，那就可能造成多个进程阻塞。

六、类的加载机制

图2 双亲委派模式

Java 类加载器（ClassLoader），顾名思义，即加载类的东西。在我们使用一个类之前，JVM需要先将该类的字节码文件（.class文件）从磁盘、网络或其他来源加载到内存中，并对字节码进行解析生成对应的Class对象，这就是类加载器的功能。我们可以利用类加载器，实现类的动态加载。

在Java中，采用双亲委派机制来实现类的加载。所谓双亲委派机制（图2）， 即加载器加载类时先把请求委托给自己的父类加载器执行,直到顶层的启动类加载器.父类加载器能够完成加载则成功返回,不能则子类加载器才自己尝试加载。

Java 提供三种类型的系统类加载器。第一种是启动类加载器（Bootstrap ClassLoader），由C++语言实现，属于JVM的一部分，其作用是加载 <Java_Runtime_Home>/lib 目录中的文件（图3），并且该类加载器只加载特定名称的文件（如 rt.jar），而不是该目录下所有的文件。另外两种是 Java 语言自身实现的类加载器，包括扩展类加载器（ExtClassLoader）和应用类加载器（AppClassLoader），扩展类加载器负责加载<Java_Runtime_Home>\lib\ext目录中或系统变量 java.ext.dirs 所指定的目录中的文件。应用程序类加载器负责加载用户类路径中的文件。用户可以直接使用扩展类加载器或系统类加载器来加载自己的类，但是用户无法直接使用启动类加载器，除了这两种类加载器以外，用户也可以自定义类加载器（图2）。

采用双亲委派机制有如下优点：

1. 避免类的重复加载

2. 避免Java的核心API被篡改