类加载过程详解（JavaGuide 转载）

Guide、guang19 与 JavaGuide 贡献者大约 16 分钟开放阅读JavaGuide转载JVM

转载自 JavaGuide 原文，作者：Guide、guang19 与 JavaGuide 贡献者。
依据 Apache-2.0 许可证收录，见固定快照。
本站移除推广与外部图片嵌入、调整技术链接，技术勘误在文内标注；配图位置的“本站补充”由 IT枫斗者编写，并非原图；文中“我”指原作者。

类的生命周期

类从被加载到虚拟机内存中开始到卸载出内存为止，它的整个生命周期可以简单概括为 7 个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。其中，验证、准备和解析这三个阶段可以统称为连接（Linking）。

这 7 个阶段的顺序如下图所示：

本站图解（非原图）

类的生命周期概念索引。仅根据文字主题重新整理，不复刻未见原图。

概念	阅读要点
加载	从二进制表示创建类或接口
连接	包括验证、准备、解析；阶段约束见下方共用图
初始化	执行类初始化流程，可能调用 `<clinit>`
使用	对类型执行程序操作，不是一道独立的 JVM 连接步骤
卸载	定义类加载器可回收时才可能发生，不保证立即卸载；启动类加载器定义的类型不能卸载

这是一份概念索引，并非七个阶段严格互不重叠的时间线。具体加载约束见本页阶段图。官方依据：JVMS 21 第5章、JLS 21 §12.7。

类加载过程

Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？

系统加载 Class 类型的文件主要三步：加载->连接->初始化。连接过程又可分为三步：验证->准备->解析。

本站图解（非原图）

加载与连接的必要先后约束。

连接包括验证、准备和解析；图中实线表示初始化前必须完成的要求，虚线表示解析时机的灵活性，并不要求两条解析路径都发生。不要把解析画成所有初始化之前都已完成的一次性关卡。此图与生命周期索引共用，避免重复大图。

官方依据：JVMS 21 §5.4。

详见 Java Virtual Machine Specification - 5.3. Creation and Loading。

加载

类加载过程的第一步，主要完成下面 3 件事情：

通过全类名获取定义此类的二进制字节流。
将字节流所代表的静态存储结构转换为方法区的运行时数据结构。
在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口。

虚拟机规范上面这 3 点并不具体，因此是非常灵活的。比如：“通过全类名获取定义此类的二进制字节流” 并没有指明具体从哪里获取（ZIP、 JAR、EAR、WAR、网络、动态代理技术运行时动态生成、其他文件生成比如 JSP...）、怎样获取。

加载这一步主要是通过我们后面要讲到的 类加载器 完成的。类加载器有很多种，当我们想要加载一个类的时候，具体是哪个类加载器加载由 双亲委派模型 决定（不过，我们也能打破双亲委派模型）。

类加载器、双亲委派模型也是非常重要的知识点，这部分内容在类加载器详解（原文参考）这篇文章中有详细介绍到。阅读本篇文章的时候，大家知道有这么个东西就可以了。

每个非数组类或接口都由某个类加载器创建。数组类不是通过 ClassLoader 创建的，而是 JVM 在需要时自动创建；引用类型数组的定义类加载器与其组件类型的定义类加载器一致，基本类型数组的 getClassLoader() 则返回 null。

一个非数组类的加载阶段（获取类的二进制字节流的动作）可控性很强。通常可以继承 ClassLoader 并重写 findClass() 来控制字节流的获取方式，同时保留 loadClass() 实现的双亲委派流程；只有确实要改变委派规则时才需要重写 loadClass()。

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了。

验证

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段这一步在整个类加载过程中耗费的资源还是相对较多的，但很有必要，可以有效防止恶意代码的执行。任何时候，程序安全都是第一位。

HotSpot 曾提供 -Xverify:none 和 -noverify 来关闭大部分类验证，但这会削弱字节码安全检查，不应作为生产环境的通用优化手段。这两个选项已在 JDK 13 中被弃用，现代 JDK 还可能忽略或移除它们。

验证阶段主要由四个检验阶段组成：

文件格式验证（Class 文件格式检查）
元数据验证（字节码语义检查）
字节码验证（程序语义检查）
符号引用验证（类的正确性检查）

本站图解（非原图）

把正文四类检查按职责列出，属于教学归类，并非规范规定的四道独立流水线。

