JVM系列(二) -类的加载过程介绍

一、背景介绍

我们知道 Java 是先通过编译器将.java类文件转成.class字节码文件，然后再通过虚拟机将.class字节码文件加载到内存中来实现应用程序的运行。

那么虚拟机是什么时候加载class文件？如何加载class文件？class文件进入到虚拟机后发生了哪些变化？

今天我们就一起来了解一下，虚拟机是如何加载类文件的。

二、类加载的时机

经常有面试官问，“类什么时候加载”和“类什么时候初始化”，从内容上来说，似乎都在问同一个问题：class文件是什么时候被虚拟机加载到内存中，并进入可以使用的状态？

从虚拟机角度来说，加载和初始化是类的加载过程中的两个阶段。

对于“什么时候加载”，Java 虚拟机规范中并没有约束，每个虚拟机实例都可以按自身需要来自由实现。但基本上都遵循类在进行初始化之前，需要先进行加载class文件。

对于“什么时候初始化”，Java 虚拟机规范有明确的规定，当符合以下条件时（包括但不限），并且虚拟机在内存中没有找到对应的类信息，必须对类进行“初始化”操作：

使用new实例化对象时，读取或者设置一个类的静态字段或方法时
反射调用时，例如Class.forName("com.xxx.Test")
初始化一个类的子类，会首先初始化子类的父类
Java 虚拟机启动时标明的启动类，比如main方法所在的类
JDK8 之后，接口中存在default方法，这个接口的实现类初始化时，接口会在它之前进行初始化

类在初始化开始之前，需要先经历加载、验证、准备、解析这四个阶段的操作。

下面我们一起来看看类的加载过程。

三、类的加载过程

当一个类需要被加载到虚拟机中执行时，虚拟机会通过类加载器，将其.class文件中的字节码信息在内存中转化成一个具体的java.lang.Class对象，以便被调用执行。

类从被加载到虚拟机内存中开始，到卸载出内存，整个生命周期包括七个阶段：加载、验证、准备、解析、初始化、使用和卸载，可以用如下图来简要概括。

其中类加载的过程，可以用三个步骤（五个阶段）来简要描述：加载 -> 连接（验证、准备、解析）-> 初始化。（验证、准备、解析这3个阶段统称为连接）

其次加载、验证、准备和初始化这四个阶段发生的顺序是确定的，必须按照这种顺序按部就班的开始，而解析阶段则不一定。在某些情况下解析阶段可以在初始化阶段之后开始，这是为了支持 Java 语言的运行时绑定，也称为动态绑定或晚期绑定。

同时，这五个阶段并不是严格意义上的按顺序完成，在类加载的过程中，这些阶段会互相混合，可能有些阶段完成了，有些阶段没有完成，会交叉运行，最终完成类的加载和初始化。

接下来依此分解一下加载、验证、准备、解析、初始化这五个步骤，这五个步骤组成了一个完整的类加载过程。使用没什么好说的，卸载通常属于 GC 的工作，当一个类没有被任何地方引用并且类加载器已被 GC 回收，GC 会将当前类进行卸载，在后续的文章我们会介绍 GC 的工作机制。

3.1、加载

加载是类加载的过程的第一个阶段，这个阶段的主要工作是查找并加载类的二进制数据，在虚拟机中，类的加载有两种触发方式：

预先加载：指的是虚拟机启动时加载，例如JAVA_HOME/lib/下的rt.jar下的.class文件，这个jar包里面包含了程序运行时常用的文件内容，例如java.lang.*、java.util.*、java.io.*等等，因此会随着虚拟机启动时一起加载到内存中。要证明这一点很简单，自己可以写一个空的main函数，设置虚拟机参数为-XX:+TraceClassLoading，运行程序就可以获取类加载的全部信息
运行时加载：虚拟机在用到一个.class文件的时候，会先去内存中查看一下这个.class文件有没有被加载，如果没有，就会按照类的全限定名来加载这个类；如果有，就不会加载。

无论是哪种触发方式，虚拟机在加载.class文件时，都会做以下三件事情：

1.通过类的全限定名定位.class文件，并获取其二进制字节流
2.将类信息、静态变量、字节码、常量这些.class文件中的内容放入运行时数据区的方法区中
3.在内存中生成一个代表这个.class文件的java.lang.Class对象，作为方法区这个类的各种数据的访问入口，一般这个java.lang.Class对象会存在 Java 堆中

虚拟机规范对这三点的要求并不具体，因此具体虚拟机实现的灵活度都很大。比如第一条，没有指明二进制字节流要从哪里来，单单就这一条，就能变出许多花样来，比如下面几种加载方式：

从 zip、jar、ear、war 等归档文件中加载.class文件
通过网络下载并加载.class文件，典型应用就是 Applet
将Java源文件动态编译为.class文件，典型应用就是动态代理技术
从数据库中提取.class文件并进行加载

总的来说，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）对于开发者来说是可控性最强的一个阶段。因为开发者既可以使用系统提供的类加载器来完成加载，也可以自定义类加载器来完成加载。

3.2、验证

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

Java 语言本身是比较安全的语言，但是正如上面说到的.class文件未必是从 Java 源码编译而来，可以使用任何途径来生成并加载。虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

验证阶段大致会完成 4 项检验工作：

