【JVM第二章】JVM-类加载

夜9夜久

已于 2023-05-22 12:01:48 修改

阅读量84

点赞数

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

于 2023-05-21 00:40:05 首次发布

本文链接：https://blog.csdn.net/qq_27028647/article/details/130787734

版权

JVM 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

类加载：加载、连接（验证、准备、解析）、初始化、使用、卸载。
类的加载过程并不是一成不变的，根据各种情况他们穿插交替的来加载一个类

1. 类加载流程

1.1 通过一个类的全限定名来获取此类的二进制字节流。（class文件字节流）（加载）
1.2 连接 - 验证 - 文件格式验证（连接 - 验证）

二进制文件格式CA FE BA BE开头

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

class文件是一个静态的二进制文件，里面存放的是我们的类中所有的常量，结构，字段，方法，属性，这些都是静态存储在class文件中

1.4 连接 - 验证 - 元数据验证

这个类是否有父类（除Object外，所有的类都应该有父类）
这个类的父类是否继承不允许被继承的类（被final修饰的类）
这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法

1.5 连接 - 验证 - 字节码验证（这个阶段主要对Class文件中的Code属性进行校验分析）
- 保证数据类型与指令码一直；如：在操作数栈是int类型，使用时却按照long类型加载到本地变量表中
- 保证指令跳转不会跳转到方法体外
- 保证方法中类型转化总是有效的；如：子类赋值给父类数据类型，这是安全的，但是父类赋值给子类数据类型是危险不合法的

PS：通过了字节码验证并不是就一定是安全的，那么程序也就不会有BUG了
那么什么情况可以节约字节码验证时间呢？
JDK6以后编译器和Java虚拟机进行了一个联合优化，把尽可能多的校验辅助措施挪到javac编译器里进行。
具体就是给方法体Code属性的属性表中增加一项名为StackMapTable新属性
StackMapTable描述了方法体所有的基本块开始时本地变量表和操作栈应有的状态，在字节码验证期间，Java虚拟机就不需要根据程序推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。这样就把字节码验证类型推导转变为类型检查，从而节省了大量的时间

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

生成的对象在堆中，我们所有的对象里面的字段，方法的访问入口在我们的堆里面，这个入口直通方法区

1.7 连接 - 准备（类变量-静态变量，有个类）（初始化“零”值）

JDK8以后类变量（静态变量）会随着Class对象一起存放到堆中
这里是不包括实例变量（成员变量），实例变量会随着对象实例化时一起分配到堆中

public staic int value = 123；
在准备阶段后的初始值是0，赋值123是在类构造器()法之中，所以要到类初始化才会被执行赋值
其次初始值还有特殊情况就是final饰的类变量，会在ConstantValue属性中就会为赋值为123 public staic final
int value = 123；

1.8 连接 - 解析 - 符号引用

解析阶段就是将常量池内的符号引用替换成直接引用的过程
只要在执行anewarray、checkcast、getfiled、getstatic、instanceof、invokedynamic、1.9 invokeinterface等17个用于操作符号引用的字节码指令之前，需要先对其符号引用解析

1.10 连接 - 解析 - 类和接口

1.11 连接 - 解析 - 字段解析

1.12 连接 - 解析 - 类方法

1.13 连接 - 解析 - 接口方法

2. 类加载过程

2.1 初始化

初始化阶段就是执行类构造器()方法的过程，这个时候会通过程序员主观计划去初始化类变量和其他资源
()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（staic{}块）中的语句合并产生
()方法对于类和接口来说并不是必须的，只要类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不用为这个类生成()方法
类和接口的()方法执行顺序同是，接口不需要先执行父接口，而类必须的，在接口中只有父接口中定义变量被用时候，父接口才会被初始化，此外接口的实现类在初始化时候也不会在初始化的时候执行()方法
Java虚拟机必须保证一个类的()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的()方法

2.2 立即初始化情况

对于初始化阶段，虚拟机规范中严格定义了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：

使用new关键字实例化对象的时候
读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候
调用一个类型的静态方法的时候

使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化。
当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

3. 类加载子系统

3.1 类加载器

在这里插入图片描述

3.2 双亲委派

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

使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。**（保证程序的安全性，类加载的有规则性）

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。（确保类的唯一可确定性）