一、概述
我们知道java代码会被编译为.class文件,这里class文件中的类信息最终还是需要jvm加载以后才能使用。
事实上,虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验,转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型的过程就是虚拟机的类加载机制。
对于jvm类的加载机制,我们主要关注两个问题:
- 类的加载时机?(初始化的五种情况)
- 类的加载过程?(类的五个加载过程)
二、类的加载时机
1.类的生命周期
类从被加载到虚拟机内存中开始,到卸载出内存为止,整个生命周期包括加载、验证、准备、解析、初始化、使用和卸载。其中验证、准备、解析统称为连接。
值得一提的是,加载,验证,准备,初始化和卸载是固定的,但是解析阶段不是:它在一定情况下可以在初始化后再开始,以支持java语言的动态绑定。
这里解释一下动态绑定和静态绑定:
静态绑定:
在程序执行前方法已经被绑定(也就是说在编译过程中就已经知道这个方法到底是哪个类中的方法),此时由编译器*或其它连接程序实现。动态绑定:
后期绑定:在运行时根据具体对象的类型进行绑定。
另外,类的加载过程必须按次步骤“开始”,但是并不等前一个步骤完成后才进行下一个步骤,而是在前一个步骤进行时就开始下一个步骤。
2.类的加载时机
我们需要明确一下,这里的“加载”只是类加载过程的一个阶段,代表这“类的加载”的这一过程的开始,jvm并没有强制性约束在什么时候开始类加载过程。
一般我们说类的加载,指的是整个加载过程。过程完成后,代表jvm将java文件编译成class文件后,以二进制流的方式存放到运行时数据的方法区中,并在java的堆中创建一个java.lang.Class对象,用来指向存放在方法堆中的数据结构。
3.类的初始化时机
首先我们得明确一下初始化和实例化的区别:
类的实例化是指创建一个类的实例(对象)的过程;
类的初始化是指为类中各个类成员(被static修饰的成员变量)赋初始值的过程,是类生命周期中的一个阶段。
初始化一般是类使用前的最后一个阶段,所以类初始化时机可以看成类的加载时机。
凡是有以下四种行为的成为对一个类进行主动引用,只有主动引用会触发类的初始化:
-
遇到四条字节码指令:
- new:使用new关键字实例化对象;
- getstatic:获取一个不被final修饰的类的静态字段;
- putstatic:设置一个不被final修饰的类的静态字段;
- invokestatic:调用一个类的静态方法;
- 使用java.lang.reflect包中的方法对类进行反射调用时,如果类还没有初始化,则必须首先对其初始化;
- 当初始化一个类时,如果其父类还没有初始化,则必须首先初始化其父类;
- 当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类。
- 当使用JDK7动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行初始化,则需要先触发其初始化。
除了以上五种方式以外引用类的方式成为被动引用,并不会触发初始化。
被动引用有以下几种代表性的例子:
假设我们有以下两种类:
/**
* @Author:CreateSequence
* @Date:2020-08-08 21:28
* @Description:Parent类
*/
public class Parent {
static int ParentAge = 10;
static {
System.out.println("我是Parent,我被初始化了!");
}
}
/**
* @Author:CreateSequence
* @Date:2020-08-08 21:28
* @Description:Child类
*/
public class Child extends Parent {
public static final int cons = 55;
static {
System.out.println("我是Child,我被初始化了!");
}
}
-
通过子类引用父类的静态字段,不会导致子类初始化;
public static void main( String[] args ) {
System.out.println(Child.ParentAge);
} //输出
我是Parent,我被初始化了!
10 -
通过数组定义引用类不会初始化;
public static void main( String[] args ) {
Parent[] Parent = new Parent[10];
} -
常量在编译阶段会存入调用类的常量池中,本质上并没有引用到定义常量的类,因此不会触发定义常量的类的初始化
public static void main( String[] args ) {
System.out.println(Child.cons);
} //输出
55
三、类的加载过程
1.加载
加载”是由类加载器完成的“类加载过程”的第一个阶段,在初始化之前完成。
加载阶段完成以下三件事:
- 通过一个类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
值得一提的是,二进制流可以从zip包中获取,这也是JAR或者WAR包格式也能部署项目基础。
另外,类的加载阶段涉及类加载器和双亲委派模型等知识点,此处将另起新随笔详细介绍,在本文就不多费笔墨了。
2.验证
验证是连接阶段的第一步,目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。
验证阶段完成以下四件事:
-
文件格式验证:验证字节流是否符合Class文件格式的规范,
比如是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围内、常量池的常量中是否有不被支持的常量类型等等;
-
元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求,
比如父类是否继承了被final修饰的类,非抽象类是否都实现了父类或者接口的方法等等;
字节码验证:通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的;
-
符号引用验证:对类自身以外的信息进行匹配性校验,
比如符号引用中通过字符串描述的全限定名是否能找到对应的类等等。
3.准备
准备阶段是正式为类被static修饰的变量(不包含实例变量)分配内存并设置类变量初始值的阶段。
这里区分常量与普通静态变量:
对于普通静态变量,比如 public staic int num = 1
,准备阶段赋值为0,而把value赋值为123的putstatic指令是程序被编译后,存放于虚拟机装载一个类初始化的时候调用的类构造器方法<clinit>()
之中,所以把value赋值为123的动作将在初始化阶段才会执行。
而对于常量类型,比如 public static final int = 1
,准备阶段就会赋值为1。
4.解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
这里我们需要理解一下符号引用和直接引用:
- 符号引用:以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用目标并不一定已经加载到内存中
- 直接引用:直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄,直接引用与虚拟机实现的内存布局相关,如果有了直接引用,引用目标必定已经加载到内存中
我们举个简单的例子:
最开始jvm要加载People类,但是一开始并不知道People的内存地址,此时就用符号“People”先表示它的地址,等到类加载器加载完People类的时候,就可以知道People类的实际地址了,于是就将“People”符号换成People这个类的实际内存地址。
5.初始化
类初始化阶段是类加载过程的最后一步。在前面的类加载过程中,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其余动作完全由虚拟机主导和控制。到了初始化阶段,才真正开始执行类中定义的java程序代码(字节码)。
这里我们可以回头看准备阶段,我们知道准备阶段会调用
初始化阶段是执行类构造器<clinit>()
方法的过程。<clinit>()
方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的。
编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问。
举个例子:
static {
i = 5;
System.out.println(i);//在此处抛出错误:非法的向前引用
}
public static int i = 0;
四、初始化时代码的执行顺序
我们在类加载的验证和初始化时都提到过类构造器 <clinit>()
,这里我们提出来与实例构造器 <init>()
介绍一下,理解了这两中构造器实际上就理解了初始化时代码的执行顺序。
我们说初始化就是执行类构造器 <clinit>()
的过程,而那么实例化就是执行实例构造器 <init>()
的过程。
类构造器<clinit>()
与实例构造器<init>()
不同,它不需要程序员进行显式调用,虚拟机会保证在子类类构造器<clinit>()
执行之前,父类的类构造<clinit>()
执行完毕。这就导致了父类静态代码块比子类静态代码块先执行。
值得注意的是:
在多线程环境下,虚拟机会保证总是只有一个线程去执行类构造器 <clinit>()
,其他线程会阻塞直到构造器执行完毕。而一个类只会进行一次初始化,这就保证了多线程下类的正确初始化。
事实上,这有点像在我关于多线程的这篇文章中提到的双重检查单例模式,也是因为这点,我们可以巧妙的使用内部类来实现一个线程安全的单例模式。
由于实例化的时候其他线程会阻塞,所以如果在类的静态块中进行了耗时较长的工作时,可能就会导致多个线程在你不知道的情况下堵塞,造成不必要的性能消耗。