类加载过程

类的生命周期

类的完整生命周期大致如下

类的加载

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个
java.lang.Class 对象，用来封装类在方法区内的数据结构。

加载.class文件方式

• 从本地系统中直接加载
• 网络下载.class文件
• zip，jar包等加载.class
• 专有数据库中提取.class
• Java源文件动态编译为.class

如何加载

类加载时 JVM 主要做了 3 件事：

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

一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

验证

验证是连接的第一步，目的是确保class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

验证阶段有 4 个要做的：

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object 之外。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正确执行。

验证阶段很重要，但不是必须的，若引用的类结果反复验证，可以通过-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

1. 这时候进行内存分配的仅包括类变量（即静态变量，被 static 关键字修饰的变量，只与类相关，因此被称为类变量），而不包括实例变量。实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
2. 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。若是加了final，如public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。

假如定义一个类变量：public static int value = 114514 ,变量value在准备阶段后初始值则为0，不是114514；因为这时候尚未开始执行任何Java方法，只有在程序编译后，初始化阶段赋值动作才会执行。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符 7 类符号引用进行。

符号引用就是一组符号来描述目标，可以是任何字面量。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

初始化

为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。这是类加载最后一步，真正执行类中定义的 Java 程序代码。

JVM初始化步骤：

1. 假如这个类还没有被加载和连接，则程序先加载并连接该类
2. 假如该类的直接父类还没有被初始化，则先初始化其直接父类
3. 假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下几种：

1. 创建类的实例，也就是new的方式

2. 当 JVM 执行 new 指令时会初始化类。即当程序创建一个类的实例对象。

3. 当 JVM 执行 getstatic 指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)。

4. 当 JVM 执行 putstatic 指令时会初始化类。即程序给类的静态变量赋值。

5. 当 JVM 执行 invokestatic 指令时会初始化类。即程序调用类的静态方法。

6. 对类进行反射调用，如 Class.forname("...") 等等。

7. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。

8. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 main 方法的那个类)，虚拟机会先初始化这个类。

9. 轻量级的反射调用机制, MethodHandle 和 VarHandle

卸载

卸载类即该类的 Class 对象被 GC。

卸载类需要满足 3 个要求:

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

所以，在 JVM 生命周期内，由 JVM 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。

类加载器

JVM 中内置了三个类加载器

1. BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类。
2. ExtensionClassLoader(扩展类加载器) ：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。
3. AppClassLoader(应用程序类加载器) ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

双亲委派模型

每一个类都有一个对应它的类加载，系统中的 ClassLoader 在协同工作的时候会默认使用 双亲委派模型 。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。

通俗来说，就是先判断类是否被加载过，已被加载的类会直接返回；若没有，则把请求委派给父类加载器，层层往上，直到顶层启动器 BootstrapClassLoader 。

好处

双亲委派模型保证了 Java 程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类），也保证了 Java 的核心 API 不被篡改。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的Object类。