Java虚拟机学习笔记-虚拟机类加载机制总结

写在前面

  记录Java虚拟机中,类加载的时机、生命周期以及类加载过程各个阶段的动作和类加载器。


类加载时机

  类从被加载到虚拟机内存中开始,到卸载出内存为止,整个生命周期包括:加载、验证、准备、解析、初始化、使用、卸载。其中,验证、准备、解析3个部分统称为连接。

  加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的。

  Java虚拟机规范中没有强制约束在什么时机开始类加载过程的第一个阶段,但是对于初始化阶段,虚拟机规范则严格规定了有且仅有5种情况必须立即对类进行初始化,对比上一条,可以知道加载、验证、准备需要在初始化之前执行。

摘自书:

  1. 遇到new(创建类实例指令)、getstatic(获取类变量)、putstatic(设置类变量)或invokestatic(调用类方法)这4条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。
  2. 使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行初始化,则需要先触发其初始化。
  3. 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
  4. 当虚拟机启动时,用户需要指定一个主类,虚拟机会先初始化这个主类。
  5. 当使用JDK 1.7的动态语言时,如果一个 java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。

  这5种场景中的行为称为对一个类的主动引用。所有引用类的方式都不会触发初始化,称为被动引用。被动引用主要有以下三种情况:

  1. 通过子类引用父类的静态字段,不会导致子类初始化。
  2. 通过数组定义来引用类,不会触发此类的初始化。
  3. 某类中定义常量,调用类调用常量,不会触发定义常量的类的初始化,因为常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化。

类加载过程

  Java虚拟机中类加载的全过程,是加载、验证、准备、解析、初始化这5个阶段所执行的具体动作。

加载

在加载阶段,虚拟机需要完成以下三件事情:

  1. 通过一个类的全限定名来获取定义此类的二进制字节流。
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
  3. 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口。

连接/链接

验证

  验证是连接阶段的第一步,目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。验证阶段主要分为4个阶段:

  1. 文件格式验证:验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。比如:是否以0xCAFEBABE开头、主次版本是否在当前虚拟机处理范围之内等。
  2. 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求。比如:这个类是否有父类(除了java.lang.Object)、父类是否继承了不允许被继承的类等。
  3. 字节码验证:最复杂的阶段,主要目的是通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。元数据验证校验完后,字节码验证阶段将对类的方法进行校验分析,保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。比如:保证任意时刻操作数栈的数据类型与指令代码序列能配合工作,不过出现在操作数栈放置一个int类型数据,使用时却按long类型来加载入本地变量表中。
  4. 符号引用验证:该阶段发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三阶段,也就是解析阶段发生。符号引用验证看做是对类自身以外的信息进行匹配性校验。比如:符号引用中通过字符串描述的全限定名是否能找到对应的类等。

准备

  准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量的内存所使用的内存都将在方法区中进行分配。该阶段进行内存分配的仅包括类变量,不包括实例变量。初始值在“通常情况”下是数据类型的零值。比如:

1
public static int value = 123;

  变量value在准备阶段过后的初始值为0,而不是123。

  在“特殊情况”下,如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量value会被初始化为ConstantValue属性所指定的值。

1
public static final int value = 123;

  准备阶段过后,value的值即为123。


解析

  解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

  • 符号引用:以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局各不相同。但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
  • 直接引用:可以是直接指向目标的指针、相对偏移量或是一个能直接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在内存中存在。

  解析阶段主要分为对类或接口的解析、字段解析、类方法解析和接口方法解析。


初始化

  类初始化阶段是类加载过程的最后一步,该阶段才真正开始执行类中定义的Java程序代码。在准备阶段,已经对类变量赋值过一次系统要求的初始值,而在初始化阶段,则根据程序员通过程序制定的主观计划去初始化变量和其他资源。从另一个角度来表达:初始化阶段是执行类构造器<clint>()方法的过程。

  <clint>()是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问。

  <clint>()方法与类的构造方法不同,它不需要显示调用父类构造器,虚拟机会保证在子类的<clint>()方法执行之前,已经执行完毕父类的<clint>()方法。

  由于父类的<clint>()方法先执行,所以父类的静态语句块要优先于子类的变量赋值操作。

  <clint>()方法对与类或接口来说不是必需的,如果类中没有静态语句块,也就没有了<clint>()方法。

  接口中不能使用静态语句块,但仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clint>()方法。但接口与类不同,执行接口的<clint>()方法不需要先执行父接口的<clint>()方法。只有当父接口中定义的变量使用时,父接口才会初始化。接口的实现类在初始化时也一样不会执行父接口的<clint>()方法。

  虚拟机会保证一个类的<clint>()方法在多线程环境中被正确地加锁、同步,多个线程同时去初始化一个类,只会有一个线程执行这个类的<clint>()方法,其他线程阻塞等待,知道<clint>()方法执行完毕。需要注意的是,执行完毕<clint>()方法后,其他线程唤醒之后不会再次进入<clint>()方法。同一个类加载器下,一个类型只会初始化一次。


