虚拟机类加载机制

概述

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

与那些在编译时需要进行连接工作的语言不同，在 Java 语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，

• 缺点：这种策略会令类加载时稍微增加一些性能开销
• 优点：为 Java 应用程序提供高度的灵活性，Java 里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
  • 例如，如果编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类；

约定：

• 第一，在实际情况中，后文中直接对「类」的描述都包括了类和接口的可能性，而对于类和接口需要分开描述的场景会特别指明；
• 第二，「Class 文件」并非特指某个存在于具体磁盘中的文件，这里所说的「Class 文件」应当是一串二进制的字节流，无论以何种形式存在都可以。

类加载的时机

七个阶段：如下所示

上图中，加载、验证、准备、初始化和卸载这 5 个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而==解析阶段则不一定==：它在某些情况下可以在初始化阶段之后再开始，这是为了支持 Java 语言的运行时绑定（也称为动态绑定或晚期绑定）。注意，这里说的是按部就班地「开始」，这些阶段通常都是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段。也就是说可能有些阶段未完成，下一个阶段就开始了。

什么情况下需要会开始加载一个类？Java 虚拟机规范中并没有进行强制约束。
但是对于初始化阶段，虚拟机规范严格规定了有且只有 5 种情况必须立即对类进行「初始化」（而加载、验证、准备自然需要在此之前开始）：

1. 遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。

• 生成这 4 条指令的最常见的 Java 代码场景是：
  • 使用 new 关键字实例化对象的时候、
  • 读取或设置一个类的静态字段（被 final 修饰、已在编译期把结果放入常量池的静态字段除外）的时候，
  • 以及调用一个类的静态方法的时候。

1. 使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
2. 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
3. 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main()方法的那个类），虚拟机会先初始化这个主类。
4. 当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄
   所对应的类没有进行过初始化，则需要先触发其初始化。

• 主动引用：以上 5 种场景中的行为称为对一个类进行主动引用。
• 被动引用：除了以上 5 种场景中的行为以外的对一个进行引用的行为。

1. 对于静态字段，只有直接定义这个字段的类才会被初始化，所以通过一个类的子类来引用父类中定义的静态变量，只会触发父类的初始化，而不会触发子类的初始化。
2. 通过数组定义来引用类，不会触发此类的初始化。
3. 常量定义在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
   • 在编译阶段通过常量传播优化实现

接口的加载过程与类加载过程稍有一些不同，接口也有初始化过程，这点与类是一致的，虽然接口中不能使用 static{}语句块，但编译器仍然会为接口生成 <clinit>()类构造器，用于初始化接口中所定义的成员变量。

• 接口与类真正有所区别的是前面讲述的 5 种「有且仅有」需要开始初始化场景中的第 3 种：
  • 当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

类加载的过程

加载

「加载」是「类加载」（Class Loading）过程的一个阶段。在加载阶段，虚拟机需要完成以下 3 件事情：

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

虚拟机规范的这 3 点要求其实并不算具体，因此虚拟机实现与具体应用的灵活度都是相当大的。

一个非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（即重写一个类加载器的 loadClass()方法）。

对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是==由 Java 虚拟机直接创建==的。

• 一个数组类（下面简称为 C）创建过程就遵循以下规则：
  • 如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组 C 将在加载该组件类型的类加载器的类名称空间上被标识（一个类必须与类加载器一起确定唯一性）。
  • 如果数组的组件类型不是引用类型（例如 int[] 数组），Java 虚拟机将会把数组 C 标记为与引导类加载器关联。数组类的可见性与它的组件类型的可见性一致，
    • 如果组件类型不是引用类型，那数组类的可见性将默认为 public。

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

加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

为什么需要验证？

• 虽然在编译时，编译器也会对 java 源码会对代码进行检查。但是 .class 文件并一定不要求用 java 源码编译来的，它可以使用任何途径生成，甚至可以用十六进制编辑器直接编写 class 文件。虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃。所以验证是虚拟机对自身保护的一项重要工作。

验证什么？

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

文件格式验证

• 是否以魔数 0xCAFEBABE 开头。
• 主、次版本号是否在当前虚拟机处理范围之内。
• 常量池的常量中是否有不被支持的常量类型（检查常量 tag 标志）。
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
• ……

该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个 Java 类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的 3 个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。

元数据验证

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合 Java 语言规范的要求

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

继承关系，方法覆盖

字节码验证

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

• 如果一个类方法体的字节码没有通过字节码验证，那肯定是有问题的；
• 但如果一个方法体通过了字节码验证，也不能说明其一定就是安全的。

离散数学中一个很著名的问题「Halting Problem」（停机问题） ：通过程序去校验程序逻辑是无法做到绝对准确的——不能通过程序准确地检查出程序是否能在有限的时间之内结束运行。

符号引用验证

发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。

符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验下列内容：

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

准备

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

