转载

一夜搞懂 | JVM 类加载机制

前言

本文已经收录到我的Github个人博客，欢迎大佬们光临寒舍：

我的GIthub博客

学习导图

一夜搞懂 | JVM 类加载机制

一.为什么要学习类加载机制？

今天想跟大家唠嗑唠嗑 Java 的类加载机制，这是 Java 的一个很重要的创新点，曾经也是 Java 流行的重要原因之一。

Oracle 当初引入这个机制是为了满足 Java Applet 开发的需求， JVM 咬咬牙引入了 Java 类加载机制，后来的基于 Jvm 的动态部署，插件化开发包括大家热议的热修复，总之很多后来的技术都源于在 JVM 中引入了类加载器。

如今，类加载机制也在各个领域大放异彩，在面试中，由类加载机制所衍生出来各类面试题也层出不穷。

所以，我们要了解下类加载机制，为工作中或者是面试中实际的需要打好良好的基础。

二.核心知识点归纳

2.1 概述

Q1:JVM类加载机制定义：

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

Q2：特性

运行期类加载。即在 Java 语言里面，类型的加载、连接和初始化过程都是在程序 运行期 完成的，从而通过牺牲一些性能开销来换取 Java 程序的高度灵活性

什么是运行期，什么是编译期？

编译期 是指编译器将 源代码翻译 为 机器能识别的代码 ， Java 被编译为 Jvm 认识的 字节码文件
运行期 则是指 Java 代码的运行过程

JVM 运行期动态加载+动态连接-> Java 的动态扩展特性

2.2 类加载的过程

类从被加载到虚拟机内存中开始、到卸载出内存为止，整个生命周期包括七个阶段：

加载
验证
准备
解析
初始化
使用
卸载

其中，验证、准备、解析这3个部分统称为连接，流程如下图：

一夜搞懂 | JVM 类加载机制

注意：

Java

想要了解 Java 动态绑定和静态绑定区别的话，可以看下这篇文章：理解静态绑定与动态绑定

2.2.1 加载

Q1：任务

通过类的全限定名来获取定义此类的 二进制字节流 。如从 ZIP 包读取、从网络中获取、通过运行时计算生成、由其他文件生成、从数据库中读取等等途径......

想要详细了解类的全限定名的知识，可以看下这篇文章：全限定名、简单名称和描述符是什么东西？

将该二进制字节流所代表的 静态存储结构 转化为 方法区 的 运行时数据结构 ，该数据存储数据结构由虚拟机实现自行定义
在内存中生成一个代表这个类的 java.lang.Class 对象，它将作为程序访问方法区中的这些类型数据的外部接口

2.2.2 验证

是连接阶段的 第一步 ，且工作量在 JVM 类加载子系统中占了相当大的一部分
目的：为了确保 Class 文件的字节流中包含的信息符合当前 虚拟机的要求 ，并且 不会危害虚拟机自身的安全

由此可见，它能直接决定 JVM 能否承受恶意代码的攻击，因此验证阶段 很重要 ，但由于它对程序运行期没有影响，并 不一定必要 ，可以考虑使用 -Xverify：none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

检验过程包括下面四个阶段：

A.文件格式验证：
- 内容：验证 字节流是否符合 Class 文件格式的规范 、以及是否能被 当前版本的虚拟机处理
- 目的：保证输入的 字节流 能正确地解析并存储于 方法区 之内，且格式上符合描述一个 Java 类型信息的要求。只有保证二进制字节流通过了该验证后，它才会进入内存的方法区中进行存储，所以 后续3个验证阶段全部是基于方法区 而不是字节流了
- 例子：
  1. 是否以魔数 0xCAFEBABE 开头
  2. 主次版本号是否在 JVM 接受范围内
  3. 索引值是否有指向不存在/不符合类型的常量
    
    ......
