本文参考于《深入理解Java虚拟机》
Java虚拟机把描述类的数据从Class文件加载到内存
,并对数据进行校验
、转换解析
和初始化
,最终形成可以被虚拟机直接使用的Java类型
,这个过程被称作虚拟机的类加载机制。
一个类型从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用和卸载
七个阶段,其中验证、准备、解析三个部分统称为连接。
图示
上图中加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类型的加载过程必须按照这种顺序按部就班地开始,而解析阶段则不一定:解析在某些情况下可以在初始化阶段之后再开始
,这是为了支持Java语言的运行时绑定特性(也称为动态绑定或晚期绑定)。请注意,这里笔者写的是按部就班地“开始”,而不是按部就班地“进行”或按部就班地“完成”,强调这点是因为这些阶段通常都是互相交叉地混合进行的,会在一个阶段执行的过程中调用、激活另一个阶段
。
“加载”阶段
是整个“类加载”过程中的一个阶段。在加载阶段,Java虚拟机需要完成以下三件事情:
数据的访问入口
。验证是连接阶段的第一步,这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求,保证这些信息被当作代码运行后不会危害虚拟机自身的安全
。
1. 文件格式验证
验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。
2. 元数据验证
对字节码描述的信息进行语义分析,以保证其描述的信息符合《Java语言规范》的要求。
主要目的是对类的元数据信息进行语义校验
,保证不存在与《Java语言规范》定义相悖的元数据信息。3. 字节码验证
第三阶段是整个验证过程中最复杂的一个阶段,主要目的是通过数据流分析和控制流分析,确定程序语义是合法的、符合逻辑的
。这阶段就要对类的方法体(Class文件中的Code属性)进行校验分析,保证被校验类的方法在运行时不会做出危害虚拟机安全的行为
。
例如:
4. 符号引用验证
符号引用验证可以看作是对类自身以外(常量池中的各种符号引用)的各类信息进行匹配性校验
,通俗来说就是,该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。
校验的内容
准备阶段是正式为类中定义的变量(即静态变量,被static修饰的变量)分配内存并设置类变量初始值
的阶段,这里所说的初始值“通常情况”下是数据类型的零值
。
特别注意:该阶段的所有变量的值都是相应的数据类型的零值
,而不是赋值以后的值。
例如
public static float a = 123f;
处于该阶段下的 a
的值为0.0f
。
解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程
。
符号引用以一组符号来描述所引用的目标
,符号可以是任何形式的字面量
,只要使用时能无歧义地定位到目标即可
。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须都是一致的
,因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄
。直接引用是和虚拟机实现的内存布局直接相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在虚拟机的内存中存在
。类的初始化阶段是类加载过程的最后一个步骤
。直到初始化阶段,Java虚拟机才真正开始执行类中编写的Java程序代码,将主导权移交给应用程序
。进行准备阶段时,变量已经赋过一次系统要求的初始零值,而在初始化阶段,则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。我们也可以从另外一种更直接的形式来表达:初始化阶段就是执行类构造器< clinit >()方法的过程
。
编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的
,编译器收集的顺序是由语句在源文件中出现的顺序决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问。它不需要显式地调用父类构造器
,Java虚拟机会保证在子类的< clinit >()方法执行前
,父类的< clinit >()方法已经执行完毕
。因此在Java虚拟机中第一个被执行的< clinit >()方法的类型肯定是java.lang.Object
。父类中定义的静态语句块要优先于子类的变量赋值操作
。< clinit >()方法对于类或接口来说并不是必需的
,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成< clinit >()方法。有变量初始化的赋值操作
,因此接口与类一样都会生成< clinit >()方法。但接口与类不同的是,执行接口的< clinit >()方法不需要先执行父接口的< clinit >()方法
,因为只有当父接口中定义的变量被使用时,父接口才会被初始化。此外,接口的实现类在初始化时也一样不会执行接口的< clinit >()方法
。一个类的< clinit >()方法在多线程环境中被正确地加锁同步
。卸载过程就是该类Class对象被回收。
所有的实例对象都已被 GC
,也就是说堆不存在该类的实例对象。没有在其他任何地方被引用
类加载器的实例已被 GC
BootstrapClassLoader, ExtClassLoader, AppClassLoader
负责加载 jdk 提供的类,所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的
,所以使用我们自定义加载器加载的类是可以被卸载掉的。比较两个类是否“相等”,只有在这两个类是由同一个类加载器加载的前提下才有意义
,否则,即使这两个类来源于同一个Class文件,被同一个Java虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等。
BootstrapClassLoader : 最顶层的加载类,由C++
实现,负责加载%JAVA_HOME%/lib
目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类
。
ExtensionClassLoader : 主要负责加载 %JRE_HOME%/lib/ext
目录下的 jar 包和类,或被 java.ext.dirs 系统变量所指定的路径下的 jar 包
。
AppClassLoader : 面向我们用户的加载器
,负责加载当前应用 classpath 下的所有 jar 包和类
。
1)想加载非 classpath 随意路径中的类文件
2)都是通过接口来使用实现,希望解耦时,常用在框架设计
3)这些类希望予以隔离,不同应用的同名类都可以加载,不冲突,常见于 tomcat 容器
在类加载的时候,系统会首先去检查这个类是否被加载过
,如果这个类被加载过的话,那么就是将已经被加载过的类直接返回。如果没有被加载过的话,那么就会尝试去加载。首先会把该请求委派给父类加载器的 loadClass() 处理
,因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader
中。当父类加载器无法处理时,才由自己来处理。当父类加载器为 null
时,会使用启动类加载器 BootstrapClassLoader 作为父类加载器
。
图示
不仅仅根据类名
,相同的类文件被不同的类加载器加载产生的是两个不同的类
。比如我们编写一个称为 java.lang.Object 类的话
,那么程序运行的时候,系统就会出现多个不同的 Object 类
。版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/weixin_56727438/article/details/121370084
内容来源于网络,如有侵权,请联系作者删除!