从 1 开始学 JVM 系列
类加载器，对于很多人来说并不陌生。我自己第一次听到这个概念时觉得有点“高大上”，觉得只有深入 JDK 源码才会触碰到 ClassLoader，平时都是传闻中的东西。
今天，就让我们一起来探索一下这”传闻“中的类加载器，看看它是何方神圣。
在正式聊类加载器之前，我们先正本清源，看看类的生命周期是什么样的。
为了方便后续解读，下面我贴了一张图展示了类的生命周期的 7 个步骤。
对于前 5 步，简单来说就是加载、链接、初始化，这是一个类最关键的加载步骤。
对照着上图，我们逐一来解释一下。
所谓的加载，就是查找字节流，并根据字节流创建类的过程。
以盖房子为例，Jack 想要要盖个房子，按照流程他要先找个建筑师，跟他说想要设计一个房型，比如说“一房一厅两卫”。这里的房型就相当于类，而建筑师就相当于类加载器。
建筑界有许多的建筑师，他们等级分明，但都有着共同的祖师爷，叫「启动类加载器（boot class loader）」。由于启动类加载器是由 C++ 实现的，没有对应的 Java 对象，因此在 Java 中只能用 null 来指代。
// jdk中 BootstrapClass 是 native 实现
private native Class<?> findBootstrapClass(String name);
但是，祖师爷不喜欢像 Jack 这样的小角色来打扰他，所以谁也没有祖师爷的联系方式，也就相当于 null 指代。
除了启动类加载器之外，其他的类加载器都是 java.lang.ClassLoader 的子类，有对应的 Java 对象。这些类加载器需要先由另一个类加载器，比如说启动类加载器，加载至 Java 虚拟机中，方能执行类加载。
建筑师界有个潜规则：接到单子后自己不能着手干，得先给师傅过过目。师傅不接手的情况下，才能自己来。即等级高的师傅有优先选择权。
在 Java 虚拟机中，这个潜规则就是「双亲委派模型」。每当一个类加载器接收到加载请求时，它会先将请求转发给父类加载器。在父类加载器没有找到请求的类时，这个类加载器才会尝试去加载。
| 加载器类型(Java 9 之前) | 作用 | 加载路径 |
|---|---|---|
| 启动类加载器 | 负责加载最为基础、最为重要的类 | 比如存放在 JRE 的 lib 目录下 jar 包中的类（以及由虚拟机参数 -Xbootclasspath 指定的类） |
| 扩展类加载器 （extension class loader） | 父类加载器是启动类加载器。它负责加载相对次要、但又通用的类 | 比如存放在 JRE 的 lib/ext 目录下 jar 包中的类（以及由系统变量 java.ext.dirs 指定的类） |
| 应用类加载器 （application class loader） | 父类加载器则是扩展类加载器。它负责加载应用程序路径下的类。 默认情况下，应用程序中包含的类便是由应用类加载器加载的 | 这里的应用程序路径，便是指虚拟机参数 -cp/-classpath、系统变量 java.class.path 或环境变量 CLASSPATH 所指定的路径。 |
Java 9 引入了模块系统，并且略微更改了上述的类加载器。扩展类加载器被改名为「平台类加载器（platform class loader）」。Java SE 中除了少数几个关键模块，比如说 java.base 是由启动类加载器加载之外，其他的模块均由平台类加载器所加载。
除了由 Java 核心类库提供的类加载器外，我们还可以加入「自定义类加载器」，实现特殊的加载方式。
举个例子，我们可以对 class 文件进行加密，加载时再利用自定义类加载器对其解密。
除了加载功能之外，类加载器还提供了「命名空间」的作用。
打个比方，假设建筑界不讲版权，如果某个人剽窃了另一个建筑师的设计作品，只要你标上自己的名字，这两个房型就是不同的。
在 Java 虚拟机中，类的唯一性是由类加载器实例以及类的全名一同确定的。即便是同一串字节流，经由不同的类加载器加载，也会得到两个不同的类。
在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。
链接，是指将创建好的类合并至 Java 虚拟机中，使之能够执行的过程。它可分为验证、准备以及解析三个阶段。
这就好比 Jack 需要将设计好的房型提交给市政部门审核。只有当审核通过，才能继续下面的建造工作。
通常而言，Java 编译器生成的类文件必然满足 Java 虚拟机的约束条件。
2.「准备」阶段的目的，则是为被加载类的静态字段分配内存。Java 代码中对静态字段的具体初始化，则会在稍后的初始化阶段中进行。
过了这个阶段，算是盖好了毛坯房。虽然结构已经完整，但没有装修之前不能住人。
除了分配内存外，部分 Java 虚拟机会在此阶段构造其他跟类层次相关的数据结构，比如说用来实现虚方法的动态绑定的方法表。
在 class 文件被加载至 Java 虚拟机之前，这个类无法知道其他类及其方法、字段所对应的具体地址，甚至不知道自己方法、字段的地址。因此，每当需要引用这些成员时，Java 编译器会生成一个「符号引用」。在运行阶段，这个符号引用一般都能够无歧义地定位到具体目标上。
举个例子，对于一个方法调用，编译器会生成一个包含目标方法所在类的名字、目标方法的名字、接收参数类型以及返回值类型的符号引用，来指代所要调用的方法。（即方法签名）
3.「解析」阶段的目的，正是将这些符号引用解析成为实际引用。
如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的链接以及初始化。）
符号引用就好比“Jack 的房子”这种说法，不管它存在不存在，我们可以用这种说法指代 Jack 的房子。
实际引用则好比实际的通讯地址，如果我们想要与 Jack 通信，则需要启动盖房子的过程。
Java 虚拟机规范并没有要求在链接过程中完成解析。它仅规定了：如果某些字节码使用了符号引用，那么在执行这些字节码之前，需要完成对这些符号引用的解析。
Java 中如果要初始化一个静态字段，我们可以在声明时直接赋值，也可以在静态代码块中对其赋值。
类加载的最后一步是初始化，便是为标记为常量值的字段赋值和执行 < clinit > 方法的过程。Java 虚拟机会通过加锁来确保类的 < clinit > 方法仅被执行一次。
只有当初始化完成之后，类才正式成为可执行的状态。
在盖房子的例子中，相当于房子装修好了，Jack 可以真正拎包入住了。
JVM 规范枚举了下述多种触发情况：
当虚拟机启动时，初始化用户指定的主类，就是启动执行的 main 方法所在的类；
当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类；
当遇到调用静态方法的指令时，初始化该静态方法所在的类；
当遇到访问静态字段的指令时，初始化该静态字段所在的类；
子类的初始化会触发父类的初始化；
如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，会触发该接口的初始化；
和继承类似(5、6 条都是面向对象)
使用反射 API 对某个类进行反射调用时，初始化这个类；
当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。
和反射类似(7、8 条都是反射相关)
// 单例延迟初始化例子
public class Singleton {
private Singleton() {}
private static class LazyHolder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}
只有当调用 Singleton.getInstance 时，程序才会访问 LazyHolder.INSTANCE，才会触发对 LazyHolder 的初始化（对应第 4 种情况），继而新建一个 Singleton 的实例。
由于类的初始化线程安全，并且仅被执行一次，因此程序可以确保多线程环境下有且仅有一个 Singleton 实例。
通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
定义对象数组，不会触发该类的初始化。
直到 new 才触发
常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
常量不是变量
通过类名获取 Class 对象，不会触发类的初始化，Hello.class 不会让 Hello 类初始化。
通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。Class.forName (“jvm.Hello”)默认会加载 Hello 类。
通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作(加载了，但不初始化)。
为了方便查看，我画了一张流程图演示上面的步骤。
如果你觉得有用，欢迎关注 「小尹探世界」 微信公众号，希望我们一起打造一个有知识、有温度、有趣点、有价值的频道，探索技术之外的广袤世界。
原文：https://www.cnblogs.com/alan-yin/p/15302644.html