• 首先，这时候进行内存分配的仅包括类变量（被 static 修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。
• 其次，这里所说的初始值「通常情况」下是数据类型的零值
  • 这时候尚未开始执行任何 Java 方法。
  • 「==特殊情况==」：如果类字段的字段属性表中存在 ConstantValue 属性，那在准备阶段变量 value 就会被初始化为 ConstantValue 属性所指定的值。
    • 假设上面类变量 value 的定义变为：public static final int value=123； 那么在准备阶段虚拟机就会根据 ConstantValue 的设置将 value 赋值为 123。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，在 Class 文件中 符号引用 以 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info 等类型的常量出现

符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。

直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

• 直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。
  • 如果有了直接引用，那引用的目标必定已经在内存中存在。

虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。

invokedynamic 指令的目的本来就是用于动态语言支持（目前仅使用 Java 语言不会生成这条字节码指令），它所对应的引用称为「动态调用点限定符」（Dynamic Call Site Specifier），这里「动态」的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。

• 相对的，其余可触发解析的指令都是「静态」的，可以在刚刚完成加载阶段，还没有开始执行代码时就进行解析。

1. 类或接口的解析

假设当前代码所处的类为 D，如果要把一个从未解析过的符号引用 N 解析为一个类或接口 C 的直接引用，那虚拟机完成整个解析的过程需要以下 3 个步骤：

