02_类的加载过程

最新推荐文章于 2023-05-27 14:02:06 发布

Coder_yupeng

最新推荐文章于 2023-05-27 14:02:06 发布

阅读量70

点赞数

分类专栏： # JVM 文章标签： java jvm

本文链接：https://blog.csdn.net/weixin_43215305/article/details/120028013

版权

JVM 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

类的加载过程

本文整理自尚硅谷宋红康老师在B站的视频，侵权即删。

本文的思维导图如下：

在这里插入图片描述

1 概述

按照Java虚拟机规范，对于一个类来说，从class文件到加载到内存中的类，再到类卸载出内存为止，它的整个生命周期包括以下七个阶段：

在这里插入图片描述

其中，验证、准备和解析三个环节统称为链接(Linking)阶段。

从程序中类的使用过程来看：

在这里插入图片描述

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，不需要加载，而引用数据类型需要进行类的加载。

2 阶段一：Loading(加载)阶段

2.1 加载完成的操作

对于加载的理解：

所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型一一类模板对象。所谓类模板对象，其实就是Java类在JVM内存中的一个快照，JVM从字节码文件中解析出的常量池、类字段、类方法等信息，存储到类模板中，这样JVM在运行期便能通过类模板获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。

反射的机制即基于这一基础，如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。

加载完成的操作：

加载阶段，可以概括为：查找并加载类的二进制数据，生成Class的实例。

在加载类时，Java虚拟机必须完成以下三件事情：

通过类的全名，获取类的二进制数据流
解析类的二进制数据流为方法区内的数据结构（Java类模型）
创建java.lang.Class类的实例，表示该类型，此实例作为方法区中这个类的各种数据的访问入口

因此，我们所说的加载完毕包括：加载、链接、初始化三个阶段都完成之后，类进入方法区中。

2.2 二进制流的获取方式

对于类的二进制数据流，虚拟机可以通过多种途径产生或获得：（所读取的字节码必须符合JVM规范）

虚拟机通过文件系统，读入一个class后缀的文件（最常见）
读入jar、zip等归档数据包，提取类文件
读取存放在数据库中的类的二进制数据
使用类似于HTTP之类的协议通过网络进行加载
在运行时生成一段Class的二进制信息等

在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例。

如果输入数据不是classFile的结构，则会抛出 ClassFormatError。

2.3 类模型与Class实例的位置

类模型的位置：

加载的类在JVM中创建相应的类模型(类结构)，类模型会存储在方法区（JDK1.8之前：永久代；JDK1.8及之后：元空间）。

Class实例的位置：

将类的.class文件加载至方法区后，会在堆区中创建一个java.lang.Class实例对象，用于封装位于方法区内的数据结构，即类模型；该Class对象在加载类的过程中创建，每个类都有一个对应的Class类型的对象。

举例：

在这里插入图片描述

2.4 数组类的加载

创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素对应的类型仍然需要依靠类加载器创建。

创建数组类（下述简称A）的过程：

1.如果数组的元素类型是引用类型，则遵循定义的加载过程，递归加载和创建数组A的元素类型；

2.JVM使用指定的元素类型和数组维度来创建新的数组类。

如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定；否则数组类的可访问性将被缺省定义为public。

3 阶段二：Linking(链接)阶段

3.1 环节1：链接阶段之Verification(验证)

当类加载到内存中后，便开始链接阶段的操作，验证时链接阶段的第一个环节。其目的是保证加载的字节码是合法、合理且符合规范的。

验证环节的步骤比较复杂，实际要验证的项目繁多，大体上虚拟机需要做以下检查：

在这里插入图片描述

整体说明：

验证内容主要涵盖类数据信息的格式验证、语义检查、字节码验证和符号引用验证等。

格式验证部分会和类的加载阶段一起执行。验证通过后，类加载器才会成功地将类的二进制数据信息加载至方法区中。
格式验证之外的其他检查操作会在方法区中进行。

链接阶段的验证环节虽然拖慢了加载速度，但它避免了在字节码运行时还需要进行的各项检查，可谓磨刀不误砍柴工。

具体说明：