类加载器

  虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

  确定一个类的唯一性:需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。比较两个类是否“相等”,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个Class文件,被同一个虚拟机加载,只要加载它们的类加载器不同,那么这两个类就必定不相等。这里所说的“相等”,包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果,也包括instanceof关键字做对象所属关系判定等情况。

双亲委派模型

  在Java虚拟机的角度来讲,只存在两种不同的类加载器:一种是启动类加载器,使用C++语言实现(只限于HotSpot),是虚拟机自身的一部分;另一种就是所有其他的类加载器,使用Java语言实现,独立于虚拟机之外,全部继承自抽象类java.lang.ClassLoader。

  具体的类加载器可以划分为以下三种系统提供的类加载器:

  • 启动类加载器(Bootstrap ClassLoader):负责将存放在<JAVA_HOME>\lib目录中,或者被-Xbootclasspath参数所指定的路径中的,并且被虚拟机识别的类库加载到虚拟机内存中。
  • 扩展类加载器(Extension ClassLoader):由sun.misc.Launcher$ExtClassLoader实现,负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库。开发者可以直接使用这个类加载器。
  • 应用程序加载器(Application ClassLoader):由sun.misc.Launcher$AppClassLoader实现。一般称它为系统类加载器。负责加载用户类路径(ClassPath)上所指定的类库。开发者可以直接使用这个类加载器。如果程序中没有定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

  如果有必要,还可以加入自己定义的类加载器。这些类加载器之间的关系一般如下图所示:

  类加载器之间的这种层次关系,称为类加载器的双亲委派模型(Parents Delegation Model)。

  双亲委派模型的工程过程如下:

如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。

  为什么使用双亲委派模型呢?

Java类随着它的类加载器一起具备了一种带有优先级的层次关系。比如一个基础类,java.lang.Object,只能由处于最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。如果没有使用双亲委派模型,由各个类加载器自行去加载的话,系统中会出现多个不同的Object类,应用程序会一片混乱。

  至于怎么实现一个双亲委派模型,在类加载器的loadClass方法之中已经实现,代码摘自JDK 1.8,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}

if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);

// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}

  我们可以看到代码中的主要逻辑是:先检查是否已经被加载过,若没有加载则调用父加载器的loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败,抛出ClassNotFoundException异常后,再调用自己的findClass()方法进行加载。


实现自定义类加载器

  在JDK 1.2之后不提倡用户再去覆盖loadClass()方法,而应当把自己的类加载逻辑写到findClass()中,在loadClass()方法的逻辑里如果父类加载失败,则会调用自己的findClass()方法来完成加载,这样可以保证新写出来的类加载器符合双亲委派模型的。

  以下实现的过程参考自Java自定义类加载器与双亲委派模型

  首先我们定义一个Test.java

1
2
3
4
5
6
7
8
package cn.howieli.offer.test;

public class Test {
public void hello() {
System.out.println("恩,是的,我是由 " + getClass().getClassLoader().getClass()
+ " 加载进来的");
}
}

  这边需要注意一点:如果你是直接在当前项目里面创建,待Test.java编译后,请把Test.class文件拷贝走,再将Test.java删除。因为如果Test.class存放在当前项目中,根据双亲委派模型可知,会通过sun.misc.Launcher$AppClassLoader 类加载器加载。为了让我们自定义的类加载器加载,我们把Test.class文件放入到其他目录。

  我将Test.class放到如下位置:

  接着实现我们的自定义类加载器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package cn.howieli.offer.test;

import java.io.FileInputStream;
import java.lang.reflect.Method;

public class MyClassLoader extends ClassLoader {
private String classPath;

public MyClassLoader(String classPath) {
this.classPath = classPath;
}

private byte[] loadByte(String name) throws Exception {
name = name.replaceAll("\\.", "/");
FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
int len = fis.available(); //返回实际可读字节数
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
return defineClass(name, data, 0, data.length);
} catch (Exception e) {
e.printStackTrace();
throw new ClassNotFoundException();
}
}

public static void main(String[] args) throws Exception {
MyClassLoader classLoader = new MyClassLoader("/home/howieli");
Class clazz = classLoader.loadClass("cn.howieli.offer.test.Test");
Object obj = clazz.newInstance();
Method helloMethod = clazz.getDeclaredMethod("hello", null);
helloMethod.invoke(obj, null);
}
}

执行结果:

1
恩,是的,我是由 class cn.howieli.offer.test.MyClassLoader 加载进来的

小结

  感觉完全在抄书,哈哈。


参考资料

Author: HowieLi
Link: https://www.howieli.cn/posts/jvm-class-load-mechanism.html
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.