JVM详解：类的加载过程

JVM中类的加载主要分为三个部分，分别为加载（loading），链接（linking），初始化（initing）。其中加载负责的主要是讲类文件加载到内存中变为类对象，不过此时只有基本结构，没有实际数据。链接阶段还会被细分为验证，准备和解析，其中验证时对字节码文件进行格式校验（实际上所有阶段在执行前都会对自己需要的数据进行校验），准备阶段则是对静态属性进行默认赋值以及类型校验，而解析阶段则是这个环节最重要的，主要是将加载阶段没有加载的结构进行加载，这就相当于加载阶段是加载了一个和简单的骨架，而链接阶段则是将剩余的骨架补齐。最终的初始化阶段则是最终的赋值，为这具骨头附加血肉，这三个阶段的具体实现如下：

1. 加载（loading）

JVM通过加载java服务的启动类来开启运行java服务，任何非启动类的加载都是由另一个类的的的调用，触发加载的。一个类调用另一个类的逻辑在编译后的字节码文件中的体现是符号引用，当需要使用那个类时，才会通过符号引用，将其加载进内存中的。不过此时内存中保存的对象信息，包括方法属性常量等等，都只是符号引用，并不是真实引用。

那么什么是符号引用呢？具体我也不清楚，但可以知道的是，在没加载类或方法之前，其是保存在字节码文件中，而符号引用其中保存了可以找到目标类或方法的字节码文件的信息（不仅仅是这个作用，符号饮用记录了很多类或方法等，其表示的东西的信息）。

1.1 加载前的检查

JVM的类加载前需要进行大量的检查，大致包括如下内容：

判断是否已经加载过这类了，如果出现类名相同，内容不同的情况，直接报错LinkageError。
检查类文件格式是否正确，可能会抛出ClassFormatError（文件格式不正确）和ClassFormatError（版本不对）的错误。
检查找到的类文件和符号饮用的描述是否一致，如果不是目标类，则报错NoClassDefFoundError。
加载其父类的符号引用，如果父类是接口（IncompatibleClassChangeError）或自身（ClassCircularityError），则会报错。

一旦检查通过，就会将当前类记录在其对应的类加载器中，表示类已经加载过了。

类加载器：见名知意，就是讲类加载进内存的东西，不过随着类的分布位置不同，也需要不同的类加载器，JVM内置了三种类加载器，其中包括：

引导类加载器（Bootstrap ClassLoader）：这是 JVM 中最底层的类加载器，负责加载 Java 核心库（如 java.lang.*、java.util.* 等），这些类位于 JDK 中的 jre/lib/rt.jar 或类似的系统路径下。它由 JVM 提供并且是不可见的，无法直接实例化。
扩展类加载器（Extension ClassLoader）：负责加载 JDK 扩展库（即 jre/lib/ext 目录下的类，或者 java.ext.dirs 配置的路径下的类）。它也是由 JVM 提供的，但与引导类加载器不同，它加载的是 Java 扩展库。
应用类加载器（Application ClassLoader）：负责加载用户应用程序的类路径（classpath）中的类，通常就是你在命令行中通过 java -cp 或 java -classpath 指定的类路径。这是最常用的类加载器，用于加载 Java 程序中定义的类。

但是创建这三个类加载器的目的是什么呢？为什么不直接把类放在一起加载呢？

首先这一定和性能无关，因为我与其使用三种加载器，不如将一种加载器复制三份。那么作用就一定是功能性的了，大概率是为了解藕不同功能的类，防止在一起互相影响，引发不可预料的事件。

除了JVM内置的加载器外，JVM还允许开发者自定义加载器，这样就可以让开发者自己处理一些刁钻的类的位置，比如在另一个服务器，或数据库中的类等等。

1.2 类的加载过程

JVM类的加载过程，大概可以将类分为两种，一种是数组类，一种是实例类（也就是非数组类）。

实例类

加载实例类时，JVM会检查类是否加载过，如果加载过，则认为其已经在内存中，跳过加载过程，如果不在，则将符号引用交给类加载器，让其寻找并加载对应的类。

当类加载或解析失败时，类加载器会抛出LinkageError或其子类的实例，当第一次加载，没有找到类的字节码文件时，则会跑出LinkageError的子类ClassNotFoundException的实例。

