从 1 开始学 JVM 系列 | JVM 类加载器(一)

类加载器，对于很多人来说并不陌生。我自己第一次听到这个概念时觉得有点“高大上”，觉得只有深入 JDK 源码才会触碰到 ClassLoader，平时都是传闻中的东西。

今天，就让我们一起来探索一下这”传闻“中的类加载器，看看它是何方神圣。

类生命周期

在正式聊类加载器之前，我们先正本清源，看看类的生命周期是什么样的。

为了方便后续解读，下面我贴了一张图展示了类的生命周期的 7 个步骤。

对照着上图，我们逐一来解释一下。

1. 加载(Loading)：找 Class 文件
2. 验证(Verification)：验证格式、依赖
3. 准备(Preparation)：静态字段、方法表
4. 解析(Resolution)：符号解析为引用
5. 初始化(Initialization)：构造器、静态变量赋值、静态代码块
6. 使用(Using)
7. 卸载(Unloading)

1.加载

所谓的加载，就是查找字节流，并根据字节流创建类的过程。

• 对于数组类，它没有对应的字节流，是由 Java 虚拟机直接生成的。
• 对于其他的类，Java 虚拟机需要借助类加载器来完成查找字节流的过程。

启动类加载器

建筑界有许多的建筑师，他们等级分明，但都有着共同的祖师爷，叫「启动类加载器（boot class loader）」。由于启动类加载器是由 C++ 实现的，没有对应的 Java 对象，因此在 Java 中只能用 null 来指代。

// jdk中 BootstrapClass 是 native 实现
private native Class<?> findBootstrapClass(String name);

除了启动类加载器之外，其他的类加载器都是 java.lang.ClassLoader 的子类，有对应的 Java 对象。这些类加载器需要先由另一个类加载器，比如说启动类加载器，加载至 Java 虚拟机中，方能执行类加载。

双亲委派模型

在 Java 虚拟机中，这个潜规则就是「双亲委派模型」。每当一个类加载器接收到加载请求时，它会先将请求转发给父类加载器。在父类加载器没有找到请求的类时，这个类加载器才会尝试去加载。

加载器类型

Java 9 引入了模块系统，并且略微更改了上述的类加载器。扩展类加载器被改名为「平台类加载器（platform class loader）」。Java SE 中除了少数几个关键模块，比如说 java.base 是由启动类加载器加载之外，其他的模块均由平台类加载器所加载。

除了由 Java 核心类库提供的类加载器外，我们还可以加入「自定义类加载器」，实现特殊的加载方式。

类加载器的命名空间

除了加载功能之外，类加载器还提供了「命名空间」的作用。

在 Java 虚拟机中，类的唯一性是由类加载器实例以及类的全名一同确定的。即便是同一串字节流，经由不同的类加载器加载，也会得到两个不同的类。

2.链接

链接，是指将创建好的类合并至 Java 虚拟机中，使之能够执行的过程。它可分为验证、准备以及解析三个阶段。

• 1. 「验证」阶段的目的，在于确保被加载类能够满足 Java 虚拟机的约束条件。

• 2.「准备」阶段的目的，则是为被加载类的静态字段分配内存。Java 代码中对静态字段的具体初始化，则会在稍后的初始化阶段中进行。

  除了分配内存外，部分 Java 虚拟机会在此阶段构造其他跟类层次相关的数据结构，比如说用来实现虚方法的动态绑定的方法表。

  在 class 文件被加载至 Java 虚拟机之前，这个类无法知道其他类及其方法、字段所对应的具体地址，甚至不知道自己方法、字段的地址。因此，每当需要引用这些成员时，Java 编译器会生成一个「符号引用」。在运行阶段，这个符号引用一般都能够无歧义地定位到具体目标上。

• 3.「解析」阶段的目的，正是将这些符号引用解析成为实际引用。

  如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的链接以及初始化。）

  Java 虚拟机规范并没有要求在链接过程中完成解析。它仅规定了：如果某些字节码使用了符号引用，那么在执行这些字节码之前，需要完成对这些符号引用的解析。

3.初始化

静态字段的赋值

Java 中如果要初始化一个静态字段，我们可以在声明时直接赋值，也可以在静态代码块中对其赋值。

• 如果直接赋值的静态字段被 final 所修饰，并且它的类型是基本类型或字符串时，那么该字段便会被 Java 编译器标记成「常量值（ConstantValue）」，其初始化直接由 Java 虚拟机完成。
• 除此之外的直接赋值操作，以及所有静态代码块中的代码，则会被 Java 编译器置于同一方法中，并把它命名为 < clinit >。

初始化

类加载的最后一步是初始化，便是为标记为常量值的字段赋值和执行 < clinit > 方法的过程。Java 虚拟机会通过加锁来确保类的 < clinit > 方法仅被执行一次。

只有当初始化完成之后，类才正式成为可执行的状态。

那么，类的初始化何时会被触发呢？

JVM 规范枚举了下述多种触发情况：

1. 当虚拟机启动时，初始化用户指定的主类，就是启动执行的 main 方法所在的类；

2. 当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类；

3. 当遇到调用静态方法的指令时，初始化该静态方法所在的类；

4. 当遇到访问静态字段的指令时，初始化该静态字段所在的类；

5. 子类的初始化会触发父类的初始化；

6. 如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，会触发该接口的初始化；

7. 使用反射 API 对某个类进行反射调用时，初始化这个类；

8. 当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。

// 单例延迟初始化例子
public class Singleton {
  private Singleton() {}
  private static class LazyHolder {
    static final Singleton INSTANCE = new Singleton();
  }
  public static Singleton getInstance() {
    return LazyHolder.INSTANCE;
  }
}

由于类的初始化线程安全，并且仅被执行一次，因此程序可以确保多线程环境下有且仅有一个 Singleton 实例。

那么，什么时候不会初始化，但可能会加载？

1. 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。

2. 定义对象数组，不会触发该类的初始化。

3. 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。

4. 通过类名获取 Class 对象，不会触发类的初始化，Hello.class 不会让 Hello 类初始化。

5. 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。Class.forName (“jvm.Hello”)默认会加载 Hello 类。

6. 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作(加载了，但不初始化)。

流程概览

为了方便查看，我画了一张流程图演示上面的步骤。

END