深入理解JVM—类加载机制

目录

类加载概述

类的生命周期

类加载过程

加载

验证

准备

解析

初始化

类加载器

双亲委派模型

自定义加载器

Java是一门面向对象的编程语言， Java程序运行过程中无时无刻都有对象被创建出来。 在语言层面上， 创建对象通常（例外： 复制、 反序列化） 仅仅是一个new关键字而已， 而在虚拟机中， 对象（限于普通Java对象，不包括数组和Class对象等）的创建又是怎样一个过程呢？

当Java虚拟机遇到一条字节码new指令时， 首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用， 并且检查这个符号引用代表的类是否已被加载、 解析和初始化过。 如果没有， 那必须先执行相应的类加载过程 。

类加载概述

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。Java虚拟机把描述类的数据从Class文件加载到内存， 并对数据进行校验、 转换解析和初始化， 最终形成可以被虚拟机直接使用的Java类型， 这个过程被称作虚拟机的类加载机制。

在Java语言里面， 类型的加载、 连接和初始化过程都是在程序运行期间完成的， 这种策略让Java语言进行提前编译会面临额外的困难， 也会让类加载时稍微增加一些性能开销，但是却为Java应用提供了极高的扩展性和灵活性， Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

类的生命周期

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

如上图所示，加载、 验证、 准备、 初始化和卸载这五个阶段的顺序是确定的， 类型的加载过程必须按照这种顺序按部就班地开始， 而解析阶段则不一定： 它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性 。另外这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

结束生命周期

在如下几种情况下，Java虚拟机将结束生命周期

• 执行了System.exit()方法
• 程序正常执行结束
• 程序在执行过程中遇到了异常或错误而异常终止
• 由于操作系统出现错误而导致Java虚拟机进程终止

类加载过程

加载

“加载”（Loading） 阶段是整个“类加载”（Class Loading） 过程中的一个阶段。在加载阶段， Java虚拟机需要完成以下三件事情：

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

《Java虚拟机规范》 对这三点要求其实并不是特别具体， 留给虚拟机实现与Java应用的灵活度都是相当大的。相对于类加载过程的其他阶段， 非数组类型的加载阶段（准确地说， 是加载阶段中获取类的二进制字节流的动作） 是开发人员可控性最强的阶段。 加载阶段既可以使用Java虚拟机里内置的引导类加载器来完成， 也可以由用户自定义的类加载器去完成， 开发人员通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的findClass()或loadClass()方法） ， 实现根据自己的想法来赋予应用程序获取运行代码的动态性 。

加载.class文件的方式

• 从本地系统中直接加载
• 通过网络下载.class文件
• 从zip，jar等归档文件中加载.class文件
• 从专有数据库中提取.class文件
• 将Java源文件动态编译为.class文件

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

验证

验证是连接阶段的第一步， 这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》 的全部约束要求， 保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

从整体上看， 验证阶段大致上会完成下面四个阶段的检验动作：

• 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以

  0xCAFEBABE

  开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object 之外。
• 字节码验证：这是整个验证过程中最复杂的一个阶段。通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。这阶段要对类的方法体（Class文件中的Code属性） 进行校验分析， 保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。
• 符号引用验证：该检验发生在虚拟机将符号引用转化为直接引用的时候，查看该类是否缺少或者被禁止访问它依赖的某些外部类、 方法、 字段等资源，目的是确保解析行为能正常执行。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

• 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
• 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
• 如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

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

假设一个类变量的定义为：

public static int value=123；
           

那么变量value在准备阶段过后的初始值为0，而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为3的 public static 指令是在程序编译后，存放于类构造器 <clinit>() 方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。

假设上面的类变量value被定义为：

public static final int value=3；
           

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据 ConstantValue的设置将value赋值为3。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中。

解析

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

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

解析动作主要针对类或接口、 字段、 类方法、 接口方法、 方法类型、 方法句柄和调用点限定符这7类符号引用进行， 分别对应于常量池的CONSTANT_Class_info、 CON-STANT_Fieldref_info、CONSTANT_Methodref_info、 CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、 CONSTANT_MethodHandle_info、 CONSTANT_Dyna-mic_info和CONSTANT_InvokeDynamic_info 8种常量类型。

初始化

类的初始化阶段是类加载过程的最后一个步骤。初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。用另外一种更直接的形式来表达: 初始化阶段就是执行类构造器<clinit>()方法的过程。

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

JVM初始化步骤

