JVM:类加载机制

本文源自参考《深入理解jvm虚拟机》，多篇博文的总结

前言

我们编写的代码最终会编译为Class文件，Class文件中描述的各种信息，最
终都需要加载到虚拟机中之后才能运行和使用。而虚拟机如何加载这些Class文件？Class文
件中的信息进入到虚拟机后会发生什么变化？这些都关系着代码的最终运行情况。

一 类加载器

类加载器：通过一个类的全限定名来获取描述此类二进制字节流的代码模块

这是类加载器比较官方的说法，简单来说就是负责读取Java字节码信息。

1.1类的唯一性

类在Java虚拟机中的唯一性：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。
通俗一点来讲，要判断两个类是否“相同”，前提是这两个类必须被同一个类加载器加载，且类字节码相同，否则这个两个类不“相同”。
这里所指的“相等”，包括代表类的Class对象的equals（）方法、isAssignableFrom（）方
法、isInstance（）方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。

1.2 类加载器种类

1. 启动类加载器 Bootstrap ClassLoader：加载JACA_HOMElib，或者被-Xbootclasspath参数限定的类。使用C++语言实现，是Java虚拟机自身的一部分，启动类加载器无法被Java程序直接引用。
2. 扩展类加载器 Extension ClassLoader：加载libext，或者被java.ext.dirs系统变量指定的类。开发人员可以直接使用。
3. 应用程序类加载器 Application ClassLoader：加载用户类路径（ClassPath）上所指定的类库，是ClassLoader中的getSystemClassLoader（）方法的返回值。开发人员可以直接使用。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
4. 自定义类加载器通过继承ClassLoader实现，一般是加载我们的自定义类。

类加载器 Java 类如同其它的Java类一样，也是要由类加载器来加载的。

二 双亲委派模型

既然有这么多种类加载器，那么在JVM中类在加载时，各个类加载器是怎么协调统一运作的呢，这就引出了双亲委派模型。

（它并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载器实现
方式。不过我们常用的JVM都实现了该模型，如：官方下载的JavaSE中JVM——Oracle Hotspot）

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己
去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

双亲委派好处:1.避免同一个类被多次加载 2.每个加载器只能加载自己范围内的类

三 类加载时机

理解了类加载器，即可开始说明类的加载详情了。首先我们要知道，JVM在什么时候会进行类加载。

3.1 类在JVM中的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载
（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析3个部分统称为连接（Linking）。

3.2 类加载的各阶段顺序

在图中，加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程
必须按照这种顺序按部就班地开始（按顺序开始，而不是完成。因为这些阶段通常都是互相交叉地混合式进行的）。

并且解析阶段并不完全遵守图中描述的加载顺序：它在某些情况下可以在初始化阶
段之后再开始，这是为了支持Java语言的运行时绑定（即动态绑定）。

3.3 类加载时机

Java虚拟机规范中并没有进行强制约束类加载时机，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

1.遇到new、getstatic、putstatic、invokestatic这4条字节码指令时。生成这4条指令最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

2.使用java.lang.reflect包方法对类进行反射调用的时候。

3.当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4.当虚拟机启动时，用户需要指定一个要执行的主类（包含main()的那个类），虚拟机会先初始化这个主类。

5.当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，则需要先触发这个方法句柄所对应的类的初始化。

四 类加载过程

接下来我们详细讲解一下Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。

4.1 加载

加载阶段是类加载过程的第一个阶段。在这个阶段，JVM的主要目的是将字节码从各个位置（网络、磁盘等）转化为二进制字节流加载到内存中，接着会为这个类在JVM的方法区创建一个对应的 Class 对象，这个 Class对象就是这个类各种数据的访问入口。

分开来说加载阶段主要做了三件事。
1.通过一个类的全限定名来获取定义此类的二进制字节流。
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据
的访问入口。

4.2 验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机——class文件是否符合Java规范，代码是否逻辑正确。

主要有4个验证动作：

1.文件格式验证:验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。(这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，所以后面的3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。)

2.元数据验证:是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。简单来说就是验证类的元数据信息是否符合Java规范。

3.字节码验证：会对代码组成的数据流和控制流进行校验，验证程序语义是否合法、符合逻辑。

4.符号引用验证：发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将
在连接的第三阶段——解析阶段中发生。

4.3 准备

当完成字节码文件的校验之后，JVM便会开始为类变量分配内存并初始化。这里需要注意两个关键点，即内存分配的对象以及初始化的类型。（也是面试题中经常考的内容）

• ****内存分配的对象**。Java中的变量有「类变量」和「类成员变量」两种类型，「类变量」指的是被 static 修饰的变量，而其他所有类型的变量都属于「类成员变量」。在准备阶段，JVM 只会为「类变量」分配内存，而不会为「类成员变量」分配内存。「类成员变量」的内存分配需要等到初始化阶段才开始。
• 初始化的类型。在准备阶段，JVM会为类变量分配内存，并为其初始化。但是这里的初始化指的是为变量赋予 Java 语言中该数据类型的零值，而不是用户代码里初始化的值。
  例如下面的代码在准备阶段之后，sector 的值将是 0，而不是 3。

但有一点例外。如果一个变量是常量（被 static final修饰）的话，那么在准备阶段，属性便会被赋予用户希望的值。
例如下面的代码在准备阶段之后，number 的值将是 3，而不是 0。

public static final int number = 3;

4.4 解析

当通过准备阶段之后，JVM针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符 7 类引用进行解析。这个阶段的主要任务是将其在常量池中的符号引用替换成直接其在内存中的直接引用。

其实这个阶段对于我们来说也是几乎透明的，了解一下就好。

4.5 初始化

到这一步JVM才开始执行我们编写的Java代码，按照一定的顺序，依次执行静态代码。
具体顺序如下：

1. 静态属性：static 开头定义的属性
2. 静态方法块： static {} 圈起来的方法块

执行完成后，类的初始化便算完成了，一个Java对象的创建往往包含了类的初始化和类的实例化两步骤。如果进行了类的实例化，还会按顺序执行以下步骤：

1.普通属性： 未带static定义的属性
2.普通方法块： {} 圈起来的方法块
3.构造函数： 类名相同的方法
4.方法： 普通方法