文件格式验证：验证字节流是否符合Class文件格式的规范，例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型等
元数据验证：对字节码描述的元数据信息进行语义分析，要符合 Java 语言规范，例如：是否继承了不允许被继承的类（例如 final 修饰过的）、类中的字段、方法是否和父类产生矛盾等等
字节码验证：对类的方法体进行校验分析，确保这些方法在运行时是合法的、符合逻辑的
符号引用验证：确保解析动作能正确执行，例如：确保符号引用的全限定名能找到对应的类，符号引用中的类、字段、方法允许被当前类所访问等等

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3.3、准备

准备是连接阶段的第二步，这个阶段的主要工作是正式为类变量分配内存并设置其初始值的阶段，这些变量所使用的内存都将在方法区中分配。

不过这个阶段，有几个知识点需要注意一下：

1.这时候进行内存分配的仅仅是类变量（被static修饰的变量），而不是实例变量，实例变量将会在对象实例化的时候随着对象一起分配在 Java 堆中
2.这个阶段会设置变量的初始值，值为数据类型默认的零值（如 0、0L、null、false 等），不是在代码中被显式地赋予的值；但是当字段被final修饰时，这个初始值就是代码中显式地赋予的值
3.在 JDK1.8 取消永久代后，方法区变成了一个逻辑上的区域，这些类变量的内存实际上是分配在 Java 堆中的，跟 JDK1.7 及以前的版本稍有不同

关于第二个知识点，我们举个简单的例子进行讲解，比如public static int value = 123，value在准备阶段过后是0而不是123。

因为这时候尚未开始执行任何 Java 方法，把value赋值为123的public static指令是在程序编译后存放于类构造器<clinit>()方法之中的，因此把value赋值为123的动作将在初始化阶段才会执行。

假如被final修饰，比如public static final int value = 123就不一样了，编译时Javac将会为value生成ConstantValue属性，在准备阶段，虚拟机就会给value赋值为123，因为这个变量无法被修改，会存入类的常量池中。

各个数据类型的零值如下图：

数据类型	零值
byte	0
short	0
int	0
long	0L
float	0.0f
double	0.0d
boolean	false
char	\u0000
reference	null

3.4、解析

解析是连接阶段的第三步，这个阶段的主要工作是虚拟机会把这个.class文件中常量池内的符号引用转换为直接引用。

主要解析的是类或接口、字段、方法等符号引用，我们可以把解析阶段中符号引用转换为直接引用的过程，理解为当前加载的这个类和它所引用的类，正式进行“连接“的过程。

我们先来了解一下符号引用和直接引用有什么区别：

符号引用：这个其实是属于编译原理方面的概念，Java 代码在编译期间，是不知道最终引用的类型，具体指向内存中哪个位置的，这时候会使用一个符号引用来表示具体引用的目标是"谁"，符号引用和虚拟机的内存布局是没有关系的
直接引用：指的是可以直接或间接指向目标内存位置的指针或句柄，直接引用和虚拟机实现的内存布局是有关系的

符号引用转换为直接引用，可以理解成将某个符号与虚拟机中的内存位置建立连接，通过指针或句柄来直接访问目标。

与此同时，同一个符号引用在不同的虚拟机实现上翻译出来的直接引用一般不会相同。

3.5、初始化

初始化是类加载的过程的最后一步，这个阶段的主要工作是执行类构造器 <clinit>()方法的过程。

简单的说，初始化阶段做的事就是给static变量赋予用户指定的值，同时类中如果存在static代码块，也会执行这个静态代码块里面的代码。

初始化阶段，虚拟机大致依此会进行如下几个步骤的操作：

1.检查这个类是否被加载和连接，如果没有，则程序先加载并连接该类
2.检查该类的直接父类有没有被初始化，如果没有，则先初始化其直接父类
3.类中如果有多个初始化语句，比如多个static代码块，则依次执行这些初始化语句

有个地方需要注意的是：虚拟机会保证类的初始化在多线程环境中被正确地加锁、同步执行，所以无需担心是否会出现变量初始化时线程不安全的问题。

如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都会阻塞等待，直到<clinit>()方法执行完毕。同时，同一个类加载器下，一个类只会初始化一次，如果检查到当前类没有初始化，执行初始化；反之，不会执行初始化。

与此同时，只有当对类的主动使用的时候才会触发类的初始化，触发时机主要有以下几种场景：

1.创建类的实例对象，比如new一个对象操作
2.访问某个类或接口的静态变量，或者对该静态变量赋值
3.调用类的静态方法
4.反射操作，比如Class.forName("xxx")
5.初始化某个类的子类，则其父类也会被初始化，并且父类具有优先被初始化的优势
6.Java 虚拟机启动时被标明为启动类的类，比如SpringBootApplication入口类

最后，<clinit>()方法和<init>()方法是不同的，一个是类构造器初始化，一个是实例构造器初始化，千万别搞混淆了啊。

四、小结

当一个符合 Java 虚拟机规范的.class字节码文件，经历加载、验证、准备、解析、初始化这些 5 个阶段相互协作执行完成之后，虚拟机会将此文件的二进制数据导入运行时数据区的方法区内，然后在堆内存中，创建一个java.lang.Class类的对象，这个对象描述了这个类所有的信息，同时提供了这个类在方法区的访问入口。

可以用如下图来简要描述。