[JAVA] JVM 类加载机制

Mar 07 2020

本文大量参考(搬运)周志明的《深入理解 Java 虚拟机》

类加载的生命周期

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载(Loading)、验证(Verification)、准备(preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称为连接(Linking)。

类加载的生命周期

在这七个阶段中，加载、验证、准备、初始化和卸载这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持 Java 语言的运行时绑定(也称为动态绑定或晚期绑定)。注意这几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

类加载的时机

对于第一个加载阶段《Java 虚拟机规范》没有进行约束，但对于初始化阶段严格规定了有且只有六种情况必须立即对类进行初始化(而加载、验证、准备需要在此之前开始):

遇到 new、getstatic、putstatic 或 invokestatic 这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。
使用 java.lang.reflect 包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化。
当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类(包含 main() 方法的那个类)，虚拟机会先初始化这个主类。
当使用动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic、REF_p utStatic、REF_invokeStatic、REF_newInvokeSpecial 四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
当一个接口中定义了默认方法时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

类加载的过程

下面讲解加载、验证、准备、解析和初始化这五个阶段所执行的具体动作。

加载

在加载阶段，JVM 需要完成以下三件事情:

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

获取这个”二进制字节流”的方式比较典型的有以下几种：

本地直接加载。
从 zip、jar、war 等压缩文件中加载。
从网络中加载，例如 Web Applet。
运行时计算生成，这种场景使用最多的就是动态代理。
由其他文件生成，如 jsp。
从专用数据库里读取。
从加密文件中读取，这是典型的防 Class 文件反编译的保护措施。

相对于类加载过程的其他阶段，非数组类型的加载阶段(准确地说，是加载阶段中获取类的二进制字节流的动作)是开发人员可控性最强的阶段。加载阶段既可以使用 JVM 里内置的引导类加载器来完成，也可以使用用户自定义的类加载器。

对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由 JVM 直接在内存中动态构造出来的。不过数组类的元素类型(Element Type，指的是数组去掉所有维度的类型)最终还是要靠类加载器来完成加载。

加载阶段结束后，JVM 外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了。之后会在 Java 堆内存中实例化一个 java.lang.Class 类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

验证

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的约束要求，并且不会危害虚拟机自身的安全。验证阶段大致上会完成下面四个阶段的检验动作:

文件格式验证 验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理，如魔数、版本号等。
元数据验证 主要是对类的元数据信息进行语义校验，以保证其符合《Java语言规范》的要求。
字节码验证 最复杂的一个阶段，主要通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑。
符号引用验证 对类自身以外(常量池中的各种符号引用)的各类信息进行匹配性校验。(这个验证发生在符号引用转化为直接引用的时候，而转化是发生在连接的解析阶段)

验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但却不是必须要执行的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运行期没有任何影响了。如果代码已经被反复使用和验证过，就可以考虑使用 -Xverify :none 参数来关闭大部分的类验证，以缩短虚拟机类加载的时间。

准备

准备阶段为类的静态变量（static 字段）分配内存，并设置其默认零值（未被真正初始化）。例如 public static int value = 123; 类变量 value 准备阶段过后的初始值为 0，而不是 123。以下为所有基本数据类型的零值：

数据类型	零值	数据类型	零值
`int`	`0`	`boolean`	`false`
`long`	`0L`	`float`	`0.0f`
`short`	`(short) 0`	`double`	`0.0d`
`char`	`'\u0000'`	`reference`	`null`
`byte`	`(byte) 0`

不过需要注意的是，对于同时被 static 和 final 修饰的常量，如 public static final int value = 123; 准备阶段就会直接初始化其指定的值为初始值，也就是 123，而不是 0 了。

解析

解析阶段是 JVM 将常量池内的符号引用转换为直接引用，确保类之间的链接关系。

符号引用 符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。
直接引用 直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。

主要操作：

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

初始化

初始化类加载过程(类加载过程不是类加载的整个生命周期)中的最后一个阶段，也是真正执行类中定义的 Java 代码(即静态初始化块)的过程，主要完成对类变量的初始化。

初始化阶段就是执行类构造器 <clinit>() 方法的过程，<clinit>() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并产生的。<clinit>() 方法与类的构造函数不同，它不需要显式地调用父类的构造器，JVM 会保证在子类的 <clinit>() 方法执行前，父类的<clinit>() 方法已经执行完毕。

类加载器

类加载器虽然只用于实现类的加载动作，但它在 Java 程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在 JVM 中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。也就是说，比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class 文件，被同一个 JVM 加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

如以下代码，不同的类加载器对 instanceof 关键字运算的结果的影响：

public class ClassLoaderTest {
  public static void main(String[] args) throws Exception {
    ClassLoader myLoader = new ClassLoader() { 
      @Override
      public Class<?> loadClass(String name) throws ClassNotFoundException { 
        try {
          String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class"; 
          InputStream is = getClass().getResourceAsStream(fileName);
          if (is == null) {
            return super.loadClass(name); 
          }
          byte[] b = new byte[is.available()];
          is.read(b);
          return defineClass(name, b, 0, b.length);
        } catch (IOException e) {
          throw new ClassNotFoundException(name);
        }
      }
    };
    Object obj = myLoader.loadClass("org.fenixsoft.classloading.ClassLoaderTest").newInstance();
    System.out.println(obj.getClass());
    System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest); 
  }
}