格式验证
- 是否以魔数0xCAFEBABE开头
- 主版本号和副版本号是在当前Java虚拟机的支持范围内
- 数据中心的每一项是否都具有正确的长度等
语义检查，语义上不符合规范的，虚拟机不会给予验证通过
- 是否一些被定义为final的方法被重写了，或者被定义为final的类被继承了
- 是否所有的类都有父类存在(除Object外，其他类都应该有父类)
- 非抽象类是否实现了全部抽象方法或接口方法
- 是否存在不兼容的方法(比如，方法的签名除返回值不同，其他都一样，这种方法让虚拟机无法调度；一个方法被abstract修饰，就不能被final修饰了)
字节码验证，此部分是验证环节最复杂的过程，试图对字节码流的分析，判断字节码是否可以被正确执行
- 在字节码的执行过程中，是否会跳转到一条不存在的指令
- 函数的调用是否传递了正确类型的参数
- 栈映射帧(StackMapTable)就是在此过程，用户检测在特定的字节码处，局部变量表和操作数栈是否有正确的数据类型。遗憾的是，100%准确判断一段字节码是否可以被安全执行是无法实现的，因此，字节码验证只是尽可能的检查可预知的明显问题。即，如果无法通过字节码验证，则虚拟机无法正确加载这个类；如果通过字节码验证，也不能说明该类完全没问题。
前面3次检查中，已排除文件格式错误、语义错误以及字节码的不正确性，但依然不能保证类没有问题。
符号引用验证，class文件在其常量池会通过字符串记录该类将要使用的其他类或者方法，因此，在验证阶段，虚拟机会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用的类无法在系统中找到，会抛出 NoClassDefFoundError，如果一个需要使用的方法无法被找到，则会抛出 NoSuchMethodError。此部分在解析环节才会执行。

3.2 环节2：链接阶段之Preparation(准备)

准备阶段的作用是为类的静态变量分配内存，并为其赋默认值。

一个类通过验证环节后，会进入准备阶段，为该类分配相应的内存空间，并设置默认初始值。各类型变量的默认值如下表：

类型	默认初始值
byte	(byte)0
short	(short)0
int	0
long	0L
float	0.0f
double	0.0
char	\u0000
boolean	false
reference	null

注意：

Java并不支持boolean类型，对于boolean类型，内部实现是int，由于int的默认值是0，所以对应的， boolean的默认值是false。
准备环节不会为实例变量赋默认初始值，类变量分配在方法区，而实例变量是随着实例对象一起分配到Java堆中。
准备环节不会有初始化或者代码被执行。

3.3 环节3：链接阶段之Resolution(解析)

解析阶段的作用是将类、接口、字段和方法的符号引用转化为直接引用。

符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，当某个方法被调用时，系统需要明确知道该方法在内存中的真实位置。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

举例：

输出操作System.out.println()对应的字节码为

invokevirtual #24 <java/io/PrintStream.println>

在这里插入图片描述

以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在方法表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用。

4 阶段三：Initialization(初始化)阶段

4.1 static与final的搭配问题

初始化阶段的作用是，为类的静态变量赋予正确的初始值。

该阶段是类的加载的最后一个阶段，如果前面的步骤都没有问题，表示类可以正确加载到系统中。此时，类才会开始执行Java字节码，即真正开始执行类中定义的程序代码。

初始化阶段的重要工作是执行类的初始化方法——<clinit>()方法：

该方法仅能由Java编译器生成并由WM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成
该方法由类静态成员变量的赋值语句以及static代码块合并产生的
该方法不用于类的构造器，构造器是虚拟机视角下的<init>()方法。

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>()总是在子类的<clinit>()之前被调用。也就是说，父类的static代码块优先级高于子类。

Java编译器不会为所有的类都产生<clinit>()初始化方法。以下情况中，字节码文件中将不会包含<clinit>()方法：

情况1：类中没有声明任何的类变量，也没有静态代码块

public class InitializationTest1 {
    public int num = 1;
}

情况2：类中声明了类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作

public class InitializationTest2 {
    // 声明了类变量，但没有显式赋值，不会生成<clinit>()方法，此时num的值为链接阶段的准备环节赋的默认初始值
    public static int num;
}

情况3：类中包含static final修饰的类变量，需要分情况讨论

public class InitializationTest3 {
    // 场景1：类变量类型为基本数据类型，且等号右侧为字面量
    public static final int INT_CONSTANT1 = 3;
    // 场景2：类变量类型为String类型，且等号右侧为字面量
    public static final String STR_CONSTANT1 = "hello";
    // 以上场景在链接阶段的准备环节显式赋值
    