1. 假如这个类还没有被加载和连接，则程序先加载并连接该类
2. 假如该类的直接父类还没有被初始化，则先初始化其直接父类
3. 假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机: 只有当对类的主动使用的时候才会导致类的初始化，有且只有六种情况必须立即对类进行“初始化” :

1）遇到new、 getstatic、 putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化， 则需要先触发其初始化阶段。 能够生成这四条指令的典型Java代码场景有：

• 使用new关键字实例化对象的时候。
• 读取或设置一个类型的静态字段（被final修饰、 已在编译期把结果放入常量池的静态字段除外）的时候。
• 调用一个类型的静态方法的时候。

2）使用java.lang.reflect包的方法对类型进行反射调用的时候。

3）当初始化类的时候， 如果发现其父类还没有进行过初始化， 则需要先触发其父类的初始化。

4）当虚拟机启动时， 用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

5）当使用JDK 7新加入的动态语言支持时， 如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、 REF_putStatic、 REF_invokeStatic、 REF_newInvokeSpecial四种类型的方法句柄， 并且这个方法句柄对应的类没有进行过初始化， 则需要先触发其初始化。

6）当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化， 那该接口要在其之前被初始化。

类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性。也就是说，比较两个类是否“相等”， 只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件， 被同一个Java虚拟机加载，只要加载它们的类加载器不同， 那这两个类就必定不相等。

双亲委派模型

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

类加载器可以大致划分为以下三类：

• 启动类加载器:Bootstrap Class Loader，负责加载存放在 <JAVA_HOME>\lib(JDK代表JDK的安装目录，下同)下，或被 -Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被 Bootstrap Class Loader加载）。启动类加载器是无法被Java程序直接引用的。

• 扩展类加载器： Extension Class Loader，这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。 它负责加载<JAVA_HOME>\lib\ext目录中， 或者被java.ext.dirs系统变量所指定的路径中所有的类库。

  开发者可以直接使用扩展类加载器。

• 应用程序类加载器： Application Class Loader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model） ”。 双亲委派模型要求除了顶层的启动类加载器外， 其余的类加载器都应有自己的父类加载器。 不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的， 而是通常使用组合（Composition） 关系来复用父加载器的代码。

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

使用这种模型来组织类加载器之间的关系的好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object类，无论哪个类加载器去加载该类，最终都是由启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。否则的话，如果不使用该模型的话，如果用户自定义一个java.lang.Object类且存放在classpath中，那么系统中将会出现多个Object类，应用程序也会变得很混乱。如果我们自定义一个rt.jar中已有类的同名Java类，会发现JVM可以正常编译，但该类永远无法被加载运行。 在rt.jar包中的java.lang.ClassLoader类中，我们可以查看类加载实现过程的代码，具体源码如下：

protected synchronized Class loadClass(String name, boolean resolve)  
        throws ClassNotFoundException {  
    // 首先检查该name指定的class是否有被加载  
    Class c = findLoadedClass(name);  
    if (c == null) {  
        try {  
            if (parent != null) {  
                // 如果parent不为null，则调用parent的loadClass进行加载  
                c = parent.loadClass(name, false);  
            } else {  
                // parent为null，则调用BootstrapClassLoader进行加载  
                c = findBootstrapClass0(name);  
            }  
        } catch (ClassNotFoundException e) {  
            // 如果仍然无法加载成功，则调用自身的findClass进行加载  
            c = findClass(name);  
        }  
    }  
    if (resolve) {  
        resolveClass(c);  
    }  
    return c;  
}  
           

通过上面代码可以看出，双亲委派模型是通过loadClass()方法来实现的，根据代码以及代码中的注释可以很清楚地了解整个过程其实非常简单：先检查是否已经被加载过，如果没有则调用父加载器的loadClass()方法，如果父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器加载失败，则先抛出ClassNotFoundException，然后再调用自己的findClass()方法进行加载。

自定义加载器

继承 java.lang.ClassLoader 类，重写findClass()方法

如果没有太复杂的需求，可以直接继承URLClassLoader类，重写方法，具体可参考AppClassLoader 和 ExtClassLoader。

获取ClassLoader几种方式

它是一个抽象类，其后所有的类加载器继承自 ClassLoader（不包括启动类加载器）

// 方式一：获取当前类的 ClassLoader
clazz.getClassLoader()
// 方式二：获取当前线程上下文的 ClassLoader
Thread.currentThread().getContextClassLoader()
// 方式三：获取系统的 ClassLoader
ClassLoader.getSystemClassLoader()
// 方式四：获取调用者的 ClassLoader
DriverManager.getCallerClassLoader()