概述
Class 文件中描述的各种信息,都要加载到虚拟机中之后才能被运行和使用。而虚拟机如何加载这些Class文件?Class文件中的信息进入到虚拟机后会发生什么变化?
虚拟机把描述类的数据从 Class 文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java 类型,这既是虚拟机的类加载机制。
在 Java 语言中,类型的加载和连接过程都是在程序运行期间完成的,这样会在类加载时稍微增加一些性能开销,但是却能为 Java 应用程序提供高度的灵活性, Java 中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
类加载的时机
类从被加载到虚拟机内存中开始,到卸载出内存位置,他的整个生命周期包括了:加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中验证、准备和解析三个部分统称为连接。
如图所示,加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的,类的加载过程必须按照这个顺序按部就班地开始,但是解析阶段则不一定:在某些情况下可以在初始化之后再开始,这是为了支持 Java 语言的运行时绑定(也称为动态绑定或晚期绑定)。
什么时候开始类加载过程的第一阶段,也即加载呢?虚拟机规范中并没有进行强行约束,这点可以交给虚拟机的具体实现来自由把握。
什么时候开始类的初始化呢?虚拟机规范则是严格规定了有且只有四种情况必须立即对类进行“初始化”(而加载、验证、准备、自然需要在此之前开始):
- 遇到 new、getstatic、putstatic 或 invokestatic 这4条字节码指令是,如果类没有进行初始化,则需要先触发其初始化。生成这4条指令的最常见的 Java 代码场景是:使用 new 关键字实例化对象时、读取或设置一个类的静态字段时、以及调用一个类的静态方法的时候。
- 使用 java.lang.reflect 包的方法对类进行发射调用的时候,如果类没有进行初始化,则需要先触发其初始化。
- 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
- 当虚拟机启动时,用户需要制定一个要执行的主类(包含 main() 方法的那个类),虚拟机会初始化这个主类。
除此之外,所有引用类的方法,都不会触发初始化,称为被动引用。
例子1
public class TestClass {
public static void main(String[] args) {
System.out.println(SubClass.value);
}
}
class SuperClass {
static {
System.out.println("SuperClass init!");
}
public static int value = 123;
}
class SubClass extends SuperClass {
static {
System.out.println("SubClass init~");
}
}
SuperClass init!
123
说明 只有直接定义这个字段的类才会被初始化,因此通过其子类来引用父类中定义的静态字段,只会触发父类的初始化而不会触发子类的初始化。至于会不会触发子类的加载和验证,在虚拟机规范中并为明确规定。
例子2
public class TestClass {
public static void main(String[] args) {
SuperClass[] sca = new SuperClass[10];
}
}
没有输出 SuperClass init!
没有输出SuperClass init!,说明没有触发类 SuperClass 的初始化阶段。
例子3
public class TestClass {
public static void main(String[] args) {
System.out.println(ConstClass.HELLOWORLD);
}
}
class ConstClass {
static {
System.out.println("ConstClass init!");
}
static final String HELLOWORLD = "hello world";
}
hello world
并没有输出 “ConstClass init!”,这是因为虽然在 Java 源码中引用了 ConstClass 类中的常量 HELLOWORLD,但是在编译阶段将此常量的值 “hello world” 存储到 TestClass类的常量池中,对常量 ConstClass.HELLOWORLD 的引用实际上被转化为 TestClass 类对自身常量池的引用。
类加载的过程
详细讲解一下类加载的全过程,也就是加载、验证、准备、解析和初始化这五个阶段。
1. 加载
“加载(Loading)” 阶段是 ”类加载(Class Loading)“ 过程的一个阶段。在加载阶段,虚拟机需要完成以下三件事件:
- 通过一个类的全限定名来获取定义此类的二进制字节流;
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在 Java 堆中生成一个代表这个类的 java.lang.Class 对象,作为方法区这个数据的访问入口。
2. 验证
验证是连接阶段的第一步,这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。
验证的实现会完成下面四个阶段的检验过程:文件格式验证、元数据验证、字节码验证和符号引用验证。
2.1 文件格式验证
第一阶段要验证字节流是否符合Class 文件格式的规范,并且能被当前版本的虚拟机处理,包括:
- 是否以魔数 0xCAFEBABE 开头;
- 主次版本号是否在当前虚拟机处理范围之内。
- 常量池的常量中是否有不被支持的常量类型(检查常量tag)
- …
该检验阶段的主要目的是确保输入的字节流能正确地解析并存储于方法区之中,格式上符合描述一个 Java 类型信息的要求。这个阶段段的校验是基于字节流进行的,经过了这个阶段的验证之后,字节流才会进入内存的方法区中进行存储,所以后面三个验证阶段全部都是基于方法区的存储结构进行的。
2.2 元数据验证
第二阶段是对字节码描述的信息进行语义分析,以确保其描述的信息符合 Java 语言规范的要求,包含:
- 这个类是否有父类
- 这个类的父类是否继承了不允许被继承的类(被 final 修饰的类)
- 如果这个类不是抽象类,是否实现了其父类或者接口之中要求实现的所有方法
- …
第二阶段的目的是对类的元数据信息进行语义校验,保证不存在不符合 Java 语言规范的元数据信息。
2.3 字节码校验
第三阶段是整个验证过程中最复杂的一个阶段,主要工作是进行数据流和控制流分析,该阶段对类的方法体进行校验分析。该阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。
2.4 符号引用验证
最后一个阶段的验证发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在链接的第三阶段 – 解析阶段中发生。符号引用验证的目的是确保解析动作能正常执行。
3. 准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中进行分配。
注:
-
进行内存分配的仅包括类变量(被static 修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。
-
初始值 通常情况下 是数据类型的的零值。
-
通常情况如下,变量value 在准备阶段过后的初始值为0 而不是 123。
public static int value = 123;
-
特殊情况如下,如果类字段的字段属性表中存在ConstantValue 属性,则会在准备阶段就将value的值赋为 123。
public static final int value = 123;
-
4. 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
- 符号引用:符号引用以一组符号来描述所引用的目标。符号可以是任何形式的字面量,只要使用是能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。
- 直接引用:直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。
虚拟机实现会根据需要来判断,到底是在类被加载器加载是就对常量池中的符号引用进行解析,还是等到一个符号引用将要被使用前才去解析它。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行,分别对应常量池的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info 及 CONSTANT_InterfaceMethodref_info 四种常量类型。
4.1 类或接口的解析
假设当前代码所处的类为D,如果要把一个从未解析过的符号引用 N 解析为一个类或接口 C 的直接引用,那虚拟机完成整个解析的过程需要包含以下3个步骤。
- 如果 C 不是一个数组类型,那虚拟机将会把代表 N 的全限定名传递给 D 的类加载器去加载这个类 C。在加载过程中,由于无数据验证、字节码验证的需要,又将可能触发其他相关类的加载动作,例如加载这个类的父类或实现的接口,一旦这个加载过程出现了异常,解析过程就将宣告失败。
- 如果 C 是一个数组类型,并且数组的元素类型为对象,也就是 N 的描述符会是类似 “[Ljava.lang.Integer” 的形式,那么将会按照第一点的规则加载数组元素类型。如果 N 的描述符如前面所假设的形式,需要加载的元素类型就是 “java.lang.Integer”,接着有虚拟机生成一个代表此数组维度和元素的数组对象。
- 如果无异常,那么 C 在虚拟机中实际上已经成为一个有效的类或接口了,但是在解析完成之前还要进行符号引用验证。确认 C 是否具备对D 的访问权限。
4.2 字段解析
要解析一个未被解析过的字段符号引用,首先将会对字段表内 class_index 项中索引的 CONSTANT_Class_info 符号引用进行解析,也就是字段所属的类或接口的符号引用。如果在解析这个类或接口的符号引用的过程中出现了任何异常,都会导致字段符号引用解析的失败。如果解析成功完成,那将这个字段所属的类或接口用 C 表示,对 C 进行后续字段的搜索:
- 如果 C 本身就包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
- 否则,如果在C中实现了接口,将会按照继承关系从上往下递归搜索各个接口和他的父接口,如果接口中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
- 否则,如果 C 不是 java.lang.Object 的话,将会按照继承关系从上往下递归搜索各个父类,如果父类中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
- 否则,查找失败,抛出 java.lang.NoSunchFieldError 。
如果查找过程成功返回了引用,将会对这个字段进行权限验证,如果发现不具备对字段的访问权限,将会抛出 java.lang.IllegalAccessError 异常。
4.3 类方法解析
类方法解析的第一步骤与字段解析一样,之后:
- 类方法和接口方法符号引用的常量类型定义是分开的,如果在类方法表中发现 class_Index 中索引的 C 是个接口,直接抛出异常
- 如果通过第一步,在类 C 中查找是否有简单名称和字段描述符都与目标相匹配的字段,如果有则返回这个字段的直接引用,查找结束。
- 否则,在类 C 的父类中递归查找简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
- 否则,在类 C 实现的接口列表以它们的父接口之间递归查找是否有简单名称和字段描述符都与目标相匹配的字段,如果存在匹配的方法,说明类 C 是一个抽象类,这时候查找结束,排除抽象方法异常。
- 否则,宣告方法查找失败。
如果查找过程成功返回了直接引用,将会对这个方法进行权限验证,如果发现不具备对此方法的访问权限,将抛出异常。
4.4 接口方法解析
接口方法解析的第一步骤与字段解析一样,之后:
- 与类方法解析相反,如果在接口方法表中索引 C 是个类而不是接口,那就直接抛出异常
- 否则,在接口 C 中查找是否有简单名称和字段描述符都与目标相匹配的字段,如果有则返回这个字段的直接引用,查找结束。
- 否则,否则,在类 C 的父类接口中递归查找简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
- 否则,宣告方法查找失败。
由于接口中所有方法都默认是 public 的,所以不存在访问权限的问题。
5. 初始化
类初始化阶段是类加载过程的最后一步,到了初始化阶段,才真正开始执行类中定义的 Java 程序代码(或者说是字节码)
在准备阶段,变量已经赋过一次系统要求的初始值,而在初始化阶段,则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器< clinit >() 方法的过程。
- 类构造器< clinit >() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{} 块)中的语句合并产生的。编译器收集的顺序是又语句在原文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在他之后的变量,在前面的静态语句块中可以赋值,但是不能访问。
- < clinit >() 方法与类的构造函数(或者说实例构造器< init >() 方法)不同,它不需要显示地调用父类构造器,因此在虚拟机中第一个被执行的< clinit>() 方法的类肯定是 java.lang.Obeject.
- 由于父类的< clinit >() 方法先执行,也就意味着父类中的静态语句块要优先于子类的变量赋值操作。
- < clinit >() 方法对于类或接口并不是必须的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成 < clinit >() 方法。
- 接口中不能使用静态语句块,但是仍有变量初始化的赋值操作,因此接口和类一样会生成< clinit >() 方法。但只有当父接口中定义的变量被使用时,父接口才会被初始化。另外,接口的实现类在初始化时也一样不会执行接口的< clinit >() 方法。
- 虚拟机会保证一个类的< clinit >() 方法在多线程环境中被正确地加锁和同步,如果有多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的 < clinit >() 方法,其他线程都需要阻塞等待,知道活动线程执行< clinit >() 方法完毕。如果在一个类的< clinit >() 方法中有耗时很长的操作,那就可能造成多个进程阻塞,在实际应用中这种阻塞往往是很隐蔽的。