【JavaEE初阶】 JVM类加载简介

文章目录

🍃前言
🌲类加载过程
- 🚩加载
- 🚩验证
- 🚩准备
- 🚩解析
- 🚩初始化
🎄双亲委派模型
- 🚩什么是双亲委派模型？
- 🚩双亲委派模型的优点
⭕总结

🍃前言

本篇博文的重点内容主要有以下两点

类加载的过程
双亲委派模型

🌲类加载过程

整个 JVM 执行的流程中，和程序员关系最密切的就是类加载的过程了，所以

接下来我们来看下类加载的执行流程。

对于一个类来说，它的生命周期是这样的：

在这里插入图片描述
其中前 5 步是固定的顺序并且也是类加载的过程，其中中间的 3 步我们都属于连接，所以对于类加载来说总共分为以下几个步骤：

加载
连接
1. 验证
2. 准备
3. 解析
初始化

博主这里分为5个步骤来介绍。

下面我们分别来看每个步骤的具体执行内容

🚩加载

“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，它和类加载 Class Loading 是不同的，一个是加载 Loading 另一个是类加载 Class Loading，所以不要把二者搞混了。

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

通过一个类的全限定名来获取定义此类的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

🚩验证

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

验证选项：

文件格式验证
字节码验证
符号引用验证
…

🚩准备

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

🚩解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程，也就是初始化常量的过程。

🚩初始化

初始化阶段，Java 虚拟机真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。初始化阶段就是执行类构造器方法的过程

🎄双亲委派模型

提到类加载机制，不得不提的一个概念就是“双亲委派模型”。

站在 Java 虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

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

🚩什么是双亲委派模型？

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

在这里插入图片描述

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

🚩双亲委派模型的优点

避免重复加载类：比如 A 类和 B 类都有一个父类 C 类，那么当 A 启动时就会将 C 类加载起来，那么在 B 类进行加载时就不需要在重复加载 C 类了。
安全性：使用双亲委派模型也可以保证了 Java 的核心 API 不被篡改，如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object类的话，那么程序运行的时候，系统就会出现多个不同的Object 类，而有些 Object 类又是用户自己提供的因此安全性就不能得到保证了。