JVM——虚拟机类加载机制

梦里梦外; 2024-03-25 13:11 111阅读 0赞

**目录**

引言

概述

类加载的时机

类加载的过程

1.加载

2.验证

①.文件格式验证

②.元数据验证

③.字节码验证

④.符号引用验证

3.准备

4.解析

5.初始化

类加载器

1.类与类加载器

2.双亲委派模型

--------------------

## 引言 ##

在Class文件中描述的各类信息，最终都需要加 载到虚拟机中之后才能被运行和使用。而虚拟机如何加载这些Class文件？Class文件中的信息进入到虚 拟机后会发生什么变化？

## 概述 ##

Java虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java 类型，这个过程被称作虚拟机的类加载机制。

## **类加载的时机**  ##

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

![a3c10aa298b949fa8dd10a002060e4a8.png][]

>  加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按 
> 
> 照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始， 这是为了支持Java 语言的运行时绑定特性（也称为动态绑定或晚期绑定）。

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

> 1 ）遇到 new 、 getstatic 、 putstatic 或 invokestatic 这四条字节码指令时，如果类型没有进行过初始 化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java 代码场景有： 
> 
>  *  使用new关键字实例化对象的时候。 
>  *  读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外） 的时候。 
>  *  调用一个类型的静态方法的时候。 
> 
> 2 ）使用 java.lang.reflect 包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需 要先触发其初始化。3 ）当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。 
> 
> 4 ）当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 方法的那个类），虚拟机会先 初始化这个主类。 
> 
> 5 ）当使用 JDK 7 新加入的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解 析结果为REF\_getStatic 、 REF\_putStatic 、 REF\_invokeStatic 、 REF\_newInvokeSpecial 四种类型的方法句 柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。 
> 
> 6 ）当一个接口中定义了 JDK 8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有 这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

## **类加载的过程**  ##

###  **1.加载**  ###

在加载阶段，Java虚拟机需要完成以下三件事情：

1）通过一个类的全限定名来获取定义此类的二进制字节流。

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3）在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入 口。

### **2.验证** ###

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚 拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段大致上会完成下面四个阶段的检验动作： **文件格式验证、元数据验证、字节**

**码验证和符号引用验证。**

#### **①.文件格式验证** ####

这一阶 段可能包括下面这些验证点：

*  是否以魔数0xCAFEBABE开头。 
 *  主、次版本号是否在当前Java虚拟机接受范围之内。 
 *  常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。 
 *  指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。 
 *  CONSTANT\_Utf8\_info型的常量中是否有不符合UTF-8编码的数据。 
 *  Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。

>  该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符 合描述一个Java 类型信息的要求。

#### ②.**元数据验证**  ####

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要 求，这个阶段可能包括的验证点如下：

*  这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。 
 *  这个类的父类是否继承了不允许被继承的类（被final修饰的类）。 
 *  如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。 
 *  类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等）。

>  第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相悖的元数据信息。

####  **③.字节码验证**  ####

第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定 程序语义是合法的、符合逻辑的。

#### **④.符号引用验证**  ####

最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用\[3\]的时候，这个转化动作将在 连接的第三阶段——解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号 引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。本阶段通常需要校验下列内容：

*  符号引用中通过字符串描述的全限定名是否能找到对应的类。 
 *  在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。 
 *  符号引用中的类、字段、方法的可访问性（private、protected、public、<package>）是否可被当前类访问。

>  符号引用验证的主要目的是确保解析行为能正常执行，如果无法通过符号引用验证，Java 虚拟机 将会抛出一个java.lang.IncompatibleClassChangeError 的子类异常。

### **3.准备**  ###

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段。

### **4.解析**  ###

解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

解析阶段中所说的直接引用与符号引用又有什么关联呢？

> **符号引用（Symbolic References）：** 符号引用以一组符号来描述所引用的目标，符号可以是任何 形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引 用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同， 但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规 范》的Class 文件格式中。 
> 
> **直接引用（Direct References）：** 直接引用是可以直接指向目标的指针、相对偏移量或者是一个能 间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚 拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

解析又有四个步骤：1.类或接口的解析 2.字段解析 3.方法解析 4.接口方法解析

### **5.初始化**  ###

类的初始化阶段是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

## **类加载器** ##

类加载器可以说是Java语言的一项创新，它是早期Java语言能够快速流行的重要原因之一。类加载器最初是为了满足Java Applet的需求而设计出来的，在今天用在浏览器上的Java Applet技术基本上已经被淘汰\[1\]，但类加载器却在类层次划分、OSGi、程序热部署、代码加密等领域大放异彩，成为Java技术体系中一块重要的基石，可谓是失之桑榆，收之东隅。

### **1.类与类加载器** ###

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

>  比较两个类是否“相 等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

###  **2.双亲委派模型**  ###

类加载器就应当划分得更细致一些。自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构

*  启动类加载器：加载 JDK 中 lib 目录中 Java 的核心类库。
 *  扩展类加载器：加载 lib/ext 目录下的类。
 *  应用程序类加载器：加载自己写的应用程序。
 *  自定义类加载器：根据自己的需求定制类加载器。

![4582715b56d94beeaac057d230710cc0.png][]

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

#### 破坏双亲委派模型 ####

在某些情况下需要破坏这个模型，所以双亲委派模型不是必然的。比如 Java 中 SPI 机制中的 JDBC 的实现，或者是 tomcat 中的 servlet 加载。tomcat 中的 类加载机制：为了给每个 web 容器单独提供一个 WebAppClassLoader 加载器，优先加载 web 应用自己定义的类也就是交给子类加载器加载的，这样就破坏了遵守双亲委派模型。

--------------------

![bf582c938291496fa2fb54de02d7ad7e.png][]

[a3c10aa298b949fa8dd10a002060e4a8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/e4d0b5b12b5f4911b1bdb07bffe18e5a.png
[4582715b56d94beeaac057d230710cc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/66b500856d834ccb8d03f3b3a2842b53.png
[bf582c938291496fa2fb54de02d7ad7e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/d5466cbfaa444880876d6d6586ffd99f.png