关注点	可核对的问题	官方章节
文件格式	二进制结构、版本与常量池项是否符合 Class 格式	JVMS §4.8
类型约束	例如是否非法继承 final 类	JVMS §5.4.1
字节码	操作数栈与指令要求的类型是否相容	JVMS §4.10
引用目标	目标字段或方法是否存在，是否允许访问	JVMS §5.4.3、§5.4.4

最后一行涉及解析和访问控制，不能理解为所有引用都必须在初始化前逐个解析。验证也不意味着程序不存在业务漏洞。

官方依据：Class 格式检查与验证、验证、解析、访问控制。

文件格式验证这一阶段是基于该类的二进制字节流进行的，主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个 Java 类型信息的要求。除了这一阶段之外，其余三个验证阶段都是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。

方法区属于是 JVM 运行时数据区域的一块逻辑区域，是各个线程共享的内存区域。当虚拟机要使用一个类时，它需要读取并解析 Class 文件获取相关信息，再将信息存入到方法区。方法区会存储已被虚拟机加载的 类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
关于方法区的详细介绍，推荐阅读 Java 内存区域详解这篇文章。

符号引用验证发生在类加载过程中的解析阶段，具体点说是 JVM 将符号引用转化为直接引用的时候（解析阶段会介绍符号引用和直接引用）。

符号引用验证的主要目的是确保解析阶段能正常执行，如果无法通过符号引用验证，JVM 会抛出异常，比如：

java.lang.IllegalAccessError：当类试图访问或修改它没有权限访问的字段，或调用它没有权限访问的方法时，抛出该异常。
java.lang.NoSuchFieldError：当类试图访问或修改一个指定的对象字段，而该对象不再包含该字段时，抛出该异常。
java.lang.NoSuchMethodError：当类试图访问一个指定的方法，而该方法不存在时，抛出该异常。
……

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，具体物理布局由虚拟机实现决定，不应把方法区、元空间和静态字段的存储位置直接等同。对于该阶段有以下几点需要注意：