B.元数据验证：
- 内容：对字节码描述的信息进行语义分析，以保证其描述的信息符合 Java 语言规范的要求
- 目的：对类的 元数据信息 进行语义校验，保证不存在不符合 Java 语言规范的元数据信息
- 例子：
  1. 类是否有父类（除了 java.lang.Object 之外，所有类都应有父类）
  2. 父类是否继承了不允许被继承的类（ final 修饰的类）
  3. 如果该类不是抽象类，是否实现了其父类或接口中要求实现的所有方法
    
    ......
C.字节码验证：
- 是验证过程中 最复杂 的一个阶段
- 内容：对类的 方法体 进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件
- 目的：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的
- 例子：
  1. 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现“在操作数栈的数据类型中放置了 int 类型的数据，使用时却按 long 类型来载入本地变量表中”
  2. 保证任何跳转指令都不会跳转到方法体外的字节码指令上
    
    ......
D.符号引用验证：
- 内容：对 类自身以外（如常量池中的各种符号引用）的信息 进行匹配性校验
- 目的：确保解析 动作能正常执行 ，如果无法通过符号引用验证，那么将会抛出一个 java.lang.IncompatibleClassChangeError 异常的子类
- 注意：该验证发生在虚拟机将 符号引用 转化为 直接引用 的时候，即『解析』阶段

2.2.3 准备

Q1：任务

为类变量（静态变量） 分配内存 ： 因为这里的变量是由方法区分配内存 的，所以 仅包括类变量 而不包括实例变量，后者将会在对象实例化时随着对象一起分配在 Java 堆中
设置类变量 初始值 ：通常情况下零值

2.2.4 解析

之前提过，解析阶段就是虚拟机将 常量池 内的 符号引用替换为直接引用 的过程

符号引用：以一组符号来描述所引用的目标

可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可
与虚拟机实现的内存布局无关，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中，所以即使各种虚拟机实现的内存布局不同，但是能接受符号引用都是一致的

直接引用：

可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄
与虚拟机实现的内存布局相关，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不同

发生时间： JVM 会根据需要来判断，是在类被加载器 加载时 就对常量池中的符号引用进行解析，还是等到一个符号引用将要被 使用前 才去解析
解析动作：有七类符号及其对应在常量池的七种常量类型

类或接口 ( CONSTANT_Class_info )
字段 ( CONSTANT_Fieldref_info )
类方法 ( CONSTANT_Methodref_info )
接口方法 ( CONSTANT_InterfaceMethodref_info )
方法类型 ( CONSTANT_MethodType_info )
方法句柄 ( CONSTANT_MethodHandle_info )
调用点限定符 ( CONSTANT_InvokeDynamic_info )

举个例子，设当前代码所处的为类 D ，把一个从未解析过的 符号引用 N 解析为一个 类或接口 C 的直接引用 ，解析过程分三步：

若 C 不是数组类型： JVM 将会把代表 N 的全限定名传递给 D 类加载器去加载这个类 C 。在加载过程中，由于 元数据验证 、 字节码验证 的需要，又可能触发其他相关类的加载动作。一旦这个加载过程出现了任何异常，解析过程就宣告失败。
若 C 是数组类型且数组元素类型为对象： JVM 也会按照上述规则加载数组元素类型
若上述步骤无任何异常：此时 C 在 JVM 中已成为一个有效的类或接口，但在解析完成前还需进行 符号引用验证 ，来确认 D 是否具备对 C 的访问权限。如果发现不具备访问权限，将抛出 java.lang.IllegalAccessError 异常

Q1:字段（成员变量/域）和属性有什么区别？

属性，是指对象的属性，对于 JavaBean 来说，是 getXXX 方法定义的
字段，是成员变量

class Person{
    private String mingzi;  //mingzi是字段，一般来说字段和属性是相同的，但是这个例子是特例
    public String getName(){  //name是属性
        return mingzi:
    }
    public void setName(){
        mingzi= "张三";
    }
}

2.2.5 初始化

是类加载过程的最后一步，会开始真正执行类中定义的 Java 代码。而之前的类加载过程中，除了在『加载』阶段用户应用程序可通过 自定义类加载器 参与之外， 其余阶段均由虚拟机主导和控制
与『准备』阶段的区分：

