类加载系统加载类时分为三个步骤，加载、链接、初始化，下面展开介绍。
类加载子系统结构图：
1 类加载器
JVM 使用类加载器加载 class 文件，类加载器可分为引导类加载器 和自定义类加载器两种。
引导类加载器（Bootstrap ClassLoader），有时也被称作启动类加载器或者零类加载器（Null ClassLoader），是 Java 虚拟机中最基础的类加载器之一。它的主要职责是加载 Java 核心类库。
自定义类加载器需要继承自 ClassLoader 类 ，JDK 默认提供了一些。比较重要的有两个，拓展类加载器（ExtClassLoader） 和应用类加载器（AppClassLoader） 。
下面展开说说这三个加载器的作用、区别以及联系。先看一张图：
1.1 引导类加载器（BootStrapClassLoader）
特点：
- 内部实现：引导类加载器并不是通过 Java 代码实现的，而是用 C++ 或者其他本地语言编写的，并且是 JVM 的一部分。
- 加载路径 ：引导类加载器通常从
$JAVA_HOME/jre/lib/或类似的位置加载 Java 核心类。 - 无父类加载器：引导类加载器没有显式的父类加载器，这是因为它的设计目的是为了加载 Java 最基础的类库，而这些类库是任何其他类加载器工作的前提。因此，它不需要依赖于任何其他类加载器。
- 不可见性：引导类加载器并不是对所有 Java 应用程序都可见的，因为它是 JVM 的一部分，而不是标准的 Java 类加载器层次结构的一部分。
- 优先级：引导类加载器通常是整个类加载过程的第一步，当 Java 应用程序启动时，它会首先加载必要的核心类库，然后才允许后续的类加载器（如扩展类加载器和应用类加载器）开始工作。
1.2 拓展类加载器（ExtClassLoader）
特点：
- 内部实现 ：
ExtClassLoader是在sun.misc.Launcher类里的静态内部类，继承自ClassLoader类，重写loadClass()方法。 - 加载路径 ：
ExtClassLoader主要负责加载位于$JAVA_HOME/jre/lib/ext目录下的扩展类库。 - 委托模型 ：
ExtClassLoader遵循 Java 类加载器的委托模型。当它收到一个类加载请求时，它首先会尝试使用其父类加载器（即 Bootstrap ClassLoader）来加载这个类。如果父类加载器无法加载，则ExtClassLoader会尝试自己加载。 - 优先级 ：
ExtClassLoader位于BootstrapClassLoader之后，但在AppClassLoader之前。这意味着它继承了Bootstrap ClassLoader的特性，并且它加载的类对Application ClassLoader可见。
1.3 应用类加载器（AppClassLoader）
特点：
- 内部实现 ：
AppClassLoader也是在sun.misc.Launcher类里的静态内部类，继承自ClassLoader类，重写loadClass()方法。 - 加载路径 ：
AppClassLoader主要负责的目录是当前应用程序的classpath所指定的路径，也就是说我们自己写的类默认都是通过AppClassLoader加载的。我们在IDEA里运行代码时，仔细观察控制台可以发现第一行通过-classpath指定了当前应用程序的class文件的目录 - 委托模型 ：
AppClassLoader遵循 Java 类加载器的委托模型。当它收到一个类加载请求时，它首先会尝试使用其父类加载器ExtClassLoader来加载这个类。如果父类加载器无法加载，则AppClassLoader会尝试自己加载。 - 优先级 ：
AppClassLoader位于ExtClassLoader之后。
除了这些特点外，AppClassLoader还有一些别的用途：
- 加载第三方 Jar 包：当应用程序依赖于第三方库时，这些库通常会被打包成 JAR 包，并放置在类路径中。AppClassLoader 会加载这些 JAR 包中的类。
- 动态加载类：在一些需要动态加载类的场景中，如 Spring Boot 应用程序，AppClassLoader 可以用于动态加载和卸载类。
1.4 双亲委派
原因一：前面我们介绍了引导类加载器、拓展类加载器、应用类加载器分别负责不同的路径下的class文件，但是并不是完全不相交的，比如-classpath除了指定当前应用程序的class文件目录外，也会指定$JAVA_HOME/jre/lib/目录下的某些 jar 包，所以要避免重复加载某些类。
原因二：如果我们的程序被黑客攻击了，比如黑客自己创建了一个java.lang的包，里面创建了一个名为String的类，把这个包和类植入我们正在运行的项目里，如果他的这个类被加载了，那我们项目里的String就会被篡改。
为了避免以上两种原因，我们要保证类只加载一次，并且保证越靠近 JVM 的类加载器优先级越高。这就是双亲委派干的事情！！！
原理：
引导类加载器、拓展类加载器、应用类加载器这三者之前有个关系，但又不是父子类关系，而是应用类加载器有个parent属性是拓展类加载器的对象。拓展类加载器的parent为空，所以会调用引导类加载器。我们观察ClassLoader的loaderClass()方法可以得出类的加载过程：
简单来说就是，
通过AppClassLoader加载class时会先用ExtClassLoader去加载这个类；
通过ExtClassLoader加载class时会先用BootStrapClassLoader去加载这个类；
好处：
- 避免类被重复加载。
- 防止JVM核心类被篡改。
2 链接
class 加载完后会进行链接，分为三步：验证、准备、解析。
2.1 验证
第一步是验证 class 文件是否正确，比如验证格式。
2.2 准备
对 static 修饰的属性赋予一个默认值，但这一步不会赋初始值。
举个例子，class 里定义了一个static int a = 1，准备阶段会把 a 赋值为 0，在初始化阶段 a 才会 = 1。
2.3 解析
将符号引用解析为直接引用。什么意思呢？
首先我们需要知道类被加载后是放到方法区的，每个类都是一个 Klass 对象（也可称为 Klass 结构）。
一般情况下我们都会在一个A类里使用到别的B类，使用方式是B类的全限定名，就只是一个字符串。但是JVM 实际在执行的时候需要从方法区中找到B类的 Klass 对象，解析的作用就是把这个名称字符串替换为实际的 Klass 对象内存地址。"符号引用"就是名称字符串、"直接引用"就是 Klass 对象内存地址。
3 初始化
初始化是类加载子系统的最后一个阶段，也是最为关键的阶段之一。下面详细介绍初始化阶段的内容及其重要性。
3.1 定义
初始化阶段是类加载过程中的最后一个阶段，它负责执行类构造器 <clinit> 方法，并初始化类的静态变量。
3.2 主要任务
初始化阶段的主要任务包括：
- 执行类构造器
<clinit>方法 ：<clinit>方法是一个特殊的静态构造器，它负责对类进行初始化。每个类都有一个<clinit>方法，该方法在类第一次被初始化时由 JVM 自动生成并执行。 - 初始化类变量 ：类中的静态变量（即类变量）在
<clinit>方法中被赋值。
3.3 <clinit> 方法的特点
- 静态块 ：在类定义中，静态代码块会被编译器转化为
<clinit>方法中的语句。 - 顺序执行：如果一个类有多个静态代码块，它们将按照在源代码中出现的顺序依次执行。
- 线程安全 ：
<clinit>方法是线程安全的，这意味着即使有多个线程同时初始化同一个类，也不会发生冲突。
3.4 示例代码
下面是一个简单的示例，展示类的初始化过程：
java
public class InitializationExample {
static {
System.out.println("执行静态初始化块。");
}
static int staticVar = initializeStaticVar();
private static int initializeStaticVar() {
System.out.println("初始化静态变量。");
return 10;
}
public static void main(String[] args) {
System.out.println("静态变量初始化为: " + staticVar);
}
}输出如下：
java
执行静态初始化块。
初始化静态变量。
静态变量初始化为: 103.5 初始化时机
类的初始化通常在以下几种情况下触发：
- 首次创建类的实例：当第一次创建类的实例时，JVM 会初始化该类。
- 调用类的静态方法：当第一次调用类的静态方法时，JVM 会初始化该类。
- 引用类的静态字段：当第一次引用类的静态字段时，JVM 会初始化该类。
- 反射性引用 ：当通过
java.lang.Class或java.lang.reflect包中的方法来引用类时，如果这些方法会导致类的初始化，那么 JVM 会初始化该类。 - 初始化子类时：当初始化一个类的子类时，如果父类还没有被初始化，那么 JVM 会首先初始化父类。
3.6 初始化顺序
类的初始化顺序遵循一定的规则：
- 如果类 A 引用了类 B 的静态字段或调用了类 B 的静态方法，那么类 B 必须先于类 A 被初始化。
- 如果类 A 继承自类 B，那么类 B 必须先于类 A 被初始化。