五、Jvm系列(3)——类加载机制

Jvm系列(3)——类加载机制

Java 与 C++ 之间有一堵由 内存动态分配和垃圾收集技术 所围成的 “高墙”，墙外面的人想进去，墙里面的人却想出来。

类的生命周期如下：

• 上图是类的 生命周期。
• Java 虚拟机中 类加载 的全过程 是* 加载、验证、准备、解析 和 初始化* 这 5 个阶段所执行的具体动作。
• 在这7个阶段中，加载、验证、准备、初始化和卸载 这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的开始。
• 而 解析 阶段则不一定，它在某些情况下可以在 初始化阶段 之后再开始。这是为了支持Java语言的运行时绑定。

0. 什么时候开始类加载过程的第一个阶段： 加载？

Java 虚拟机规范中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。
但是对于 初始化阶段，虚拟机规范则是严格规定了有且只有5中情况必须立即对类进行初始化（而加载、验证、准备、自然要在此之前开始）。

• 1、遇到new、getstatic、putstatic 或 invokestatic 这4条字节码指令时，如果类没有进行初始化，则需要先触发其初始化。 生成这4条指令的最常见的Java代码场景是：使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）、以及调用一个类的静态方法的时候。
• 2、使用 java.lang.reflect 包的方法对类进行 反射调用 的时候，如果类没有进行过初始化，则需要先触发其初始化。
• 3、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其* 父类* 的初始化。
• 4、当虚拟机启动时，用户需要指定一个要执行的 主类（包含 main（）方法的那个类），虚拟机会先初始化这个主类。
• 5、当使用 JDK1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

上述这5种场景中的行为称为对一个类进行 主动引用。 除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

1. 加载

虚拟机在加载阶段，需要完成以下3件事情：

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

对于上述 二进制字节流，不一定要从一个 Class 文件中获取，还可以有如下来源：

• 从 ZIP 包中读取，这很常见，最终成为日后 JAR、EAR、WAR 格式的基础。
• 从网络中获取，典型应用 Applet。
• 运行时计算生成，例如动态代理技术，在 java.lang.reflect.Proxy 中，就是用了 ProxyGenerator.generateProxyClass 来为特定接口生成形式为 ” *$Proxy ” 的代理类的二进制字节流。
• 其他文件生成，典型场景 JSP 应用。
• 数据库中读取，这种场景相对少见，例如 中间件服务器（ SAP Netweaver)

注意： 数组类 本身不通过类加载器创建，它是由 Java 虚拟机直接创建的。 但是数组类的元素类型最终还是要靠类加载器去创建的。

2. 验证

验证是 连接阶段（Linking）的第一步。 它的目的是 为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求。 不会危害虚拟机自身的安全。
比如：纯粹的 Java 代码无法做到 访问数组边界以外的数据、将一个对象转型为它并未实现的类型、跳转到不存在的代码行 之类的事情，如果你这样做了，编译器将会 拒绝编译，也就是无法生成 Class 文件。
但是前面说过，Class 文件并不一定要由 Java 源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生 Class 文件。然而在 字节码语言 层面上，上述 Java 代码无法做到的事情都是可以实现的，所以 验证阶段 是非常重要也是必要的。

验证阶段 大致会完成下面4个阶段的 检验动作。

• 1、文件格式验证：验证 字节流 是否符合 Class 文件格式的规范。
• 2、元数据验证： 验证 是否符合 Java 语言规范。
• 3、字节码验证： 通过 数据流 和 控制流 分析，确定程序语义是否是合法的、符合逻辑的。
• 4、符号引用验证：验证 虚拟机将 符号引用 转化为 直接引用。

2.1 文件格式验证

• 是否以 魔数 0xCAFEBABE (咖啡宝贝?) 开头。
• 主、次版本号是否在当前虚拟机处理范围之内。
• 检查常量 tag 标志
• 等等……

只有通过了这个阶段的 验证后，字节流才会进入 内存的方法区 中进行存储。

2.2 元数据验证

经过 文件格式验证，字节流已经加载到 方法区， 这个阶段的工作就是 对方法区的字节码 描述的信息进行语义分析，以保证其描述的信息符合 Java 语言规范的要求， 验证点如下：

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