clinit

clinit ：由编译器自动收集类中的所有 类变量（静态变量）的赋值动作 和静态语句块 static{} 中的语句合并产生

是 线程安全 的，在多线程环境中被正确地加锁、同步
对于类或接口来说是非必需的，如果一个类中 没有静态语句块 ，也没有对变量的赋值操作，那么编译器可以不为这个类生成 clinit
接口与类不同的是 ，执行接口的 clinit 不需要先执行父接口 的 clinit ，只有当父接口中定义的变量使用时，父接口才会初始化。另外， 接口的实现类在初始化时 也一样不会执行接口的 clinit

想详细了解 clinit 以及其与 init 的区别的读者，可以看下这篇文章：深入理解jvm--Java中init和clinit区别完全解析

在虚拟机规范中，规定了有且只有五种情况 必须立即 对类进行『 初始化 』：

遇到 new 、 getstatic 、 putstatic 或 invokestatic 这4条字节码指令时
使用 java.lang.reflect 包的方法对类进行反射调用的时候
当初始化一个类的时候，若发现其父类还未进行初始化，需先触发其父类的初始化
在虚拟机启动时，需指定一个要执行的主类，虚拟机会先初始化它
当使用 JDK1.7 的动态语言支持时，若一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic 、 REF_putStatic 、 REF_invokeStatic 的方法句柄，且这个方法句柄所对应的类未进行初始化，需先触发其初始化。

2.3 类加载器&双亲委派模型

每个类加载器，都拥有一个独立的命名空间，它不仅用于加载类，还和这个类本身一起作为在 JVM 中的唯一标识。所以比较两个类是否相等，只要看它们是否由同一个 类加载器 加载，即使它们来源于同一个 Class 文件且被同一个 JVM 加载，只要加载它们的 类加载器不同，这两个类就必定不相等

2.3.1 类加载器

从 JVM 的角度，可将类加载器分为两种：

启动类加载器

由 C++ 语言实现，是虚拟机自身的一部分
负责加载存放在 ＜JAVA_HOME＞/lib 目录中、或被 -Xbootclasspath 参数所指定路径中的、且可被虚拟机识别的类库
无法被 Java 程序直接引用，如果自定义类加载器想要把加载请求委派给引导类加载器的话，可直接用 null 代替

其他类加载器：由 Java 语言实现，独立于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader ，可被 Java 程序直接引用。常见几种：

扩展类加载器

A.由 sun.misc.Launcher$ExtClassLoader 实现

B.负责加载 ＜JAVA_HOME＞/lib/ext 目录中的、或者被 java.ext.dirs 系统变量所指定的路径中的所有类库
应用程序类加载器

A.是默认的类加载器，是 ClassLoader#getSystemClassLoader() 的返回值，故又称为 系统类加载器

B.由 sun.misc.Launcher$App-ClassLoader 实现

C.负责加载用户类路径上所指定的类库
自定义类加载器：如果以上类加载起不能满足需求，可自定义

一夜搞懂 | JVM 类加载机制

需要注意的是：虽然 数组类 不通过类加载器创建而是由 JVM 直接创建的，但仍与类加载器有密切关系，因为 数组类的元素类型最终还要靠类加载器去创建

2.3.2 双亲委派模型

定义：表示类加载器之间的层次关系
前提：除了顶层启动类加载器外， 其余类加载器都应当有自己的父类加载器 ，且它们之间关系一般不会以继承关系来实现，而是通过组合关系来复用父加载器的代码
工作过程 ：若一个类加载器收到了类加载的请求，它先会把这个请求委派给父类加载器，并向上传递，最终请求都传送到顶层的启动类加载器中。只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载
注意：不是一个强制性的约束模型，而是 Java 设计者推荐给开发者的一种类加载器实现方式
优点：类会随着它的类加载器一起具备带有 优先级 的层次关系，可保证 Java 程序的稳定运作；实现简单，所有实现代码都集中在 java.lang.ClassLoader的loadClass() 中