理解 JVM 工作机制(十) 类加载机制和加载的过程
类加载的机制
类的生命周期
类从被加载到虚拟机内存开始,到卸载出内存为止,它的整个生命周期包括以下 7 个阶段:
加载
验证
准备
解析
初始化
使用
卸载
加载、验证、准备、初始化和卸载这 5 个阶段的顺序是确定的,类的加载过程必须按照这种顺序按部就班地开始(注意是“开始”,而不是“进行”或“完成”),而解析阶段则不一定:它在某些情况下可以在初始化后再开始,这是为了支持 Java 语言的运行时绑定。
类加载过程初始化的时机
Java 虚拟机规范没有强制约束类加载过程的第一阶段(即:加载)什么时候开始,但对于“初始化”阶段,有着严格的规定。有且仅有 6 种情况必须立即对类进行“初始化”:
在遇到 new、putstatic、getstatic、invokestatic 字节码指令时,如果类尚未初始化,则需要先触发其初始化。
使用
java.lang.reflect
包的方法第一次对类进行反射调用时会触发类的初始化初始化类时,如果发现父类还没有初始化,则需要先触发父类的初始化
虚拟机启动时,用户需要指定一个主函数类(
main()
方法所在的类),虚拟机会先启动这个类当使用 JDK 1.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类还没初始化,则需要先触发其初始化。
接口中定义了 JDK 8 新加入的默认方法(
default
修饰符),实现类在初始化之前需要先初始化其接口
这六种场景的行为称为对一个类型的主动引用,除此之外,所有引用类型的方式都不会触发初始化,称为被动引用。
被动引用演示 Demo
Demo1
对于静态字段,只有直接定义这个字段的类才会被初始化,因此通过其子类来引用父类中定义的静态字段,只会触发父类的初始化而不会触发子类的初始化。
Demo2
这段代码不会触发父类的初始化,但会触发“[L 全类名”这个类的初始化,它由虚拟机自动生成,直接继承自 java.lang.Object,创建动作由字节码指令 newarray 触发。
Demo3
编译通过之后,常量存储到 NotInitialization 类的常量池中,NotInitialization 的 Class 文件中并没有 ConstClass 类的符号引用入口,这两个类在编译成 Class 之后就没有任何联系了。
接口的加载过程
接口加载过程与类加载过程稍有不同。
当一个类在初始化时,要求其父类全部都已经初始化过了,但是一个接口在初始化时,并不要求其父接口全部都完成了初始化,当真正用到父接口的时候才会初始化。
init 和 clinit 区别
init 和 clinit 方法执行时机不同
init 是对象构造器方法,也就是说在程序执行 new 一个对象调用该对象类的 constructor 方法时才会执行 init 方法,而 clinit 是类构造器方法,也就是在 jvm 进行类加载—–验证—-解析—–初始化,中的初始化阶段 jvm 会调用 clinit 方法。
类加载过程
类加载过程包括 5 个阶段:加载、验证、准备、解析和初始化。
加载
“加载”是“类加载”过程的一个阶段,不能混淆这两个名词。在加载阶段,虚拟机需要完成 3 件事:
通过类的全限定名获取该类的二进制字节流。
将二进制字节流所代表的静态结构转化为方法区的运行时数据结构。
在内存中创建一个代表该类的 java.lang.Class 对象,作为方法区这个类的各种数据的访问入口。
获取二进制字节流
对于 Class 文件,虚拟机没有指明要从哪里获取、怎样获取。除了直接从编译好的 .class 文件中读取,还有以下几种方式:
从 zip 包中读取,如 jar、war 等
从网络中获取,如 Applet
通过动态代理技术生成代理类的二进制字节流
由 JSP 文件生成对应的 Class 类
从数据库中读取,如 有些中间件服务器可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
“非数组类”与“数组类”加载比较
非数组类加载阶段可以使用系统提供的引导类加载器,也可以由用户自定义的类加载器完成,开发人员可以通过定义自己的类加载器控制字节流的获取方式(如重写一个类加载器的 loadClass() 方法)
数组类本身不通过类加载器创建,它是由 Java 虚拟机直接创建的,再由类加载器创建数组中的元素类。
注意事项
虚拟机规范未规定 Class 对象的存储位置,对于 HotSpot 虚拟机而言,Class 对象比较特殊,它虽然是对象,但存放在方法区中。
加载阶段与连接阶段的部分内容交叉进行,加载阶段尚未完成,连接阶段可能已经开始了。但这两个阶段的开始时间仍然保持着固定的先后顺序。
验证
验证的重要性
验证阶段确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。
验证的过程
文件格式验证 验证字节流是否符合 Class 文件格式的规范,并且能被当前版本的虚拟机处理,验证点如下:
是否以魔数 0XCAFEBABE 开头
主次版本号是否在当前虚拟机处理范围内
常量池是否有不被支持的常量类型
指向常量的索引值是否指向了不存在的常量
CONSTANT_Utf8_info 型的常量是否有不符合 UTF8 编码的数据
......
元数据验证 对字节码描述信息进行语义分析,确保其符合 Java 语法规范。
字节码验证 本阶段是验证过程中最复杂的一个阶段,是对方法体进行语义分析,保证方法在运行时不会出现危害虚拟机的事件。
符号引用验证 本阶段发生在解析阶段,确保解析正常执行。
准备
准备阶段是正式为类中定义的变量(即静态变量,被 static 修饰的变量)分配内存并设置类变量初始值的阶段,从概念上讲,这些变量所使用的内存都应当在方法区中进行分配,但必须注意到方法区本身是一个逻辑上的区域,在 JDK7 及之前,HotSpot 使用永久代来实现方法区时,实现是完全符合这种逻辑概念的;而在 JDK8 及之后,类变量则会随着 Class 对象一起存放在 Java 堆中,这时候“类变量在方法区"就完全是一种对逻辑概念的表述了。
初始值“通常情况下”是数据类型的零值(0, null...),假设一个类变量的定义为:
那么变量 value 在准备阶段过后的初始值为 0 而不是 123,因为这时候尚未开始执行任何 Java 方法。
存在“特殊情况”:如果类字段的字段属性表中存在 ConstantValue 属性,那么在准备阶段 value 就会被初始化为 ConstantValue 属性所指定的值,假设上面类变量 value 的定义变为:
那么在准备阶段虚拟机会根据 ConstantValue 的设置将 value 赋值为 123。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用( Symbolic References):符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在《Java 虚拟机规范》的 Class 文件格式中。
直接引用(Direct References) :直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在虚拟机的内存中存在。
初始化
类初始化阶段是类加载过程的最后一步,是执行类构造器 <clinit>() 方法的过程。
<clinit>() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static {} 块)中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的。
静态语句块中只能访问定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块中可以赋值,但不能访问。如下方代码所示:
<clinit>() 方法不需要显式调用父类构造器,虚拟机会保证在子类的 <clinit>() 方法执行之前,父类的 <clinit>() 方法已经执行完毕。
由于父类的 <clinit>() 方法先执行,意味着父类中定义的静态语句块要优先于子类的变量赋值操作。如下方代码所示:
<clinit>() 方法不是必需的,如果一个类没有静态语句块,也没有对类变量的赋值操作,那么编译器可以不为这个类生成 <clinit>() 方法。
接口中不能使用静态代码块,但接口也需要通过 <clinit>() 方法为接口中定义的静态成员变量显式初始化。但接口与类不同,接口的 <clinit>() 方法不需要先执行父类的 <clinit>() 方法,只有当父接口中定义的变量使用时,父接口才会初始化。
虚拟机会保证一个类的 <clinit>() 方法在多线程环境中被正确加锁、同步。如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的 <clinit>() 方法。
版权声明: 本文为 InfoQ 作者【ue4】的原创文章。
原文链接:【http://xie.infoq.cn/article/4761070881a48b0a428ef64b6】。文章转载请联系作者。
评论