类的加载过程(生命周期)
类的加载过程(生命周期)
按Java虚拟机规范,从class文件加载到虚拟机内存中的类,再到类从虚拟机内存中卸载,大致要经历7个阶段。我们通常把验证、准备、解析统称为链接。
加载的是哪个?
在Java中分为基本数据类型和引用数据类型,基本类型有虚拟机预定义,而引用数据类型则需要类加载器进行加载。
1.1、第一阶段:加载(Loading)
加载(也称装载),就是把Java类的字节码加载到机器内存中,然后依据字节码构建出Java类的原型-类模板对象。
装载完成的操作
装载阶段,简言之,查找并加载类的二进制数据,生成Class的实例。
在加载类时,Java虚拟机必须完成以下3件事情:
-
通过类的全名,获取类的二进制数据流
-
解析类的二进制数据流为方法区内的数据结构(Java类模板)
-
创建java.lang.Class类的实例,表示该类型。作为方法区这个类的各种数据的访问入口
类模板对象是啥?
所谓类模板对象,其实就是Java类在JVM内存中的一个快照,JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中,这样JVM在运行期便能通过类模板而获取Java类中的任意信息,能够对Java类的成员变量进行遍历,也能进行Java方法的调用。
反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来,则JVM在运行期也无法反射。
字节码二进制流的获取方式
对于类的二进制数据流,虚拟机可以通过多种途径产生或获得。(只要所读取的字节码符合JVM规范即可)
- 虚拟机可能通过文件系统读入一个class后缀的文件
- 读入jar、zip等归档数据包,提取类文件
- 事先存放在数据库中的类的二进制数据
- 使用类似于HTTP之类的协议通过网络进行加载
- 在运行时生成一段Class的二进制信息等
Class实例的位置
类将.class文件加载至元空间(metaspace)后,会在堆中创建一个java.lang.Class对象,用来封装类位于方法区内的数据结构,该Class对象是在加载类的过程中创建的,每个类都对应有一个Class类型的对象。(instanceKlass(对象头中) --> mirror :Class的实例)。
外部可以通过访问代表Order类的Class对象来获取Order的类数据结构。
Class类的构造方法是私有的,只有JVM能够创建。 java.lang.Class实例是访问类型元数据的接口,也是实现反射的关键数据、入口。通过Class类提供的接口,可以获得目标类所关联的.class文件中具体的数据结构:方法、字段等信息。
数组的加载
创建数组类的情况稍微有些特殊,因为数组类本身并不是由类加载器负责创建,而是由JVM在运行时根据需要而直接创建的,但数组的元素类型仍然需要依靠类加载器去创建。创建数组类(下述简称A)的过程:
- 如果数组的元素类型是引用类型,那么就遵循定义的加载过程递归加载和创建数组A的元素类型。
- JVM使用指定的元素类型和数组维度来创建新的数组类。
- 如果数组的元素类型是引用类型,数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
1.2、第二阶段:链接(Linking)
1.2.1、验证(Verification)
当类加载到系统后,就开始链接操作,验证是链接操作的第一步。
它的目的是保证加载的字节码是合法、合理并符合规范的。
验证的步骤比较复杂,实际要验证的项目也很繁多,大体上Java虚拟机需要做以下检査,如图所示。
说明:
验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证,以及符号引用验证等。
-
其中格式验证会和装载阶段一起执行。验证通过之后,类加载器才会成功将类的二进制数据信息加载到方法区中。
-
格式验证之外的验证操作将会在方法区中进行。
1.2.2、准备(Preparation)
简言之,为类的静态变量分配内存,并将其初始化为默认值('0' 值)。
在这个阶段,虚拟机就会为这个类分配相应的内存空间,并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。
⚠️注意:Java并不支持boolean类型,对于boolean类型内部实现是int,由于int的默认值是0,故对应的boolean的默认值就是false。
1.2.3、解析(Resolution)
简言之,将类、接口、字段和方法的符号引用转为直接引用。
1.具体描述:
符号引用就是一些字面量的引用,和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中,通过常量池进行了大量的符号引用。但是在程序实际运行时,只有符号引用是不够的,比如当如下println()方法被调用时,系统需要明确知道该方法的位置。
举例:输出操作System.out.println()对应的字节码:
invokevirtual #24 <java/io/PrintStream.println>
以方法为例,Java虚拟机为每个类都准备了一张方法表,将其所有的方法都列在表中,当需要调用一个类的方法的时候,只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作,符号引用就可以转变为目标方法在类中方法表中的位置,从而使得方法被成功调用。
2.小结:
所谓解析就是将符号引用转为直接引用,也就是得到类、字段、方法在内存中的指针或者偏移量。因此可以说,如果直接引用存在,那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用,不能确定系统中一定存在该结构。
不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中,加载、验证、准备和初始化会按照顺序有条不紊地执行,但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。
1.3、第三阶段:初始化(Initialization)
初始化阶段,简言之,为类的静态变量赋予正确的初始值。(显式初始化)
具体描述:
类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题,那么表示类可以顺利装载到系统中。此时,类才会开始执行Java字节码。(即:到了初始化阶段,才真正开始执行类中定义的 Java 程序代码。)
初始化阶段的重要工作是执行类的初始化方法:<clinit>()方法。
-
该方法仅能由Java编译器生成并由JVM调用,程序开发者无法自定义一个同名的方法,更无法直接在Java程序中调用该方法,虽然该方法也是由字节码指令所组成。
-
它是由类静态成员的赋值语句以及static语句块合并产生的。
其它要点:
-
在加载一个类之前,虚拟机总是会试图加载该类的父类,因此父类的<clinit>总是在子类<clinit>之前被调用。也就是说,父类的static块优先级高于子类。
-
哪些类不会生成<clinit>?
- 一个类中没有申明任何类变量,也没有任何静态代码块。
- 一个类中申明了类变量,但没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作。
- 一个类中包含由static final修饰的基本数据类型的字段,这些类字段初始化语句采用编译时常量表达式(编译期就已经确定了)。
-
<clinit>()调用会出现死锁吗?
-
对于<clinit>()方法的调用,也就是类的初始化,虚拟机会在内部确保其多线程环境中的安全性。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。
正是因为函数<clinit>()带锁线程安全的,因此,如果在一个类的<clinit>()方法中有耗时很长的操作,就可能造成多个线程阻塞,引发死锁。并且这种死锁是很难发现的,因为看起来它们并没有可用的锁信息。
如果之前的线程成功加载了类,则等在队列中的线程就没有机会再执行<clinit>()方法了。那么当需要使用这个类时,虚拟机会直接返回给它已经准备好的信息。
-
类的初始化之主动使用:
Class只有在必须要首次使用的时候才会被装载,Java虚拟机不会无条件地装载Class类型。Java虚拟机规定,一个类或接口在初次使用前,必须要进行初始化。这里指的“使用”,是指主动使用。
主动使用只有下列几种情况:(即:如果出现如下的情况,则会对类进行初始化操作。初始化操作之前的加载、验证、准备已经完成。)
- 当创建一个类的实例时,比如使用new关键字,或者通过反射、克隆、反序列化。
- 当调用类的静态方法时,即当使用了字节码invokestatic指令。
- 当使用类、接口的静态字段时(final修饰特殊考虑),比如,使用getstatic或者putstatic指令。
- 当使用java.lang.reflect包中的方法反射类的方法时。比如:Class.forName("cc.xuhao.jvm.Clzinit")
- 当初始化子类时,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
- 如果一个接口定义了default方法,那么直接实现或者间接实现该接口的类的初始化,该接口要在其之前被初始化。
- 当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类。
- 当初次调用 MethodHandle 实例时,初始化该 MethodHandle 指向的方法所在的类。(涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类)。
类的初始化之被动使用:
除了以上的情况属于主动使用,其他的情况均属于被动使用。被动使用不会引起类的初始化,也就是说并不是在代码中出现的类,就一定会被加载或者初始化。如果不符合主动使用的条件,类就不会初始化。
-
当访问一个静态字段时,只有真正声明这个字段的类才会被初始化,通过子类引用父类的静态变量,不会导致子类初始化。
-
通过数组定义类引用,不会触发此类的初始化(例如
ClassName[] array
,并没有直接使用new
关键字创建类的实例,那么这个类的初始化过程不会被触发)。 -
引用常量不会触发此类或接口的初始化,因为常量在链接阶段就已经被显式赋值了。
-
调用ClassLoader类的loadClass()方法加载一个类,并不是对类的主动使用,不会导致类的初始化。
被动的使用,意味着不需要执行初始化环节,意味着没有<clinit>()的调用。
拓展:
可以通过-XX:+TraceClassLoading
来追踪类加载的信息!
1.4、第四阶段:使用(Using)
任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类成功经历过这3个步骤之后,便可以进行使用了。
开发人员可以在程序中访问和调用它的静态类成员信息(比如:静态字段、静态方法),或者使用new关键字为其创建对象实例。
1.5、第五阶段:类卸载(UnLoading)
类、类加载器、类实例之间的引用关系:
在类加载器的内部实现中,用一个Java集合来存放所加载类的引用。另一方面,一个Class对象总是会引用它的类加载器,调用Class对象的getClassLoader()方法,就能获得它的类加载器。由此可见,代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法,这个方法返回代表对象所属类的Class对象的引用。此外,所有的Java类都有一个静态属性class,它引用代表这个类的Class对象。
如下图:
⚠️注意:只有当上图左侧的3个引用全部置为null,整个Sample类在方法区的信息才会被卸载,卸载后如果再次需要使用需要重新进行类加载。
类的卸载:
- 有引导类加载器加载的类型在整个运行过程中都不允许被卸载。
- 由扩展类加载器和应用类加载器加载的类型在运行过程中基本不可能被卸载,因为这两个类加载器的实例总是能直接或间接的被访问,基本不可能会有不可达的情况。
- 自定义类加载器只有在很简单的上下文环境中才会被卸载,且一般还要强制调用虚拟机的垃圾回收功能(System.gc()等)。稍为复杂的场景也基本不可能被卸载(卸载时间不确定,何时触发GC?)。
总结:可以看出一个类的卸载实属不易的,被卸载的概率很小(卸载的时间不确定)。故在开发过程中,不应该以依赖类型卸载来实现某些应用功能。