    // 其余场景在初始化阶段的<clinit>()方法中赋值，比如
    // 场景3：类变量类型为基本数据类型，等号右侧为调用其他方法产生的值
    public static final int INT_CONSTANT2 = new Random.nextInt(10);
    // 场景4：类变量类型为String类型，等号右侧为new方法产生的字符串
    public static final String STR_CONSTANT2 = new String("foo");
    // 场景5：类变量类型为引用数据类型
    public static final int INTEGER_CONSTANT1 = 2;
}

4.2 clinit()的线程安全性

<clinit>()方法的线程安全性：

对于<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性，在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行 <clinit>()方法完毕。

如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时，虚拟机会直接返回已经准备好的信息。

正是因为函数<clinit>()带锁线程安全的，因此，如果在两个类的<clinit>()方法中有耗时很长的操作，且在<clinit>()方法中互相调用，就可能造成多个线程阻塞，引发死锁，并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。

4.3 类的初始化情况：主动使用vs被动使用

Java程序对类的使用分为两种：主动使用和被动使用。

主动使用：Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是指主动使用，主动使用只有下列几种情况：（即：如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。）

创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化
调用类的静态方法时，即当使用了字节码invokestatic指令
使用类、接口的静态字段时（final修饰特殊考虑，可参考4.1中对static final的说明），比如，使用getstatic(访问变量)或者putstatic(赋值变量)指令。
使用java.lang.reflect包中的方法反射类的方法时。比如：class. forName(“com.xxx.www.Test”)
初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
- 补充说明：初始化一个类时，要求它的所有父类都己经被初始化，但是这条规则并不适用于接口。
  - 初始化一个类时，并不会先初始化它所实现的接口
  - 初始化一个接口时，并不会先初始化它的父接口
- 因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。
如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化
虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类
- JVM启动时，通过引导类加载器加载一个初始类，这个类在调用 public static void main(String[] args)方法之前被链接和初始化；这个方法的执行将依次导致所需的类的加载，链接和初始化。
初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类。（涉及解析REF getstatic、REF_ putstatic、 REF invokeStatic方法句柄对应的类）

被动使用：除以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。即：并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化。

访问一个静态字段时，只有真正声明这个字段的类才会被初始化。
- 当通过子类引用父类的静态变量，不会导致子类初始化
通过数组定义类引用，不会触发此类的初始化
引用常量不会触发此类或接口的初始化（注意分情况，可参考4.1中对static final的说明），因为常量在链接阶段就己经被显式赋值了
调用Classloader类的 loadclass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化

5 类的Using(使用)阶段

任何一个类在使用之前都必须经历过完整的加载、链接和初始化这三个类加载阶段，一旦一个类型成功经历过这三个阶段之后，开发人员可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用new关键字为其创建对象实例。

6 类的Unloading(卸载)阶段

当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类模板在方法区的数据也会被卸载，从而结束Sample类的生命周期。所以，一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

类、类的加载器、类的实例之间的引用关系为：

在类加载器的内部实现中，用一个Java集合存放所加载类的引用。另一方面，一个Class实例总是会引用它的类加载器，调用Class实例的getClassloader()方法，就能获得它的类加载器。由此可见，代表某个类的class实例与其类的加载器之间为双向关联关系。

一个类的实例总是引用代表这个类的Class实例。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class实例的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class实例。

在这里插入图片描述

loader变量和obj变量间接引用代表Sample类的Class实例，而objClass直接引用它。

如果程序运行过程中，将上图左侧三个引用变量都置为null，此时 Sample实例结束生命周期， MyClassLoader对象结束生命周期，代表Sample类的Class实例也结束生命周期， Sample类在方法区内的二进制数据被卸载。

当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载：如果不存在 Sample类会被重新加载，在虚拟机的堆区会生成一个新的代表Sample类的Class实例（可通过哈希码查看是否是同一个实例）。

说明：一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的：

启动类加载器加载的类型在整个运行期间是不可能被卸载的（JVM和jls规范）。
应用程序类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为应用程序类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。
被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中，比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的时间是不确定的）。

关于方法区的垃圾回收：

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。判定一个常量是否“废弃”还是相对简单，但是要判定一个类型是否属于“不再使用的类型”的条件就比较苛刻了。需要同时满足下面三个条件：