虚拟机的类加载机制
:Java虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这个过程被称作虚拟机的类加载机制
与那些在 编译时需要进行连接 的语言不同
在Java语言里面,类型的加载、连接和初始化过程都是在 程序运行期间完成的
Java天生可以动态扩展的语言特性就是依赖 运行期动态加载 和 动态连接 这个特点实现的
类的生命周期(从被加载到虚拟机内存开始,到卸载出为止):
验证、准备、解析三个部分统称为连接(Linking)
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类型的加载过程必须按照这种顺序按部就班地开始,而解析阶段则不一定:它在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)。
主动引用( 必须初始化 的场景)
被动引用
加载、验证、准备、解析和初始化 5个步骤
1)通过一个类的 全限定名 来获取定义此类的 二进制字节流 。 (它并没有指明二进制字节流必须得从某个
Class文件中获取,确切地说是根本没有指明要从哪里获取、如何获取)
2)将这个字节流所代表的 静态存储结构 转化为 方法区 的 运行时数据结构。
3)在 内存 (堆)中 生成一个代表这个类的java.lang.Class对象 ,作为方法区这个类的各种数据的 访问入口 。
数组类型和非数组类型有区别。
image-20210427154420027
对于数组类而言,情况就有所不同,数组类本身不通过类加载器创建,它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系,因为数组类的元素类型(ElementType,指的是数组去掉所有维度的类型)最终还是要靠类加载器来完成加载,一个数组类(下面简称为C)创建过程遵循以下规则:(略)P365
加载阶段结束后 ,Java虚拟机外部的 二进制字节流 就按照虚拟机所设定的格式 存储在方法区之中
了,方法区中的数据存储格式完全由虚拟机实现自行定义,《Java虚拟机规范》未规定此区域的具体数据结构。类型数据妥善 安置在方法区之后 ,会在
Java堆内存中实例化一个java.lang.Class类的对象 ,这个对象将作为程序访问方法区中的类型数据的 外部接口 。
类 和 数组加载过程的区别 ?
数组也有类型,称为“数组类型”。如:String[] str = new String[10];
这个数组的数组类型是Ljava.lang.String,而String只是这个数组中元素的类型。
当程序在运行过程中遇到new关键字 创建一个数组时,由JVM直接创建数组类,再由类加载器创建数组中的元素类。
而普通类的加载由类加载器完成。既可以使用系统提供的引导类加载器,也可以使用用户自定义的类加载器。
* **原因** : **Class文件并不一定只能由Java源码编译而来,它可以使用包括靠键盘0和1直接在二进制编辑器中敲出Class文件在内的任何途径产生** 。上述Java代码无法做到的事情在字节码层面上都是可以实现的,至少语义上是可以表达出来的。Java虚拟机如果不检查输入的字节流,对其完全信任的话,很可能会因为载入了有错误或有恶意企图的字节码流而导致整个系统受攻击甚至崩溃,所以验证字节码是 **Java虚拟机保护自身** 的一项必要措施。
四个阶段:
验证阶段对于虚拟机的类加载机制来说,是一个 非常重要 的、但 却不是必须要执行的阶段 ,因为验证阶段只有通过或者不通过的差别,只要通过了验证,其后就对程序运行期没有任何影响了。如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码) 都已经被反复使用和验证过 ,在生产环境的实施阶段就可以考虑使用-Xverify:none参数来 关闭大部分的类验证措施 ,以 缩短虚拟机类加载的时间 。
准备阶段: 正式为 类中定义的静态变量 (即静态变量,被static修饰的变量)分配内存并设置类变量初始值的阶段。
(这里所说的初始值“通常情况”下是 数据类型的零值
。如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量值就会被初始化为ConstantValue属性所指定的初始值)
概念上讲,这些变量所使用的内存都应当在 方法区 中进行分配,在JDK
7及之前,HotSpot使用永久代来实现方法区时,实现是完全符合这种逻辑概念的;
在JDK 8及之后,类变量则会随着Class对象一起存放在 Java堆 中
public static int value = 123;
那变量value在 准备阶段过后的初始值为0而不是123 ,因为这时尚未开始执行任何Java方法,而把 value赋值为123的putstatic指令是程序被编译后,存放于类构造器<clinit>()方法之中,所以把 value赋值 为123的动作要到类的初始化阶段 才会被执行
public static final int value = 123;
编译时Javac将会为value生成ConstantValue属性,在准备阶段虚拟机就会根据Con-stantValue的设置将value赋值为123。
解析阶段 :是Java虚拟机将常量池内的 符号引用 替换为 直接引用 的过程
《Java虚拟机规范》之中并 未规定解析阶段发生的具体时间 ,只要求了在 执行 ane-
warray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invoke-
special、
invokestatic、invokevirtual、ldc、ldc_w、ldc2_w、multianewarray、new、putfield和putstatic
这17个用于操作符号引用的字节码指令之前 , 先对它们所使用的符号引用进行解析 。
解析动作 主要针对 类 或 接口 、 字段、类方法、接口方法、方法类型、方法句柄 和 调用点限定符
这7类符号引用进行
image-20210427190744756
前提:解析字段所属的类或者接口的符号引用。
要解析一个未被解析过的字段符号引用, 首先将会对字段表内class_index
项中索引的CONSTANT_Class_info符号引用进行解析,也就是 字段所属的类或接口的符号引用
。如果在解析这个类或接口符号引用的过程中出现了任何异常,都会导致字段符号引用解析的失败。
java.lang.NoSuchFieldError异常
image-20210427192557687
前提:解析方法所属的类或者接口的符号引用。 是需要先解析出方法表的 class_index项 中索引的方法所属的类或接口的符号引用
image-20210427193211104
java.lang.NoSuchMethodError
前提:解析接口方法所属的类或者接口的符号引用。 是需要先解析出 接口方法表 的class_index项中索引的方法所属的类或接口的符号引用
在JDK
9之前,Java接口中的所有方法都默认是public的,也没有模块化的访问约束,所以不存在访问权限的问题,接口方法的符号解析就不可能抛出java.lang.IllegalAccessError异常。但在JDK
9中增加了接口的静态私有方法,也有了模块化的访问约束,所以从JDK
9起,接口方法的访问也完全有可能因访问权限控制而出现java.lang.IllegalAccessError异常。
在编译生成class文件时,会自动产生两个方法,一个是类的初始化方法clinit(), 另一个是实例的初始化方法init()
clinit():在jvm第一次加载class文件时调用,包括静态变量初始化语句和静态块的执行
init():在实例创建出来的时候调用,包括调用new操作符;调用Class或java.lang.reflect.Constructor对象的newInstance()方法;调用任何现有对象的clone()方法;通过java.io.ObjectInputStream类的getObject()方法反序列化。
类的初始化阶段是类加载过程的最后一个步骤,除了在 加载阶段 用户应用程序 可以通过自定义 类加载器的方式局部参与外,
其余动作都完全由Java虚拟机来主导控制 。直到 初始化阶段 ,Java虚拟机才 真正开始执行类中编写的Java程序代码
,将主导权移交给 应用程序 。
进行 准备阶段 时,变量已经赋过一次系统要求的 初始零值 ,而在 初始化阶段 ,则会根据程序员通过程序编码制定的主观计划去
初始化类变量和其他资源 。
初始化阶段就是执行类构造器clinit()方法的过程
。clinit()并不是程序员在Java代码中直接编写的方法,它是Javac编译器的自动生成物。
clinit()方法 是由 编译器 自动收集 类 中的 所有类变量的赋值动作 和
静态语句块(static{}块)中的语句
合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问
初始化阶段就是执行类构造器clinit()的过程。
clinit()方法由编译器自动产生,收集类中static{}代码块中的类变量赋值语句和类中静态成员变量的赋值语句。在准备阶段,类中静态成员变量已经完成了默认初始化,而在初始化阶段,clinit()方法对静态成员变量进行显示初始化。??(显式初始化)
public class Test {
static {
i = 0; // 给变量复制可以正常编译通过
System.out.print(i); // 这句编译器会提示“非法向前引用”
}
static int i = 1;
}
同一个类加载器下,一个类型只会被初始化一次
类加载阶段 :通过一个类的全限定名来获取描述该类的二进制字节 流。
把这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“ 类加载器” (Class
Loader)。
对于任意一个类,都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。
这句话可以表达得更通俗一些: 比较两个类是否“相等” ,只有在这两个类是 由同一个类加载器加载的前提下
才有意义,否则,即使这两个类来源于同一个 Class文件,被同一个Java虚拟机加载, 只要加载它们的类加载器不同,那这两个类就必定不相等 。
各种类加载器之间的层次关系被称为类加载器的 “双亲委派模型 (Parents Delegation
Model)”。双亲委派模型要求除了顶层的启动类加载器外, 其余的类加载器都应有自己的父类加载器
。不过这里类加载器之间的父子关系一般不是以继承(Inheritance)的关系来实现的,而是 **通常使用
组合(Composition)关系来复用父加载器的代码** 。
双亲委派模型的工作过程是: 如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是 把这个请求委派给父类加载器去完成,
每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到最顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去完成加载
好处
双亲委派模型的实现:
在 java.lang.ClassLoader的loadClass()方法 之中
先检查请求加载的类型是否已经被加载过,若没有则调用父加载器的
loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。假如父类加载器加载失败,抛出ClassNotFoundException异常的话,才调用自己的findClass()方法尝试进行加载。
双亲委派模型并 不是一个具有强制性约束的模型 ,而是Java设计者 推荐 给开发者们的类加载器实现方式。
双亲委派模型的优点我总结得不太好,建议大家多看看其它优秀的博客
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。