2.3 字节码验证

对类的方法体进行校验。

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

2.4 符号引用验证

目的是确保 解析动作能正常执行。 校验点：

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

对于虚拟机的类加载机制来说，验证阶段非常重要的，但不是一定必要的。如果所运行的全部代码(包含自己编写以及第三方包的代码)都已经被反复使用和验证过，那么可以考虑使用 -Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3. 准备

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

3.1 类变量：赋予初始值
假设： public static int value = 123;
变量 value 在准备阶段过后的初始值为 0 而不是 123。 把value赋值为123的动作将在 初始化阶段 执行。

3.2 常量：赋予真实值
假设：public static final int value = 123;
编译时，javac 将会为 value 生成 ConstantValue 属性，在准备阶段 虚拟机就会根据 ConstantValue 的设置将 value 赋值为 123

3.3 实例变量：不赋任何值
该阶段仅对类变量进行内存分配，而对于实例变量(或者称呼为成员变量)并不会分配内存，也就更不用提赋值的事。实例变量的初始化，是随着对象实例化时在Java堆上分配内存而进行的。

4. 解析

主要工作是： 虚拟机将常量池内的 符号引用 替换为 直接引用 的过程。

• 符号引用（Symbolic Reference）：以一组符号来描述引用目标，符号可以是任意形式的字面量。只能要准确定位到目标即可。符号引用与虚拟机的内存布局无关，引用的目标也不一定存在内存。这样兼容性强，各种虚拟机只需要能接受符号引用即可。
• 直接引用（Direct References）：直接引用就是指向 目标的指针、相对偏移量 或者能间接定位到目标的句柄。直接引用和虚拟机内存布局是相关的。同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

5. 初始化

主要工作：执行类构造器 <clinit>() 方法 （class init 的简称）。

• clinit 方法是由编译器自动收集 类中的所有 类变量的赋值动作 和 静态语句块(static{}块)中的语句合并产生的。收集顺序是由语句在源文件的顺序所决定。故静态语句块只能访问定义之前的静态变量；对于定义之后的变量可以赋值，但不能访问。
• clinit 方法 与 类的构造函数（或者说实例构造器 init 方法） 不同。clinit 方法不需要显式调用父类构造器，虚拟机会保证子类的 clinit 方法 执行之前，父类的 clinit方法 已经执行完毕。因此虚拟机中第一个被执行的 clinit方法 的类肯定是java.lang.Object。
• 父类静态语句和静态变量赋值优先于子类。
• clinit方法 不是必需的，对于没有静态块和类变量赋值操作，编译器可以不为这个类生成 clinit方法。
• 接口中不能使用静态语句块，但仍可以有变量初始化的赋值操作，也可以生成 clinit方法。但接口和类不同的是，执行接口的 clinit方法 不需要先执行父接口的 clinit方法。只有当父接口中定义的变量使用时，父接口才会初始化。
• 虚拟机会保证一个类的 clinit 方法 可以多线程正确执行，会加锁、同步的操作。 如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的 clinit 方法，其他线程阻塞等待，当类构造方法有耗时操作，会造成多进程的阻塞,往往比较隐蔽。

6. 类加载器——双亲委派模型

类加载器从 Java 开发人员的角度可以分为以下三种系统提供的类加载器：

• 启动类加载器（Bootstrap ClassLoader）: 负责将存放在 < JAVA_HOME >\ lib 目录中的类库 或者 被 -Xbootclasspath 参数所指定的路径中的类库 加载到虚拟机内存中。 启动类加载器无法被 Java 程序直接引用。
• 扩展类加载器（Extension ClassLoader）：负责加载 < JAVA_HOME >\ lib \ ext 目录中的 或者 被 java.ext.dirs 系统变量所指定的路径中的所有类库。 开发者可用直接使用扩展类加载器
• 应用程序类加载器（Application ClassLoader） ：这个类加载器由 sun.misc.Launcher$AppClassLoader 实现。它负责加载 用户类路径（ClassPath）上所指定的类库。
• 当然除了以上三种，我们还可以 自定义类加载器。

上图所示的 类加载器 之间的这种层次关系，称为 类加载器的双亲委派模型。

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