深入理解java虚拟机--虚拟机类加载机制(代码片段)

本文参考于《深入理解Java虚拟机》

1. 虚拟机类加载机制说明

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

2. 类生命周期

2.1 类生命周期总述

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

图示

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

2.2 加载

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

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

2.3 验证

2.3.1 验证的目的

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

2.3.2 验证的四个方面

1. 文件格式验证

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

• 验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
• 主、次版本号是否在当前Java虚拟机接受范围之内。
• 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
• CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。

2. 元数据验证

对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求。

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

该阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相悖的元数据信息。

3. 字节码验证

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

例如：

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

4. 符号引用验证

符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。

校验的内容

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

2.4 准备

2.4.1 准备的目的

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段，这里所说的初始值“通常情况”下是数据类型的零值。

特别注意：该阶段的所有变量的值都是相应的数据类型的零值，而不是赋值以后的值。

例如

public static float a = 123f;

处于该阶段下的 a 的值为0.0f 。

2.5 解析

2.5.1 解析的目的

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

2.5.2 补充概念

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

2.6 初始化

2.6.1 初始化阶段说明

类的初始化阶段是类加载过程的最后一个步骤。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。我们也可以从另外一种更直接的形式来表达：初始化阶段就是执行类构造器< clinit >()方法的过程。

2.6.2 < clinit >方法说明

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

2. < clinit >()方法与类的构造函数（即在虚拟机视角中的实例构造器< init >()方法）不同，它不需要显式地调用父类构造器，Java虚拟机会保证在子类的< clinit >()方法执行前，父类的< clinit >()方法已经执行完毕。因此在Java虚拟机中第一个被执行的< clinit >()方法的类型肯定是java.lang.Object。

3. 由于父类的< clinit >()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

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

5. 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成< clinit >()方法。但接口与类不同的是，执行接口的< clinit >()方法不需要先执行父接口的< clinit >()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的< clinit >()方法。

6. Java虚拟机必须保证一个类的< clinit >()方法在多线程环境中被正确地加锁同步。

2.7 卸载

2.7.1 卸载过程说明

卸载过程就是该类Class对象被回收。

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

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

jdk 自带的 BootstrapClassLoader, ExtClassLoader, AppClassLoader 负责加载 jdk 提供的类，所以它们(类加载器的实例)肯定不会被回收。而我们自定义的类加载器的实例是可以被回收的，所以使用我们自定义加载器加载的类是可以被卸载掉的。

3. 类加载器

3.1 类相等判断

比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

3.2 启动类加载器

BootstrapClassLoader : 最顶层的加载类，由C++ 实现，负责加载%JAVA_HOME%/lib目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类。

3.3 扩展类加载器

ExtensionClassLoader : 主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。

3.4 应用程序类加载器

AppClassLoader : 面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

3.5 自定义类加载器

3.5.1 什么时候需要自定义类加载器?

1）想加载非 classpath 随意路径中的类文件
2）都是通过接口来使用实现，希望解耦时，常用在框架设计
3）这些类希望予以隔离，不同应用的同名类都可以加载，不冲突，常见于 tomcat 容器

3.5.2 定义步骤

• 继承 ClassLoader 父类。
• 要遵从双亲委派机制，重写 findClass 方法 注意不是重写 loadClass 方法，否则不会走双亲委派机制。
• 读取类文件的字节码。
• 调用父类的 defineClass 方法来加载类。
• 使用者调用该类加载器的 loadClass 方法。

4. 双亲委派机制

4.1 双亲委派机制说明

在类加载的时候，系统会首先去检查这个类是否被加载过，如果这个类被加载过的话，那么就是将已经被加载过的类直接返回。如果没有被加载过的话，那么就会尝试去加载。首先会把该请求委派给父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

图示

4.2 好处

1. 避免类的重复加载：JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类。
2. 保证了 Java 的核心 API 不被篡改：如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。