这时候进行内存分配的仅包括类变量（Class Variables，即静态变量，被 static 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
从概念上讲，类变量所使用的内存都应当在 方法区 中进行分配。不过有一点需要注意的是：JDK 7 之前，HotSpot 使用永久代来实现方法区的时候，实现是完全符合这种逻辑概念的。而在 JDK 7 及之后，HotSpot 已经把原本放在永久代的字符串常量池、静态变量等移动到堆中，这个时候类变量则会随着 Class 对象一起存放在 Java 堆中。相关阅读：[《深入理解 Java 虚拟机（第 3 版）》勘误#75](https://github.com/fenixsoft/jvm_book/issues/75 “《深入理解Java虚拟机（第3版）》勘误#75”)
这里所设置的初始值通常是数据类型的默认零值（如 0、0L、null、false 等）。比如定义 public static int value=111，value 在准备阶段通常先得到 0，在初始化阶段才赋值为 111。字段带有 ConstantValue 属性时，按 JVMS 21 §4.7.2，其指定值在初始化过程中、调用 <clinit> 前赋入。public static final int value=111 是典型常量字段，但并非所有 static final 字段都有该属性。不要将 HotSpot 的内部提前赋值与规范阶段定义混同。

基本数据类型的零值：（图片来自《深入理解 Java 虚拟机》第 3 版 7.3.3）

本站图解（非原图）

默认初值对照表，依据规范重新整理，不复制书中配图。

类型	默认值
byte、short、int	`0`
long	`0L`
float	`0.0f`（正零）
double	`0.0d`（正零）
char	`'\u0000'`（空字符，不是字符 `'0'`）
boolean	`false`
引用类型（补充）	`null`

这些是字段及数组元素的默认值；局部变量不会自动获得可供读取的默认值。普通静态字段 static int value = 111; 在准备时为 0，初始化时执行赋值。

规范口径补充：正文已按规范修订；按 JVMS 21 §4.7.2，该属性指定值在类或接口初始化中、调用 <clinit> 前赋入。static final int N = 111; 是典型常量字段；static final Integer N = 111; 不等同于这样的编译期常量。默认值表本身不表示常量字段的全部初始化过程。

官方依据：JLS 21 §4.12.5、JVMS 21 §5.4.2、ConstantValue 属性。

解析

解析阶段是虚拟机从运行时常量池中的符号引用动态确定具体值的过程。 当前规范涉及类或接口、字段、方法、接口方法、方法类型、方法句柄、动态调用点以及动态常量等符号引用。

《深入理解 Java 虚拟机》7.3.4 节第三版对符号引用和直接引用的解释如下：

本站图解（非原图）

符号引用解析的文字例子。下列类名与描述符是本站自拟示例，不是原图内容或实际常量池转储。

表示层次	自拟示例或含义
方法符号引用	类 `demo/Service`，方法 `run`，描述符 `()V`（无参数、返回 void）
解析	依据类加载身份、方法查找与访问规则确定目标；不成功时可能产生链接错误
解析结果	JVM 可使用的目标表示；规范不要求统一为裸地址或固定方法表偏移
实际调用	对虚方法，仍须依据接收者的运行时类型选择方法；解析不等于提前确定所有实际调用实现

不能仅凭方法名 run 唯一定位方法，描述符和所属类型也参与标识。这里不推测原书截图中的文字或地址。

官方依据：JVMS 21 §4.3.3 方法描述符、§5.4.3.3 方法解析、§5.4.6 方法选择。

举个例子：程序调用方法时，虚拟机需要根据方法符号引用确定实际要调用的方法。HotSpot 等虚拟机可以使用方法表、入口地址或其他内部结构加速调用，但这些表示方式属于实现细节，并非《Java 虚拟机规范》统一规定的方法表偏移量。

综上，解析阶段是虚拟机根据运行时常量池中的符号引用确定类、字段、方法或动态调用点等具体目标的过程；直接引用的内部表示不一定是内存指针或固定偏移量。

初始化

初始化阶段会执行类或接口的初始化方法 <clinit>()（如果编译器生成了该方法），这是类加载过程的最后一步。

说明：编译器根据静态字段初始化表达式和静态初始化块生成 <clinit>()；如果没有需要执行的类初始化代码，Class 文件中可以不存在该方法。

JVM 会同步类或接口的初始化过程，确保同一时刻只有一个线程执行其初始化方法；这并不是说 <clinit>() 方法本身带有 Java 锁。其他线程可能在等待该类初始化完成时阻塞。

对于初始化阶段，规范列出的主要主动使用场景包括：

遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时：
- new: 创建一个类的实例对象。
- getstatic、putstatic: 读取或设置一个类型的静态字段（被 final 修饰、已在编译期把结果放入常量池的静态字段除外）。
- invokestatic: 调用类的静态方法。
使用 java.lang.reflect 包的方法对类进行反射调用时如 Class.forName("..."), newInstance() 等等。如果类没初始化，需要触发其初始化。
初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。
当虚拟机启动时，用户需要定义一个要执行的主类 (包含 main 方法的那个类)，虚拟机会先初始化这个类。
首次调用解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic 或 REF_newInvokeSpecial 的 MethodHandle 时，需要初始化声明该目标的类或接口。
「补充，来自issue745」 当一个接口中定义了 JDK8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

类卸载

卸载这部分内容来自 issue#662由 guang19 补充完善。

类卸载是 JVM 回收某个类或接口的方法区表示及其关联资源的过程。根据《Java 语言规范》，类或接口只有在其定义类加载器可被垃圾回收时才可能卸载；由启动类加载器定义的类或接口不能卸载。在常见的 HotSpot 应用中，这通常发生在可回收的自定义类加载器及其定义的类上。

在 HotSpot 中判断某个类是否可能卸载时，通常可以从下面三个条件理解：

该类的所有的实例对象都已被 GC，也就是说堆不存在该类的实例对象。
该类没有在其他任何地方被引用
该类的类加载器的实例已被 GC

满足这些条件只表示该类具备被卸载的条件，并不保证 JVM 会立即或一定卸载它。由启动类加载器创建的类不会被卸载；由自定义类加载器创建的类则可能被卸载。

通常，JDK 自带的启动类加载器、平台类加载器和应用类加载器会随 JVM 长期存活；自定义类加载器的实例则可以变为不可达，因此由它定义的类可能具备卸载条件。JDK 9 起，原来的扩展类加载器已由平台类加载器取代。

参考

《深入理解 Java 虚拟机》
《实战 Java 虚拟机》
Chapter 5. Loading, Linking, and Initializing - Java Virtual Machine Specification：https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4

本站勘误：规范阶段与实现细节

上述 ConstantValue 赋值阶段按 JVMS 21 §4.7.2修订；普通静态字段在准备阶段先取得默认值。原书与 HotSpot 内部步骤的归类不能代替规范定义。

本站补充：类加载阶段示意

以下简图由本站编写。依照 JVMS 21 第 5.4 节，初始化前需要完成验证和准备；解析可以提前进行，也可以在初始化之后按需继续。

继续对照本站收录的 Java 内存区域与类加载器版本差异。