上一篇文章中我们已经提到了,一个类加载的过程分为以下的七个步骤加载 -> 验证 -> 准备 -> 解析 -> 初始化 -> 使用 -> 卸载
,并且我们也在上一篇文章《深入理解jvm》读书笔记之——类加载机制(类的初始化)中解释了类的初始化过程,那么今天我们就聊一聊其他 的几个的过程.
加载
类的加载过程
加载的过程中,jvm要完成以下的三件事:
- 通过一个类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
这里我们需要注意的是,对于第一条,jvm并没有特殊的去指定这个类应该从哪里获取,基于这一条,现在的java平台发展处了jar,war等;以及动态的运行时计算生成,也就是我们现在著名的动态代理技术;另外也诸如由其他的文件生成,例如jsp。
类的加载阶段可以使用系统的类加载器,也可以自定义类加载器(重新一个类加载器的loadClass
方法)
特殊的情况-数组
对于数组而言,本身不通过类加载器创建,直接有jvm创建,但是数组类的元素类型最终还是由类加载器去加载,一个数组类创建过程会遵循下面的规则:
- 数组类型是引用类型,递归的遵循上面的加载过程去加载这个组件类型,该数组会在加载该组件类型的类加载器的类名称空间上被标示(这一点是为了确保一个类的在同一个jvm唯一性安全)
- 数组的组件类型不是引用类(如int[]),jvm会将数组标记为与引导类加载器关联
- 数组类可见性与它的组件类型可见性一致,如果组件类型不是引用型,那数组类的可见性默认为public。
加载的阶段完成后,jvm外部的二进制字节流按虚拟机所需要的格式存在方法区里,方法区中的数据存储格式由jvm自行定义。然后在内存中实例化一个java.lang.Class类的对象(没有明确规定是在java堆里,对于Hotspot来说,Class对象比较特殊,虽然是对象,却会放在方法区里)
验证
验证是为了确保class的字节流是符合当前jvm的,并且对jvm没有危害。
对于验证这一步骤来讲要经历以下的几个过程:
- 文件格式验证:(是否以java的魔数开头,主次版本号是否正确,常量池常理是否有不被支持等等),这个阶段是基于二进制字节流进行的,通过这个阶段之后,字节流会进入内存的方法区,然后开启后面的验证。
- 元数据验证:(是否有父类,父类是否继承了不允许被继承的final类,是否实现了抽象方法等等)。
- 字节码验证:(通过数据流和控制流分析,确定语义合法性,逻辑连通性,校验类的方法是否会做出危害jvm安全的事)。
- 符号引用验证:(符号引用中通过字符串描述的全限定是否正确,符号引用中的访问属性private等是否正确)。
stackMapTable
由于字节码验证这个操作过于复杂,jdk6之后,方法体的Code属性的属性表增加了"stackMapTable"
(我们把他称为栈图
),这个属性是用来描述方法体中所有的基本块在开始时本地变量表和操作栈应有的状态,在字节码验证就需要根据程序做推到验证了,只需要做栈图
中的属性记录是否合法就可以了,这样就把原来的字节码验证由类型推到
变成了类型验证
。
jdk6中,Hotspot提供了-XX:-UseSplitVerifier这个参数来关闭这些优化,jdk7之后,对于主版本大于50的class。只能使用栈图
来校验。
准备
准备阶段是正式为类变量分配内存并初始化值的阶段,这些变量用的内存都在方法区中进行分配。而这里我们所指的类变量就是static变量。
我们这里举个例子public static int a = 123;
,这里的变量a
就是类变量。并且这里我们需要注意一个事情,对于准备阶段而已,变量a
的值是0,而复制变量a
为123的操作是在初始化阶段的clinit
方法中执行的。
但是对于上面的情况,如果把变量a
用final修饰,public static final int a = 123;
,那么在编译时javac会为变量a
生成ConstantValue
属性,在准备阶段Jvm就会根据ConstantValue
的设置为变量a
赋值。
解析
解析就是jvm将常量池内的符号引用替换为直接引用的过程。
符号引用:以一组符号来描述所引用的目标,符号可以是类和形式的字面量,只要使用时能无歧义的定位到目标即可,与虚拟机实现的内存布局无关,引用的目标不一定已经加载到内存中。
直接引用:可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的,引用的目标必定已经在内存中存在。
除了invokeDynamic指令以外,虚拟机实现可以对第一次解析的结果进行缓存(在运行时常量池中记录直接引用,并把常量标示为已解状态)从而避免解析动作重复进行。无论是否真正被执行了多少次解析,jvm需要保证的是在同一个实体中,如果一个符号引用之前已经被成功解析过,那后续的引用解析请求就应该一直成功;同理,第一次解析失败了,那么其他指令对这个符号的解析请求也就应该收到相同的异常。
对应上面的规则,invokeDynamic指令是例外的,invokeDynamic指令只有在程序实际运行到这条指令解析动作才开始进行。
而java的解析阶段主要是针对于4块:类或者接口的解析、字段解析、类方法解析,接口方法解析