深入理解JVM虚拟机(六)：虚拟机类加载机制

1. 概述

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

与那些在编译时需要进行连接工作的语言不同，在Java7语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为Java程序提高高度的灵活性，在Java里面天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。

2. Java虚拟机体系

学习一个东西之前，我们务必要知道，这东西大概是干什么的，有什么作用。为了更清楚的阐释类加载机制到底是干什么的，我先将JVM的结构图贴给大家：

如上图，我们要学的类加载机制就是要搞清楚类加载器是如何找到指定的Class文件以及怎样将Class文件装载进内存，以便执行引擎执行Class文件中存在的数据和指令，从而使你的Java程序跑起来。

2. 类加载的时机

在我们了解虚拟机类加载机制的开始，我们首先来介绍一下类的生命周期。类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接。

上图中，加载、验证、准备、初始化、卸载这个5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的开始，而解析阶段则不一定，它在某种情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或者晚绑定）。

现在我们了解了类的加载过程的生命周期，下面我们需要知道什么时候需要类加载过程？Java虚拟机规范中没有进行强制约束，这一点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

• new一个对象、读取一个类静态字段、调用一个类的静态方法的时候
• 对类进行反射调用的时候
• 初始化一个类，发现父类还没有初始化，则先初始化父类
• 如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

对于这五种情况会触发类进行初始化过程，我们称为主动引用。除此之外，所有引用类的方式都不会触发初始化过程，称为被动引用。下面我们来介绍一下下面3种被动引用的情况：

---

2.1 被动引用案例1：通过子类引用父类的静态字段，不会导致子类初始化

class SuperClass{
    static {
        System.out.println("SuperClass init");
    }

    public static int  value=123;
}

class SubClass extends SuperClass{
    static {
        System.out.println("SubClass init");
    }
}

public class NotInitialization1 {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

运行结果
SuperClass init
123

对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类引用父类中定义的静态字段、只会触发父类的初始化而不会触发子类的初始化。

扫描二维码关注公众号，回复： 4484553 查看本文章

2.2 被动引用案例2：通过数组定义引用类，不会触发此类的初始化

public class NotInitialization2 {
    public static void main(String[] args) {
        SuperClass[] sca=new SuperClass[20];
    }
}

运行结果

这段代码触发了一个名为“[Lcom.basic.java.classloader.SuperClass”的类初始化阶段，对于用于代码来说，这是并不是一个合法的类名称，它是一个由虚拟机自动生成的、直接继承与java.lang.Object的子类，创建动作由字节码newarray触发。这个类元素代表一个com.basic.java.classloader.SuperClass的一维数组，数组中应用的属性和方法都实现在这个类中。

2.3 被动引用案例3：静态常量变量的使用，不会触发类的初始化

class ConstClass{
    static {
        System.out.println("ConstClass init");
    }

    public static final String HELLOWORLD="helloWorld";
}
public class NotInitialization3 {
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLOWORLD);
    }
}

运行结果：
helloWorld

常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发常量的类的初始化。这种调用方式不会触发ConstClass的初始化，因为常量传播优化，常量“hello world”已经被存储到了NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用实际上都被转化为NotInitialization对自身常量池的引用。这种做法其实叫做常量的传播优化。

通过本节知识，我们知道了类会在什么时候进行类加载过程，下面我们详细介绍一下类加载机制的具体细节。

3.类加载的过程

3.1 加载

我们来看在加载阶段，虚拟机需要完成哪些事情：

• 通过一个类的全限定名来获取定义此类的二进制字节流
• 将获取到的二进制字节流转化成一种数据结构并放进方法区
• 在内存中生成一个代表此类的java.lang.Class对象，作为访问方法区中各种数据的接口

过一个类的全限定名来获取定义此类的二进制字节流这一条， 它没有指二进制字节流要从一个Class文件中获取，准确的说是根本没有指明要从哪里获取，怎样获取。虚拟机设计团队在加载阶段搭建了一个非常开放的、广阔的“舞台。我们可以从以下这些地方获得一个类二进制字节流。

• 在ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础
• 从网络中获取，这种常见最典型的应用就是Applet
• 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成形式“*$Proxy”的代理类的二进制字节流
• 由其他文件生成，典型的场景是JSP应用，即由JSP文件生成对应的Class类
• 从数据库中读取，这种场景相对少见一些，例如有些中间件服务器可以选择把程序安装到数据库中来完成程序代码在集群中的分发

在我们了解了类加载阶段，虚拟机完成了哪些事情之后。下面我们介绍一个特殊的类加载过程：对于数组类价值过程：数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的但是数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终是要靠类加载器去创建，一个数组类创建过程就遵循以下规则：