1. 如果 C 不是一个数组类型，那虚拟机将会把代表 N 的全限定名传递给 D 的类加载器去加载这个类 C。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就宣告失败。
2. 如果 C 是一个数组类型，并且数组的元素类型为对象，也就是 N 的描述符会是类似「[Ljava/lang/Integer」的形式，那将会按照第 1 点的规则加载数组元素类型。如果 N 的描述符
   如前面所假设的形式，需要加载的元素类型就是「java.lang.Integer」，接着由虚拟机生成一个代表此数组维度和元素的数组对象。
3. 如果上面的步骤没有出现任何异常，那么 C 在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，检查访问权限。如果发现不具备访问权限，将抛出 java.lang.IllegalAccessError 异常。

字段解析

类方法解析

接口方法解析

接口的方法、常量都是 public 的，所以不需要进行权限验证

初始化

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

• 在准备阶段，变量已经赋过一次系统要求的初始值
• 在初始化阶段，根据项目需要对类变量进行相应的初始化，或者可以从另外一个角度来表达：初始化阶段是执行类构造器 () 方法的过程。

()方法是由编译器自动收集类中的所有类变量的==赋值动作==和静态语句块（static{}块）中的语句合并产生的，

• 编译器收集的顺序是由语句在源文件中出现的顺序所决定的，
• 静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
• 如果没有静态语句块也没有变量初始化赋值，就不会产生 方法

()方法不需要显式地调用父类构造器，虚拟机会保证在子类的 ()方法执行之前，父类的()方法已经执行完毕。
因此在虚拟机中第一个被执行的 ()方法的类肯定是 java.lang.Object。

接口与类一样都会生成 ()方法。但接口与类不同的是，

• 执行接口的 ()方法不需要先执行父接口的 ()方法。只有当父接口中定义的变量使用时，父接口才会初始化。
• 另外，接口的实现类在初始化时也一样不会执行接口的 ()方法。

虚拟机会保证一个类的 方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的 ()方法中有耗时很长的操作，就可能造成多个进程阻塞。在实际应用中这种阻塞往往是很隐蔽的

类加载器

类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在 Java 虚拟机中的唯一性，每一个类加载器都拥有一个独立的命名空间。

双亲委派模型

从 Java 虚拟机的角度来讲，只存在两种不同的类加载器：

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

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

• 启动类加载器（Bootstrap ClassLoader）：这个类将器负责将存放在＜JAVA_HOME＞\lib 目录中的，或者被-Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如 rt.jar，名字不符合的类库即使放在 lib 目录中也不会被加载）
  类库加载到虚拟机内存中。
  • 无法直接被用户使用，只能通过子类返回 null 来间接调用。
• 扩展类加载器：Extension ClassLoader，负责加载＜JAVA_HOME＞\lib\ext (扩展库)目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
• 应用程序类加载器：因为可以通过 ClassLoader.getSystemClassLoader() 获取，因此一般也称为系统类加载器，负责加载用户路径上所指定类库，可以直接被开发者使用。

上图中展示的层次关系，称为类加载器的双亲委派模型。

• 该模型要求除了顶层的启动类加载器外，其余的类加载器都应该有自己的父类加载器。
  • 此处的父子关系通常不会通过继承关系来实现，而是选择组合关系来复用父加载器的代码

工作过程：当一个类加载器收到了类加载的请求时，它不是自己加载，而是将这个请求委派给父类加载器去完成，每一层的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成该请求时，子加载器才会尝试自己去加载。

好处：

• Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。
• 保证 java 核心库的安全性（例如：如果用户自己写了一个 java.lang.String 类就会因为双亲委派机制不能被加载，不会破坏原生的 String 类的加载）
  • 栗子： Object 类，无论哪一个类要加载该类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。

实现：在 ClassLoader 的 loadClass 方法中。

对比：

代理模式：

• 与双亲委派机制相反，代理模式是先自己尝试加载，如果无法加载则向上传递。tomcat 就是代理模式。

「破坏」双亲委派模型

双亲委派模型并不是一个强制性的约束模型。

• 双亲委派模型的第一次「被破坏」其实发生在双亲委派模型出现之前——即 JDK 1.2 发布之前。
• 双亲委派模型的第二次「被破坏」是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载）
  • 基础类之所以称为「基础」，是因为它们总是作为被用户代码调用的 API，但是基础类调用回用户的代码不容易（用回调不行？？）
  • 一个典型的例子便是 JNDI 服务
• 双亲委派模型的第三次「被破坏」是由于用户对程序动态性的追求而导致的，这里所说的「动态性」指的是当前一些非常「热门」的名词：代码热替换（HotSwap）、模块热部署（HotDeployment）等，说白了就是希望应用程序能像我们的计算机外设那样，接上鼠标、U 盘，不用重启机器就能立即使用。热插拔？

在 OSGi 环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi 将按照下面的顺序进行类搜索：

1. 将以 java.*开头的类委派给父类加载器加载。
2. 否则，将委派列表名单内的类委派给父类加载器加载。
3. 否则，将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载。
4. 否则，查找当前 Bundle 的 ClassPath，使用自己的类加载器加载。
5. 否则，查找类是否在自己的 Fragment Bundle 中，如果在，则委派给 Fragment Bundle 的类加载器加载。
6. 否则，查找 Dynamic Import 列表的 Bundle，委派给对应 Bundle 的类加载器加载。
7. 否则，类查找失败。

一个问题

写出下面代码中的输出结果

class SingleTon {
    private static SingleTon singleTon = new SingleTon();
    public static int count1;
    public static int count2 = 0;
 
    private SingleTon() {
        count1++;
        count2++;
    }
 
    public static SingleTon getInstance() {
        return singleTon;
    }
}
 
public class Test {
    public static void main(String[] args) {
        SingleTon singleTon = SingleTon.getInstance();
        System.out.println("count1=" + singleTon.count1);
        System.out.println("count2=" + singleTon.count2);
    }
}

分析:

1. 从 main 函数看起，SingleTon singleTon = SingleTon.getInstance();调用了SingleTon类的静态方法，触发类的初始化。
2. 类加载的时候在准备过程中为类的静态变量分配内存并初始化默认值singleton=null count1=0,count2=0
3. 类初始化，为类的静态变量赋值和执行静态代码块。singleton赋值为new SingleTon()。调用类的构造方法
4. 调用类的构造方法后 count=1;count2=1
5. 继续为count1与count2赋值,此时count1没有赋值操作,所有count1为1,但是count2执行赋值操作就变为0

小结

加载

加载是类加载过程中的一个阶段，这个阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的入口。注意这里不一定非得要从一个 Class 文件获取，这里既可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）。

验证

这一阶段的主要目的是为了确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

准备

准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。注意这里所说的初始值概念，比如一个类变量定义为：

public static int v = 8080;

实际上变量 v 在准备阶段过后的初始值为 0 而不是 8080，将 v 赋值为 8080 的putstatic指令是程序被编译后，存放于类构造器<client>方法之中，这里我们后面会解释。

但是注意如果声明为：

public static final int v = 8080;

在编译阶段会为 v 生成ConstantValue属性，在准备阶段虚拟机会根据 ConstantValue 属性将 v 赋值为 8080。

解析

解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。符号引用就是 class 文件中的：

• CONSTANT_Class_info
• CONSTANT_Field_info
• CONSTANT_Method_info

等类型的常量。

下面我们解释一下符号引用和直接引用的概念：

• 符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。
• 直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化

初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由 JVM 主导。到了初始阶段，才开始真正执行类中定义的 Java 程序代码。

初始化阶段是执行类构造器<clint>方法的过程。<clint>方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证<clint>方法执行之前，父类的<clint>方法已经执行完毕。p.s: 如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成<clint>()方法。

注意以下几种情况不会执行类初始化：

• 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
• 定义对象数组，不会触发该类的初始化。
  • Xxx[] ary = new Xxx[];
• 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
• 通过类名获取 Class 对象，不会触发类的初始化。
• 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
• 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作。

参考资料与学习资源推荐

• 《深入理解 Java 虚拟机》
• JVM 类加载机制详解

本文内容主要参考自《深入理解 Java 虚拟机》，当然也有一些个人理解，若有不正确的结论、说法，请大家指出，共同探讨，共同进步，谢谢!