java虚拟机之类加载机制

注：文中所说的 Class 文件并不是特指存在于具体磁盘中的文件，而是一串二进制字节流，无论是以何种形式存在的都可以。

1. 引言

java 类被虚拟机编译之后成为一个 Class 的字节码文件，该字节码文件中包含各种描述信息，最终都需要加载到虚拟机中之后才能运行和使用。那么虚拟机是如何加载这些 Class 文件？Class 文件中的信息进入虚拟机之后会发生什么变化？接下来我们一个一个探讨。

2. 类加载的时机

类的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、准备、解析 3 个部分统称为连接。

在上图中，加载、验证、准备、初始化和卸载这 5 个阶段的顺序是确定的，类的加载过程必须按照这个过程按部就班的开始，中间可以再插入另一个类的加载过程。那么，什么情况下需要开始类加载过程的第一个阶段呢？虚拟机规范严格规定了有且只有 5 种情况必须立即对类进行「初始化」。

• 遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时，如果类没有初始化，则需要先触发其初始化。生成这 4 条指令的最常见的 java 代码场景是：使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段（被 final、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法时。
• 使用 java.lang.reflec 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
• 当初始化一个类的时候，如果发现父类没有初始化过，则需要先触发其父类的初始化
• 当虚拟机启动时，用户需要指定一个执行的类（包含 main 方法的那个类），虚拟机会先初始化这个主类
• 当使用 JDK1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例后的解析结果 REF_getStatic、REF_pubStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先初始化这个类。（这一点还不理解是什么）

3. 类加载过程

了解了类是什么时候开始加载之后，我们来了解一下类加载的全过程。也就是加载、验证、准备、解析和初始化这个 5 个阶段的具体动作。

3.1 加载

注 ：「加载」是「类加载」过程的一个阶段，在加载阶段，虚拟机需要完成下面 3 件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流，其中，类的全限定名可 多个以从途径获得，例如 ZIP 包、网络、动态代理等等。
2. 将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

3.2 验证

在加载阶段中，Class 文件并不一定要求用 java 源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生 Class 文件。因此，为了保证虚拟机的安全，验证阶段是非常有必要的，验证阶段的工作量在虚拟机的类加载子系统中占了相当大的一部分。其大致会完成下面 4 个阶段的检验动作。

• 文件格式验证
• 元数据验证，即文件描述信息是否符合 java 的语法规则，主要验证类的数据类型是否正确，例如这个类是否有父类，该类的父类是否继承了不允许被继承的类等等。
• 字节码验证，这个验证过程主要是针对类的方法体，保证被检验的类方法不会做出危害虚拟机的事。
• 符号引用验证，判断该类中引用的类信息能否访问，或者有权访问（更具 private、protected 修饰符访问）。

3.3 准备

准备阶段是正式为 类变量 分配内存并设置类变量初始化的阶段，这些变量所使用的内存都将在方法区中进行分配。

这里需要注意两点，首先，这个阶段初始化的变量是类变量，即 static 修饰的变量，不包括实例变量。实例变量将会在对象初始化时随对象一起分配到 java 堆中。其次，这里的初始化「通常情况」下是数据类型的 零值，例如一个变量 public static int value = 123，其先初始化为 0，等到这个类首次被初始化之后才变为 123。

上面说了通常情况下是那样，当然也存在一些「不通常的情况」，例如public static final int value = 123。final 修饰的变量在此阶段就会生产对应的值。

3.4 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。其完成的任务是验证阶段的符号引用验证。主要由下面 4 种解析过程

• 类或接口解析
• 字段解析
• 类方法解析
• 接口方法解析

3.5 初始化

在准备阶段，主要是对类变量进行赋值（一般类型赋为 0，boolean 赋为 false 等等），而初始化阶段是初始化类变量和其他资源，这是执行 类构造器<clinit>() 方法的过程。下面介绍一些可能会影响到程序运行行为的特点和细节：

• <clinit>() 方法收集类变量的赋值动作和执行静态语句块的语句。静态语句块只能为定义在语句块后面的变量赋值，但是不能访问定义在语句块后面的变量。例如

public class Test{
	static{
		i = 0;                 // 给变量赋值可以正常编译通过
		System.out.println(i); // 这句编译器会提示「非法向前引用」
	}

	static int i = 1;
}

• <clinit>() 方法与类的构造函数不同，它不需要显示地调用父类构造函数，虚拟机保证子类的 <clinit>() 方法执行之前，父类的 <clinit>() 已经执行完毕。因此，第一个在虚拟机中被执行 <clinit>() 方法的类一定是 java.lang.Object。
• 由于父类的 <clinit>() 方法先执行，因此父类定义的静态语句块要先于子类的静态语句块。
• 虚拟机会保证一个类的<clinit>() 方法在多线程的环境中被正确的加锁、同步，如果多个线程同时初始化一个类，刚好这个类的<clinit>() 方法耗时很长的操作，就可能造成多个进程的阻塞。例如

static class DeadLoadClass{
	static{
		if(true){
			System.out.println(Thread.currentThread()+"init DeadLoopClass");
			while(true){}
		}
	}
}

public static void main(String[] args){
	Runnable srcipt = new Runnable(){
		public void run(){
			System.out.println(Thread.currentThread()+"start");
			DeadLoadClass dlc = DeadLoadClass();
			System.out.println(Thread.currentThread()+"run over");
		}
	};
	Thread t1 = new Thead(script);
	Thread t2 = new Thead(script);
	t1.start();
	t2.start();
}

运行结果如下，即一个线程在死循环中长时间操作，另一个线程发生阻塞，一直等待。

Thread[Thread-0,5,main]start
Thread[Thread-1,5,main]start
Thread[Thread-0,5,main]init DeadLoopClass

4. 类加载器

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

4.1 类与类加载器

类加载器在 java 程序中起到的作用远远不限于类的加载阶段。在运行阶段，比较两个类是否「相等」，只有在这两个类来源于用一个 Class 文件，被同一个虚拟机加载，并且使同一个类加载器加载，这两个类才会相等。

这里所指的「相等」，包括代表类的 Class 对象的 equals 方法、isAssignableFrom方法、isInstance 方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。

4.2 双亲委派模型

绝大部分 java 程序都会使用到以下 3 种系统提供的类加载器

• 启动类加载器：这个类加载器负责将存放在 <JAVA_HOME>lib 目录中的类库加载到虚拟机内存中。
• 扩展类加载器：这个加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载 <JAVA_HOME>libext 目录中，或被 java.ext.dirs 系统变量所指定的所有类库。
• 应用程序类加载器：这个类库加载器由 sun.misc.Launcher$AppClassLoader 实现，它负责加载用户路径上（ClassPath）所指定的类库。如果应用程序中没有自定的类加载器，一般情况下这个就是默认的类加载器。

我们的应用程序都是由这 3 种类加载器相互配合进行加载的，如果有必要，还可以自定义类加载器。这些类加载器之间的关系如下图所示，这种层次关系被称为类加载器的双亲委派模型。

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

双亲委派模型一个显而易见的好处是 java 类随着它的类加载器一起具备了带有优先级的层次关系。当自定义了一个 java.lang.Object 对象，该对象中存在危害程序的代码，但是它并不会被加载，因为 Object 类是由 启动类加载器 加载的，一定程度上保证了程序的安全性。

以上是对虚拟机类加载机制的总结，主要摘自《深入理解java虚拟机》一书。