• 如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上表示
• 如果数组的组件类型不是引用类型（如int[]数组），Java虚拟机将会把数据C标记为与启动类加载器关联
• 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式有虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构。然后在内存中实例化一个java.lang.Class类的对象（并没有明确规定是在Java堆中，对于HotSpot虚拟机而言，Class对象比较特殊，它虽然是对象，但是存放在方法区里面），这个对象将作为程序访问方法区中的这些类型数据的外部接口。

3.2 验证

从上面类的生命周期一图中我们可以看出，验证是连接的第一步，这一阶段的目的主要是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，从而不会危害虚拟机自身安全。也就是说，当加载阶段将字节流加载进方法区之后，JVM需要做的第一件事就是对字节流进行安全校验，以保证格式正确，使自己之后能正确的解析到数据并保证这些数据不会对自身造成危害。

验证阶段主要分成四个子阶段：

• 文件格式验证
• 元数据验证
• 字节码验证
• 符号引用验证

3.2.1 文件格式验证

这一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

3.2.2 元数据验证

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下：

• 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）
• 这个类的父类是否继承了不允许被继承的类（被final修饰的类）
• 如果这个类不是抽象类，是否实现了其父类或者接口之中要求实现的所有方法
• 类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等）

第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。

3.2.3 字节码验证

第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件，例如：

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况：在操作栈放置了一个int类型的数据，使用时却按照long类型来家载入本地变量表中
• 保证跳转指令不会跳转到方法体以外的字节码指令上
• 保证方法体重的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系，完全不相干的一个数据类型，则是危险和不合法的

3.2.4 符号引用验证

最后一个阶段的校验发生在虚拟机将符号引用转换为直接引用的时候，这个转化动作将在连接的第三个阶段——解析阶段发生。符号一弄验证可以看做是对类自身以外（常量池的各种符号引用）的信息进行匹配性校验，统称需要校验下列内容：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类
• 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
• 符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可以被当前类访问

3.2.4. 准备阶段（类变量）

1.准备阶段的目的：正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存将在方法区中分配。

注意我的重点：是类变量（static）不是实例变量，还有，我们又知道了在JVM的方法区中不仅存储着Class字节流（按照运行时方法区的数据结构进行存储，上述的二进制字节流是不严谨的说法，只是为了大家好理解），还有我们的类变量。

2.这里的类变量初始值通常是指数据类型的零值。比如int的零值为0，long为0L，boolean为false… …真正的初始化赋值是在初始化阶段进行的。

额外一点，如果你设置的类变量还具有final字段，如下：

public static final int value = 123;

那么在准备阶段变量的初始值就会被直接初始化为123，具体原因是由于拥有final字段的变量在它的字段属性表中会出现ConstantValue属性。

3.2.5 解析阶段

阶段的目的：虚拟机将常量池内的符号引用替换为直接引用。

常量池：在Class的文件结构中我们就花了大量的篇幅去介绍了常量池，我们再来总结一下：常量池(constant pool)指的是在编译期被确定，并被保存在已编译的.class文件中的一些数据。它包括了关于类、方法、接口等中的常量，也包括字符串常量。

看完上面这句话，你可能会有疑问什么事符号引用，什么是直接引用。

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

现在我们对上面那句话进行重新解读：虚拟机将运行时常量池中那些仅代表其他信息的符号引用解析为直接指向所需信息所在地址的指针。

虚拟机规范中并未规定解析阶段发生的具体时间，只要求了在执行anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield和putstatic这16个用于操作符号引用的字节码指令之前，先对他们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。

解析动作主要是有以下执行动作：

• 类或接口的解析（注意数组类和非数组类）
• 字段（简单名称+字段描述符）解析（注意递归搜索）
• 类方法解析（注意递归搜索）
• 接口方法解析（注意递归搜索）

在解析阶段还有一个很有意思的东西：动态连接！

它也是上面解析阶段发生时间不确定的直接原因：大部分JVM的实现都是延迟加载或者叫做动态连接。它的意思就是JVM装载某个类A时，如果类A中有引用其他类B，虚拟机并不会将这个类B也同时装载进JVM内存，而是等到执行的时候才去装载。

而这个被引用的B类在引用它的类A中的表现形式主要被登记在了符号表中，而解析的过程就是当需要用到被引用类B的时候，将引用类B在引用类A的符号引用名改为内存里的直接引用。这就是解析发生时间不可预料的原因，而且这个阶段是发生在方法区中的。

3.2.6 初始化阶段

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义加载类加载器参与外，其余动作完全由虚拟机主导和控制。到了初始化阶段，财政在开始执行类中定义的Java程序代码。