运行结果：

class org.fenixsoft.classloading.ClassLoaderTest 
false

双亲委派

站在 JVM 的角度来看，只存在两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由 Java 语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

站在 Java 开发人员的角度来看，类加载器就应当划分得更细致一些。自 JDK 1.2 以来，Java 一直保持着三层类加载器、双亲委派的类加载架构，尽管这套架构在 Java 模块化系统出现后有了一些调整变动，但依然未改变其主体结构。

启动类加载器(Bootstrap Class Loader)
这个类加载器负责加载存放在 <JAVA_HOME>\lib 目录，或者被 -Xbootclasspath 参数所指定的路径中存放的，而且是 JVM 能够识别的（按照文件名识别，如rt。jar、tools。jar，名字不符合的类库即使放在 lib 目录中也不会被加载）类库加载到虚拟机的内存中。启动类加载器无法被 Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用 null 代替即可。
扩展类加载器(Extension Class Loader)
这个类加载器是在类 sun.misc.Launcher$ExtClassLoader 中以 Java 代码的形式实现的。它负责加载 <JAVA_HOME>/lib/ext 目录中，或者被 java.ext.dirs 系统变量所指定的路径中所有的类库。根据“扩展类加载器”这个名称，就可以推断出这是一种 Java 系统类库的扩展机制，JDK 的开发团队允许用户将具有通用性的类库放置在 ext 目录里以扩展 Java SE 的功能，在 JDK 9 之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由 Java 代码实现的，开发者可以直接使用扩展类加载器来加载 Class 文件。
应用程序类加载器(Application Class Loader)
这个类加载器由 sun.misc.Launcher$AppClassLoader 来实现。由于应用程序类加载器是 ClassLoader 类中的 getSystemClassLoader() 方法的返回值，所以也称它为“系统类加载器”。它负责加载用户类路径 (ClassPath)上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派

双亲委派模型(Parents Delegation Model)要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承(Inheritance)的关系来实现的，而是通常使用组合(Composition)关系来复用父加载器的代码。

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

这样做的好处是 Java 中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.langObject，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为 java.lang.Object 的类，并放在程序的 ClassPath 中，那系统中就会出现多个不同的 Object 类，Java 类型体系中最基础的行为也就无从保证，程序将会变得一片混乱。

