Java虚拟机的类加载机制

前言

（仅供秋招复习，了解。）

之前在我的 详解对象的创建，布局，定位，存活判断，介绍了类加载之后的事情。

但是关于类加载机制并没有过多的介绍，先简单介绍一下。

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最
终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

类加载的时机

之前我们介绍到了在我们使用new关键字之后，如果我们类没有符号引用也就是没有被加载的时候就会触发类加载的机制，这算一个类的加载时机，但是加载时机还有很多下面会介绍到。关于我们的类加载过程呢主要是如下图：

（1）加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。并且为支持动态绑定，解析阶段可以在初始化阶段之后再开始。

（2）类加载在什么时候开始可以由虚拟机自己决定。但是呢，针对初始化，我们的《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”。（在此之前的其他操作也需要开始）

• 遇到new、getstatic、putstatic、invokestatic四条字节码指令时，如果没有初始化，则需要先触发初始化阶段。具体场景有：
  • 使用new实例化对象时
  • 读取或设置一个类型的静态字段（除被final修饰放到常量池中的字段）
  • 调用一个类型的静态方法时
• 使用反射包下的方法对类型进行反射调用时，如未初始化，则先初始化。
• 类初始化时，如父类未初始化，则先初始化父类。
• 虚拟机启动时，先初始化main函数所在的类。
• 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解
  析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。（这里了解即可）
• JDK8种如果接口使用了default关键字进行修饰，那么实现接口的类初始化的时候要先初始化接口。

主动引用与被动引用

上面我们介绍到了六种方法，这六个方法的行为称为对一个类型进行主动引用。除了这些，所有引用类型的方法都不会触发初始化，称为被动引用。

关于被动引用的情况有如下：

• 通过子类引用父类的静态字段，不会导致子类初始化。
• 通过数组定义来引用类，不会触发此类的初始化。
• 常量在编译阶段存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此也不会触发定义的类的初始化。这里在上面也提到了，被static修饰但是没有被final修饰会触发主动引用，但是都被修饰只能算是被动引用。

类加载的过程

加载

类加载过程的第一步，主要完成下面3件事情：

1. 通过全类名获取定义此类的二进制字节流（并没有规定从哪里获取二进制流，所以可以从ZIP压缩文件中获取（JAR、WAR的基础）、网络中获取（applet的基础）、运行时计算（动态代理技术）、从其他文件生成（JSP）））。
2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构。
3. 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口。

一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。

验证

确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。主要有如下验证：

1. 文件格式验证，验证是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

2. 元数据验证，对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。

3. 字节码验证,通过数据流和控制流分析，确定程序语义是否合法、符合逻辑。

4. 符合引用验证，是对类自身以外的信息进行匹配性校验(常量池中各种符合引用)。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。但是也需要注意的是：实例变量不会在这阶段分配内存，它会在对象实例化时随着对象一起被分配在堆中。应该注意到，实例化不是类加载的一个过程，类加载发生在所有实例化操作之前，并且类加载只进行一次，实例化可以进行多次。

初始值一般为 0 值，例如下面的类变量 value 被初始化为 0 而不是 123。只有在被实例化的时候才会赋值123。

public static int value = 123;

如果类变量是常量，那么它将初始化为表达式所定义的值而不是 0。例如下面的常量 value 被初始化为 123 而不是 0。

public static final int value = 123;

基本类型的初始值如下：

解析

该阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。

• 符号引用就是一组符号来描述目标，可以是任何字面量。
• 直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

在程序实际运行时，只有符号引用是不够的，举个例子：在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方发表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。

初始化

初始化阶段就是执行类构造器<clinit>()方法的过程。这个方法不是我们在Java代码中去编写，而且Javac编译器的自动生成物，但是我们有必要去了解。

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

public class Test {
	static {
		i = 0; // 给变量复制可以正常编译通过
		System.out.print(i); // 这句编译器会提示“非法向前引用”
	}
	static int i = 1;
}

（2）<clinit>()与类构造方法init()方法不同，虚拟机会保证在子类的<clinit>()执行前，父类的已经执行完毕。所以，Object类的<clinit>()方法一定是最先执行的。这也意味着，父类的静态语句块要优先与子类的变量赋值操作。

（3）<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

（4）接口中的<clinit>()执行前不需要先执行父类的<clinit>()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也 一样不会执行接口的<clinit>()方法。

（5）Java虚拟机必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行完毕<clinit>()方法。如果在一个类的<clinit>()方法中有耗时很长的操作，那就可能造成多个进程阻塞。

卸载

(该部分知识点参考Github高星：《JavaGuide》)

卸载类即该类的Class对象被GC。

卸载类需要满足3个要求:

1. 该类的所有的实例对象都已被GC，也就是说堆不存在该类的实例对象。
2. 该类没有在其他任何地方被引用
3. 该类的类加载器的实例已被GC

所以，在JVM生命周期类，由jvm自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。

只要想通一点就好了，jdk自带的BootstrapClassLoader,PlatformClassLoader,AppClassLoader负责加载jdk提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。

类加载器与双亲委派模型

类加载介绍

（1）BootstrapClassLoader（启动类加载器）

在jdk的rt.jar包下面，是所有类加载器的父类，c++编写的。涉及到虚拟机的具体实现无法引用到，这也就是我们上面为什么null的原因了。

（2）ExtClassLoader （标准扩展类加载器）

负责加载Java的扩展类库，也就是从jre/lib/ext目录下或者java.ext.dirs系统属性指定的目录下加载类。

（3）AppClassLoader（系统类加载器）

负责加载加载应用程序的主函数类。

（4）CustomClassLoader（用户自定义类加载器）

顾名思义，是用户自己编写的类加载器，用来加载指定路径下面的类。

双亲委派模型

每一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工作的时候会默认使用 双亲委派模型 。不考虑自定义的类加载器，我们首先会在加载AppClassLoader,如果加载过了，则不加载，如果没有加载，则委派给了ExtClassLoader ，到了这里，也会同样进行判断，如果没有被加载的话，则会被委派给了BootstrapClassLoader。在启动类类加载器这里，如果被加载过的话，就不加载了，如果没有的话但是可以加载，就进行加载了，如果不可以加载就反馈给了子加载器，一直到系统类加载器。

具体流程可以参考示意图：

常见问题分析

（1）为什么需要双亲委派模型？有什么好处？

1. 防止重复加载同一个.class，稳定运行。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全和Java程序的稳定运行。
2. 保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。

（2）什么是双亲委派模型的破坏？怎么破坏？

双亲委派模型的破坏指的是不按照双亲委派模型来加载类，历史上就出现了三次比较重大的破坏，详细的可以去了解一下（点击跳转）。在自定义类加载器的时候也可以进行破坏。自定义加载器的话，需要继承 ClassLoader 。如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法。

参考资料

《深入理解Java虚拟机3》