在准备阶段，类变量（静态变量）已经赋过一次系统要求的初始化值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度去表达：初始化阶段是执行类构造器<clinit()>方法执行过程中一些可能会影响程序运行行为的特点和细节，这部分相对更贴近于普通的程序开发人员。我们下面来详细讲解<clinit()>方法是怎么生成的。

• clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，当时不能访问。
• clinit()方法与类的构造器不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的clinit()方法执行之前，父类的clinit()方法已经执行完毕。因此在虚拟机中第一个被执行的clinit()方法的类肯定是java.lang.Object。
• clinit()方法对于类或者接口来说并不是必需的，如果一类中没有静态语句块，也没有对变量的赋值操作，那么编译可以不为这个类生成clinit()方法。
• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成clinit()方法。但是接口与类不同的是，执行接口的clinit()方法不需要先执行父接口的clinit()方法。只有当肤疾克中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始时也一样不会执行接口的clinit()方法。
• 虚拟机会保证一个类的clinit()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的clinit()方法，其他线程都需要阻塞等待，知道活动线程执行clinit()方法完毕。如果在一个类的clinit()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

3.3 利用实例分析类加载过程

咱们来看一个例子将上面类加载的过程来串一下吧，加深一下自己的印象

class Lava {

    private int speed = 5;
    void flow() {

    }
}

public class Volcano {

    public static void main(String[] args) {
        Lava lava = new Lava();
        lava.flow();
    }
}

3.3.1 加载

读取一个类的class文件并将其中的二进制字节流组织成正确的数据结构放进运行时方法区中：

要运行Volcano程序，首先得以某种“依赖于实现的”方式告诉虚拟机“Volcano”这个名字。之后，虚拟机将找到并读入相应的class文件“Volcano.class”，然后它会从导入的class文件里的二进制数据中提取类型信息并放到方法区中。通过执行保存在方法区中的字节码，虚拟机开始执行main()方法，在执行时，它会一直持有指向当前类（Volcano类）的运行时常量池（方法区中的一个数据结构）的指针。

注意：虚拟机开始执行Volcano类中main()方法的字节码的时候，尽管Lava类还没被装载，但是和大多数（也许所有）虚拟机实现一样，它不会等到把程序中用到的所有类都装载后才开始运行。恰好相反，它只会需要时才装载相应的类。（延迟加载、动态连接）

main()的第一条指令告知虚拟机为列在常量池第一项的类分配足够的内存。所以虚拟机使用指向Volcano常量池的指针找到第一项，发现它是一个对com.basic.java.classloader.Lava类的符号引用，然后它就检查方法区，看Lava类是否已经被加载了。

检查方法区，发现Lava类没有加载，这个时候虚拟机开始进行类加载过程。首先是加载阶段，虚拟机开始查找并装载文件“Lava.class”，并把从读入的二进制数据中提取的类型信息放在方法区中。

3.3.2 解析

虚拟机以一个直接指向方法区Lava类数据的指针来替换常量池第一项（就是那个字符串“Lava”），以后就可以用这个指针来快速地访问Lava类了。这个替换过程称为常量池解析，即把常量池中的符号引用替换为直接引用。

终于，虚拟机准备为一个新的Lava对象分配内存。此时它又需要方法区中的信息。还记得刚刚放到Volcano类常量池第一项的指针吗？现在虚拟机用它来访问Lava类型信息，找出其中记录的这样一条信息：一个Lava对象需要分配多少堆空间。

AVA虚拟机总能够通过存储在方法区的类型信息来确定一个对象需要多少内存，当JAVA虚拟机确定了一个Lava对象的大小后，它就在堆上分配这么大的空间，并把这个对象实例的变量speed初始化为默认初始值0。

当把新生成的Lava对象的引用压到栈中，main()方法的第一条指令也完成了。接下来的指令通过这个引用调用Java代码（该代码把speed变量初始化为正确初始值5）。另一条指令将用这个引用调用Lava对象引用的flow()方法。

4. 类加载器

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

4.1 类与类加载器

类加载器的命名空间：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类命名空间。也就是说，你现在要比较两个类是否相等，只有在这两个类是同一个类加载器加载的前提下才有意义。

我们程序一般使用的都是应用程序类加载器。

4.2 双亲委派模型

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

从Java开发人员的角度来看，类加载器可以划分的更细致一些，绝大部分Java程序都会使用到以下3种系统提供的类加载器。

• 启动类加载器（Bootstrap ClassLoader）：前面已经介绍过，这个类将存放在\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名称不符合类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即。
• 扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载器\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
• 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认类加载器。

我们的应用程序都是由这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。

上图中展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

---

重点

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