双亲委派模型对于保证 Java 程序的稳定运作极为重要，但它的实现却异常简单，用以实现双亲委派的代码只有短短十余行，全部集中在 java.lang.ClassLoader$loadClass() 方法之中，如下代码：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
  // 首先，检查请求的类是否已经被加载过了 
  Class c = findLoadedClass(name); 
  if (c == null) {
    try {
      if (parent != null) {
        c = parent.loadClass(name, false);
      } else {
        c = findBootstrapClassOrNull(name); 
      }
    } catch (ClassNotFoundException e) {
      // 如果父类加载器抛出ClassNotFoundException 
      // 说明父类加载器无法完成加载请求
    }
    if (c == null) {
      // 在父类加载器无法加载时
      // 再调用本身的findClass方法来进行类加载 
      c = findClass(name);
    } 
  }
  if (resolve) { 
    resolveClass(c);
  }
  
  return c; 
}

破环双亲委派

双亲委派模型并不是一个具有强制性约束的模型，而是 Java 设计者推荐给开发者们的类加载器实现方式。在 Java 的世界中大部分的类加载器都遵循这个模型，但也有例外的情况。

一个典型的例子便是 JNDI 服务，JNDI 现在已经是 Java 的标准服务，它的代码由启动类加载器来完成加载(在 JDK 1.3 时加入到 rt.jar 的)，肯定属于 Java 中很基础的类型了。但 JNDI 存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的 ClassPath 下的 JNDI 服务提供者接口(Service Provider Interface，SPI)的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，为了解决这个问题，Java 的设计团队只好引入了一个不太优雅的设计: 线程上下文类加载器 (Thread Context ClassLoader)。这个类加载器可以通过 java.lang.Thread 类的 setContextClassLoader() 方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

还有就是对程序动态性的追求，如代码热替换(Hot Swap)、模块热部署(Hot Deployment)等。代表技术有 Sun/Oracle 公司的 Jigsaw，和 IBM 公司主导的 JSR-291(即OSGi R4.2)。

模块化下的类加载器（JDK 9 之后）

为了保证兼容性，JDK 9 并没有从根本上动摇从 JDK 1.2 以来运行了二十年之久的三层类加载器架构以及双亲委派模型。但是为了模块化系统的顺利施行，模块化下的类加载器仍然发生了一些应该被注意到的变动，主要包括以下几个方面。

首先，是扩展类加载器(Extension Class Loader)被平台类加载器(Platform Class Loader)取代。既然整个 JDK 都基于模块化进行构建(原来的 rt.jar 和 tools.jar 被拆分成数十个 JMOD 文件)，其中的 Java 类库就已天然地满足了可扩展的需求，那自然无须再保 <JAVA_HOME>\lib\ext 目录，此前使用这个目录或者 java.ext.dirs 系统变量来扩展 JDK 功能的机制已经没有继续存在的价值了，用来加载这部分类库的扩展类加载器也完成了它的历史使命。类似地，JDK 中也取消了 <JAVA_HOME>\jre 目录，因为随时可以组合构建出程序运行所需的 JRE 来，譬如假设我们只使用 java.base 模块中的类型，那么随时可以通过以下命令打包出一个“JRE”:

jlink -p $JAVA_HOME/jmods --add-modules java.base --output jre

其次，平台类加载器和应用程序类加载器都不再派生自 java.net.URLClassLoader，如果有程序直接依赖了这种继承关系，或者依赖 URLClassLoader 类的特定方法，那代码很可能会在 JDK 9 及更高版本的 JDK 中崩溃。现在启动类加载器、平台类加载器、应用程序类加载器全都继承于 jdk.internal.loader.BuiltinClassLoader，在 BuiltinClassLoader 中实现了新的模块化架构下类如何从模块中加载的逻辑，以及模块中资源可访问性的处理。

另外，启动类加载器现在是在 JVM 内部和 Java 类库共同协作实现的类加载器，尽管有了 BootClassLoader 这样的 Java 类，但了与之前的代码保持兼容，所有在获取启动类加载器的场景（譬如 Object.class.getClassLoader()）中仍然会返回 null 来代替，而不会得到 BootClassLoader 的实例。

最后，JDK 9 中虽然仍然维持着三层类加载器和双亲委派的架构，但类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。

JDK 9 后的类加载器委派关系