JVM的类加载机制及双亲委派模型

最新推荐文章于 2024-01-11 19:02:13 发布

云淡风qin

最新推荐文章于 2024-01-11 19:02:13 发布

阅读量146

点赞数

分类专栏： Java 文章标签： jvm java

本文链接：https://blog.csdn.net/userID66/article/details/130291014

版权

Java 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

双亲委派机制

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载。
双亲委派模型

好处
沙箱安全机制：自己写的String.class类不会被加载，这样便可以防止核心API库被随意篡改。
避免类的重
复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次
破坏时期

双亲委派模型的第一次“被破坏”是重写自定义加载器的loadClass()。
双亲委派模型的第二次“被破坏”是ServiceLoader和Thread.setContextClassLoader()。即线程上下文类加载器（contextClassLoader）。双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用代码调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢？线程上下文类加载器就出现了。
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求导致的，这里所说的“动态性”指的是当前一些非常“热门”的名词：代码热替换、模块热部署等，简答的说就是机器不用重启，只要部署上就能用

类加载机制

java 类加载过程

类加载

1. Loading(加载)阶段

所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型——类模板对象。
在加载类时，Java 虚拟机必须完成以下 3 件事情：
- 通过类的全名，获取类的二进制数据流。

- 解析类的二进制数据流为方法区内的数据结构（Java 类模型）

- 创建 java.lang.Class 类的实例，表示该类型。作为方法区这个类的各种数据的访问入口.

2. Verification(验证)阶段

它的目的是保证加载的字节码是合法、合理并符合规范的。
**具体说明：**

1.格式验证：是否以魔数 0XCAFEBABE 开头，主版本和副版本号是否在当前 Java 虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。

2.语义检查：Java 虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如：

是否所有的类都有父类的存在（在 Java 里，除了 object 外，其他类都应该有父类）
是否一些被定义为 final 的方法或者类被重写或继承了
非抽象类是否实现了所有抽象方法或者接口方法

3.字节码验证：Java 虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：

在字节码的执行过程中，是否会跳转到一条不存在的指令
函数的调用是否传递了正确类型的参数
变量的赋值是不是给了正确的数据类型等

栈映射帧（StackMapTable）就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。

在前面3次检查中，已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。

4.符号引用的验证：校验器还将进符号引用的验证。Class 文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出 NoClassDefFoundError，如果一个方法无法被找到，则会抛出 NoSuchMethodError。此阶段在解析环节才会执行。

3.Preparation(准备)阶段

简言之，为类的静态变分配内存，并将其初始化为默认值。

注意：
1.这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。

// 一般情况：static final修饰的基本数据类型、字符串类型字面量会在准备阶段赋值
private static final String str = "Hello world";
// 特殊情况：static final修饰的引用类型不会在准备阶段赋值，而是在初始化阶段赋值
private static final String str = new String("Hello world");

2.注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到 Java 堆中。
3.在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

4.Resolution(解析)阶段

解析阶段是虚拟机将常量池内的符号引用****替换为直接引用的过程，解析动作主要针对类或接口、字
段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

5.Initialization(初始化)阶段

为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化，包括给声明类变量指定初始值，和为类static变量指定静态代码块地址。

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

主动使用

1.实例化： 当创建一个类的实例时，比如使用 new 关键字，或者通过反射、克隆、反序列化。

2.静态方法： 当调用类的静态方法时，即当使用了字节码 invokestatic 指令。

3.静态字段： 当使用类、接口的静态字段时（final 修饰特殊考虑），比如，使用 getstatic 或者 putstatic 指令。（对应访问变量、赋值变量操作）

4.反射：当使用 java.lang.reflect 包中的方法反射类的方法时。比如：Class.forName(“com.atguigu.java.Test”)

5.继承：当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

当 Java 虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。

在初始化一个类时，并不会先初始化它所实现的接口
在初始化一个接口时，并不会先初始化它的父接口
因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。

6.default 方法：如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。

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

VM 启动的时候通过引导类加载器加载一个初始类。这个类在调用 public static void main(String[])方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化。

8.MethodHandle：当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。（涉及解析 REF getStatic、REF_putStatic、REF invokeStatic 方法句柄对应的类）

被动使用

1.静态字段：当通过子类引用父类的静态变量，不会导致子类初始化，只有真正声明这个字段的类才会被初始化。

2.数组定义：通过数组定义类引用，不会触发此类的初始化

3.引用常量：引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。

4.loadClass 方法：调用 ClassLoader 类的 loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

6.Using(使用)阶段

任何一个类型在使用之前都必须经历过完整的加载、链接和初始化 3 个类加载步骤。一旦一个类型成功经历过这 3 个步骤之后，便“厉事俱备只欠东风”，就等着开发者使用了。

开发人员可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用 new 关键字为其创建对象实例。

7.卸载(Unloading)阶段

情况：
（1）启动类加载器加载的类型在整个运行期间是不可能被卸载的（jvm 和 jls 规范）

（2）被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到 unreachable 的可能性极小。

（3）被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中（比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的时间是不确定的）。

综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。