同样的NoClassDefFoundError也是LinkageError的子类实例，不同的是其通常是类在某个时刻加载过，但后续没有找到。JVM规定两次查找相同的类必须返回同一类对象，所以也可以说NoClassDefFoundError是在JVM的堆中没有找到类对象，而ClassNotFoundException是在磁盘中没有找到类的字节码文件。

数组类

而对于数组类，其没有二进制表示，是由JVM拿到相应参数来创建的。JVM会优先检查数组类内部元素是否为引用类型，如果是，其类是否在之前加载过，如果没有则会先加载器内部元素的类（如果元素的类还包含其他的类，则递归这一过程）。最终在由JVM创建数组类。如果不是，该数组类会被标记为引到类加载器加载的类（防止下一次重复检查，直接加载即可）。

1.3 类的加载约束

假设两个类加载器，加载了两个同名内容却不同的类，由于JVM规定一个类只允许加载一次，当一个类加载完成后，另一个加载时会被当成已经加载过了，那么在使用这类时，就会出现类的实际行为与预期不一致的问题。

为了防止这种情况的发生，JVM采用了一种名为类加载约束的方式。JVM要求加载类之前，如果发现了同名的类，必须保证其符号引用中记录的类格式一样（符号饮用的另一个作用，在编译期间生成的符号饮用会记录类的格式）。如果不同，则会返回LinkageError的错误。

实际上述情况还有另一种说明，就是根本不会发生类加载前的格式检查，而是同名类会直接拒绝加载，使用内存中的，如果与预期的类不一致，则会直接抛出LinkageError的错误，具体实现会在不同版本的JVM中有所差异，不过归根到底都是遇到同类名不同内容时，会返回错误。

那么如果真的出现了同名的类，哪个类会被加载进内存呢？这就和类加载器的执行顺序有关了，jvm的类加载器按照向上检查，向下加载的顺序来决定有哪个类加载器来加载这个类，这是什么意思呢？

类加载器之间也是有继承关系的（这个在java代码中可见），其中引导类加载器（Bootstrap ClassLoader）为所有类加载器的顶级父类，其子类为扩展类加载器（Extension ClassLoader），然后是应用类加载器（Application ClassLoader），自定义加载器为应用类加载器的子类。向上检查则是从自定义加载器开始检查，是否加载过这个类，如果加载过则无需重复加载。这一过程是从自定义加载器开始，逐渐顺着继承链向上检查。当检查到**引导类加载器（Bootstrap ClassLoader）时则证明没有加载过这个类，再从引导类加载器（Bootstrap ClassLoader）**开始判断是否有记载这个类的能力，如果有，则进行加载，如果没有则判断其子类，以此类推。大概过程如下图
在这里插入图片描述

当所有的类加载器都不能加载这个类时，由于类加载器的区别时根本加载类文件所处位置位置不同，所以没有类加载器能够加载这个类实际上就是没有在对应位置找到对应类文件，所以会返回ClassNotFoundException报错。

2. 连接（linking）

连接分为三个阶段，分别是验证，准备，以及解析

2.1 验证

在验证阶段，JVM会对文件再次进行检查，检查二进制文件（字节码文件）是否符合预期，如果不符合则会抛出异常LinkageError或其子类。

2.2 准备

在准备阶段，JVM会对加载类中的静态字段，并赋予其默认值（不是实际的值，实际的值会在解析阶段使其赋值）。并且还会对其实现或重写的接口或父类方法之前的类型进行对比检查（这会导致接口和父类的提前加载）。

2.3 解析

在类的加载阶段（loading），大量类的父类、字段、方法、接口等被作为符号引用，存在常量池中。而在linking的解析阶段，这些符号引用将被转换为真实引用，并将方法和属性加载到方法区中。但是对于反射和动态方法，这些无法在编译及加载期间确定其具体值的，必须在实际执行时，才能够进行符号引用到实际引用的变换操作。

JVM在解析阶段对方法和字段进行解析时，如果当前类寻找不到，则会在当前类的继承链或实现接口进行查找。如果还是没有找到，则会抛出错误。

在当前被加载的类中，未被使用的方法里保存的类，会被作为符号引用存在常量池中，不会被解析为实际引用，。不过正在加载类的整个继承链和接口，都会从子类的linking阶段的准备阶段开始初始化，并且需要在子类初始化完成之前初始化完成。父类和接口虽然需要提前被初始化完成，不过这也并不代表优先于子类初始化，而是会卡在连接阶段，只有在子类初始化时，父类和接口等才会被递归初始化，这些后面初始化阶段会说。