JVM 知识整理 - 技术栈

JVM 是 Java Virtual Machine 的简称，意为 Java虚拟机。虚拟机是指通过软件模拟的具有完整硬件功能的、运行在⼀个完全隔离的环境中的完整计算机系统。真实的操作系统中，对于进程的地址空间是进行了分区域的设计，JVM也就仿照了操作系统的情况，也进行了分区域的设计.

JVM 是 Java 运行的基础，也是实现⼀次编译到处执行的关键。

1. JVM 的组成

JVM的组成主要包括：类加载器、运行时数据区（堆、虚拟机栈等）、执行引擎和本地方法接口四大部分组成。

JVM执行流程

程序在执行之前先要把java代码转换成字节码（class文件），JVM 首先需要把字节码通过⼀定的方式类加载器（ClassLoader）把文件加载到内存中运行时数据区（Runtime Data Area），而字节码文件是 JVM 的⼀套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器（执行引擎）将字节码翻译成底层系统指令再交由CPU去执行，而这个过程中需要调用其他语言的接⼝本地库接口（Native Interface）来实现整个程序的功能，这就是这4个主要组成部分的职责与功能。

2. JVM 运行时数据区

JVM 运行时数据区域也叫内存布局，但需要注意的是它和 Java 内存模型（(Java Memory Model，简称 JMM）完全不同，属于完全不同的两个概念，它由以下 5 大部分组成：

2.1 程序计数器（线程私有）

程序计数器的作用：用来记录当前线程执行的行号的。

程序计数器是⼀块比较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。

如果当前线程正在执行的是⼀个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；
如果正在执行的是⼀个Native方法，这个计数器值为空。
程序计数器内存区域是唯⼀⼀个在JVM规范中没有规定任何OOM情况的区域。

2.2 Java虚拟机栈（线程私有）

Java 虚拟机栈的作用：Java 虚拟机栈的生命周期和线程相同，Java 虚拟机栈描述的是 Java 方法执行的内存模型：每个方法在执行的同时都会创建⼀个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。咱们常说的堆内存、栈内存中，栈内存指的就是虚拟机栈。方法从调用到执行完毕，对应一个栈帧在虚拟机栈中从入栈到出栈的过程。

Java 虚拟机栈中包含了以下 4 部分：

局部变量表：存放了编译器可知的各种基本数据类型(8大基本数据类型)、对象引用。局部变量表所需的内存空间在编译期间完成分配，当进入⼀个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在执行期间不会改变局部变量表大小。简单来说就是存放方法参数和局部变量。
操作栈：每个方法会生成⼀个先进后出的操作栈。
动态链接：指向运行时常量池的方法引用。
方法返回地址：PC 寄存器的地址。

2.3 本地方法栈（线程私有）

本地方法栈和虚拟机栈类似，只不过 Java 虚拟机栈是给 JVM 使用的，而本地方法栈是给本地方法（ Native 方法）使用的。

native 关键字修饰的本地方法被执行的时候，在本地方法栈中也会创建一个栈帧，用于存放该 native 本地方法的局部变量表、操作数栈、动态链接、方法返回地址。方法执行完毕后，相应的栈帧也会出栈并释放内存空间。

2.4 堆（线程共享）

作用：所有线程共享的内存区域，几乎所有的对象实例和数组都在这里分配内存。它是 JVM 管理的内存中最大的一块，也是垃圾回收器（GC）主要活动的区域（因此常被称为"GC 堆"）。

例如 Test t = new Test();
如果 t 是一个局部变量， t 就在栈上
如果 t 是一个成员变量（非静态成员变量）， t 就在堆上
如果 t 是一个静态成员变量， t 就在元数据区上

关于堆中的新生代和老生代的概念，在垃圾回收（GC）部分讲解。

2.5 方法区/元空间（线程共享）

作用：所有线程共享，用于++存储已被虚拟机加载的类型信息（类名、访问修饰符、属性、继承哪个类、实现哪个接口等）、常量、静态变量（static）++、即时编译器（JIT）编译后的代码缓存等。

在《Java虚拟机规范中》把此区域称之为"方法区"，而在 HotSpot 虚拟机的实现中，在 JDK 7 时此区域叫做永久代（PermGen），JDK 8 中叫做元空间（Metaspace）。元空间是 JDK 8+ 中 HotSpot 虚拟机对方法区的实现（方法区是规范（接口），元空间（Metaspace）是 JDK 1.8 后的具体实现（实现类）），替代原永久代。

运行时常量池：是方法区的一部分，用于存放 class 文件中的字面量（如字符串常量 "abc"）和符号引用。

2.6 总结

3. JVM 类加载

3.1 类加载过程

对于⼀个类来说，它的生命周期是这样的：

其中前 5 步是固定的顺序并且也是类加载的过程，其中中间的 3 步我们都属于连接，所以对于类加载来说，过程分为五个阶段：加载、验证、准备、解析、初始化。

① 加载

类加载的起点，JVM 要做三件事：

找到类文件 ：通过类的全限定名（如 java.lang.String），找到对应的 .class 二进制字节流。
转成静态数据结构：将字节流解析成 JVM 内部特定的数据结构（即方法区/元空间中的运行时数据）。
生成入口对象 ：在堆内存中创建一个 java.lang.Class 对象，作为外界访问该类元数据的"总入口"。

② 验证

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

主要检查：

文件格式：魔数（CAFEBABE）是否正确，版本号是否匹配当前 JVM。
元数据：类是否有父类（除了 Object），是否非法继承了 final 类。
字节码：方法体里的指令是否合法（比如跳转指令不会跳到方法体之外）。
符号引用：即将引用的其他类、方法、字段是否真实存在（这部分会在解析阶段再次确认）。

③ 准备

这个阶段正式为类变量（static）分配内存，并设置初始值（默认零值）。

分配对象：只在方法区/元空间中给static变量划地盘。实例变量不归它管（实例变量等 new 对象时再说）。
赋的值：是数据类型的默认值（int→0，boolean→false，引用→null）。
特例：如果同时被 final 修饰（如 static final int a = 10;），由于值已知且不会再变，JVM 在准备阶段就会直接赋值为 10。

④ 解析

编译成 .class 文件时，代码里的引用（比如调了 System.out.println）只是符号引用（一个字符串名字，如 "java/io/PrintStream"）。此时 JVM 还不知道这个类具体加载到内存的哪个位置。

解析阶段：JVM 将常量池中的符号引用，替换为直接引用（即指向元空间中的内存地址、方法偏移量等），也就是初始化常量的过程。

⑤ 初始化

这是类加载的最后一步，也是真正执行 Java 代码逻辑的开始。JVM 会执行类的构造器方法 <clinit>()，该方法由两部分组成：

静态变量的显式赋值（如 static int a = 123;，此时才把 123 写进去）。
静态代码块（static { ... }）中的代码。
注意：JVM 会保证父类的 <clinit>() 先执行，即若有父类，先初始化父类（再初始化子类）

以上就是类加载的全过程，一个进程中，一个类的加载，只会触发一次。

3.2 双亲委派模型

= 类加载触发的时机 =

类加载的触发时机，核心原则只有一句话：按需加载，懒加载（Lazy Loading）。JVM 绝不会一启动就把所有类全加载进内存，而是等用到时再加载。

在Java代码中，用到哪个类，就会触发哪个类的加载：

构造这个类的实例时
调用/使用类静态属性/静态方法时
使用某个类的时候，如果它的父类还没有加载，也会触发父类的加载

= 类加载器 =

JVM 中，有专门的模块，负责类加载，即为 类加载器。

JVM 默认提供了三种类加载器：

BootstrapCLassLoader （启动类加载器）
ExtensionCLassLoader （扩展类加载器）
ApplicationCLassLoader （应用程序类加载器）
除了上述三种默认的加载器，还有自定义类加载器：在 Java 中，开发者可以继承 java.lang.ClassLoader 类，重写 findClass 等方法来自定义类加载器。

这三种类加载器，彼此之间是父子关系，注意，不是父类子类，而是通过 parent 这样的引用指向的父子关系（类似于链表）。

这三个类加载器，首当其冲就是要进行 找 .class 文件的环节，例如给定一个类名，类似于 java.lang.String ，这三个类加载器负责找的目录范围是不同的：

通过上述，可以总结出 双亲委派模型的过程：

进行类加载，通过全限定类名，找到 .class 文件的时候，就会从 ApplicationCLassLoader 作为入口开始，然后把加载类这样的任务，委托给父亲 ExtensionCLassLoader 来进行，而 ExtensionCLassLoader 也不会立即进行查找，而是也委托给父亲 BootstrapClassLoader 来进行，BootstrapClassLoader 也想委托给父亲，由于它指向的是 null，也就是没有父亲，只能自己进行类加载，根据类名，找标准库范围，看看是否存在匹配的 .class 文件。
如果 BootstrapClassLoader 没有找到，再把任务还给孩子 ExtensionCLassLoader ，接下来 ExtensionCLassLoader 来负责进行找 .class 文件的过程，找到就加载，没有找到，也就把任务还给孩子 ApplicationCLassLoader ，接下来 ApplicationCLassLoader 负责找 .class 文件，找到就加载，没有找到就抛出异常。

上述的这一套流程，目的是为了约定 "优先级"，收到一个类名之后，一定是先在标准库中找，再扩展库找，最后才是第三方库找。

4. 垃圾回收（GC）

手动释放free 内存比较麻烦，容易忘记，就会出现内存泄露的问题，Java中，引入了垃圾回收，进行内存的自动释放，JVM 会自动识别出某个内存是不是后续不再使用了，是的话就自动释放。

上面讲了Java运行时内存的各个区域。对于程序计数器、虚拟机栈、本地方法栈这三部分区域而言，其生命周期与相关线程有关，随线程而生，随线程而灭。并且这三个区域的内存分配与回收具有确定性，因为当方法结束或者线程结束时，内存就自然跟着线程回收了。

因此我们课所讲的有关内存分配和回收关注的是Java 堆与方法区这两个区域。

GC 的工作过程：

找到垃圾（不再使用的对象）
释放垃圾（对应的内存释放掉）

4.1 找到垃圾

Java堆中存放着几乎所有的对象实例，垃圾回收器在对堆进行垃圾回收前，首先要判断这些对象哪些还存活，哪些已经"死去"。判断对象是否已"死"有如下几种算法。

内存 VS 对象

在 Java 中，所有的对象都是要存在内存中的（也可以说内存中存储的是⼀个个对象），因此我们将内存回收，也可以叫做死亡对象的回收。

死亡对象的判断方法：

①引用计数算法

每个对象在 new 的时候，都搭配一个小的空间，来保存一个整数，这个整数就表示当前对象有多少个引用指向它。具体为：

给对象增加⼀个引用计数器，每当有⼀个地⽅引用它时，计数器就+1；当引用失效时，计数器就 -1；任何时刻计数器为 0的对象就是不能再被使用的，即对象已"死"。
引用计数法实现简单，判定效率也比较高，在大部分情况下都是⼀个不错的算法。比如 Python 语言就采用引用计数法进行内存管理。

每次进行引用赋值的时候，一定是通过引用来完成的，如果引用计数为0了，就说明没有引用指向这个对象了，这个对象就是垃圾。

但是，引用计数算法也有缺点：

内存消耗的更多：尤其是对象本身比较小，引用计数消耗的空间比例就更大。假设引用计数是4个字节，对象本身是8个字节，引用计数就相当于占了一半的内存空间。
可能出现 "循环引用 " 的问题：
- 在主流的JVM中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题
- 循环引用问题：假设有两个对象 A 和 B，A 持有 B 的引用，B 同时持有 A 的引用，且两者都没有被其他外部对象引用。此时：在引用计数算法中，A 和 B 的引用计数器始终为 1（互相引用），永远不会变为 0，因此无法被回收。

②可达性分析算法

Java并不采用引用计数法来判断对象是否已"死"，而采用 "可达性分析" 来判断对象是否存活。

此算法的核心思想为 : 通过⼀系列称为 "GC Roots" 的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为"引用链"，当⼀个对象到 GC Roots 没有任何的引用链相连时(从GC Roots 到这个对象不可达) 时，证明此对象是不可用的。

可作为 GC Roots 的对象：
1）栈上的局部变量（引用类型）
2）常量池引用指向的对象
3）静态成员变量（引用类型）

从这些起始节点起，尽可能遍历，判定某个对象是否能访问到：

每次访问到一个对象，都会把这个对象标记为 "可达" ，当完成所有的对象的遍历后，未被标记成 "可达" 的对象就是 "不可达" 。

JVM 中一共有多少个对象，JVM 自身是知道的，通过可达性分析，知道了哪些是 "可达" 的，剩下的就是 "不可达" 的，这些 "不可达" 就是要回收的垃圾。

假设有这样的代码，创建一棵二叉树：

java 复制代码

class Node {
    String val;
    Node left;
    Node right;
}

Node build {
    Node a = new Node("a");
    Node b = new Node("b");
    Node c = new Node("c");
    Node d = new Node("d");
    Node e = new Node("e");
    Node f = new Node("f");
    Node g = new Node("g");
    a.left = b;
    a.right = c;
    b.left = d;
    b.right = e;
    e.left = g;
    c.right = f;
    return a;
}

正常情况下，所有的节点都是 "可达" 的：

如果让 root.right.right = null; ，这样的操作，就会使 f 这个节点 "不可达" ，那么在下一轮的 GC 过程中，此处的 f 节点就会被当作垃圾进行回收。

下一轮，是因为可达性分析这个过程是周期性的，每隔一定的时间，触发一次这样的可达性分析的遍历。

而如果是将 root.right = null; ，那么 c 节点就会被当作垃圾，同时要想访问 f 节点也要通过 c 节点，但是 c 不可达，就会使得 f 节点也不可达，f 节点也会被当作垃圾处理。

当已经知道哪些对象是垃圾了，接下来就是解决如何释放垃圾的问题。

4.2 释放垃圾

通过上面的学习我们可以将死亡对象标记出来了，标记出来之后我们就可以进行垃圾回收操作了。

垃圾回收算法：

①标记-清除算法

"标记-清除"算法是最基础的收集算法。算法分为"标记"和"清除"两个阶段 : 首先标记出所有需要回收的对象，在标记完成后统⼀回收所有被标记的对象。

缺点：

效率问题 : 标记和清除这两个过程的效率都不高
空间问题 : 标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行中需要分配较大对象时，无法找到足够连续内存而不得不提前触发另⼀次垃圾收集。

申请内存空间都是申请连续的内存，不能是多个部分拼到一起，内存碎片如果非常多，总的空闲空间虽然很大，但是但凡想申请一个稍微大一点的内存都会失败。

②复制算法

"复制"算法是为了解决 "标记-清理"的效率问题。

它将可用内存按容量划分为大小相等的两块，每次只使用其中的⼀块。当这块内存需要进行垃圾回收时，会将此区域还存活着的对象复制到另⼀块上面，然后再把已经使用过的内存区域一次清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配时也就不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配即可。此算法实现简单，运行高效。

缺点：

内存的空间利用率很低
一旦不是垃圾的对象较多，复制的成本就会很高

③标记-整理算法

标记过程仍与"标记-清除"过程⼀致，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向⼀端移动，然后直接清理掉端边界以外的内存。（类似于顺序表的 "搬运"）

缺点：内存搬运数据的操作，开销是挺大的，复制成本问题仍然存在。

④分代收集算法

Java 释放对象/垃圾，就使用了分代回收的算法，将上述三种算法优点结合起来，分代算法通过区域划分，实现不同区域和不同的垃圾回收策略，从而实现更好的垃圾回收。

当前 JVM 垃圾收集都采用的是 "分代收集(GenerationalCollection)"算法，这个算法并没有新思想，只是根据对象存活周期的不同将内存划分为几块。

⼀般是把 Java堆分为新生代和老年代。在新生代 中，每次垃圾回收都有大批对象死去 ，只有少量存活，因此我们采用复制算法 ；而老年代 中对象存活率高 、没有额外空间对它进行分配担保，就必须采用**"标记-清理"或者"标记-整理"算法**。

"代" ，就是对象的年龄，也就是 GC 轮次，某个对象经历一轮 GC 可达性分析之后，不是垃圾，此时对象的年龄就 +1，初始情况为 0。

哪些对象会进入新生代？哪些对象会进入老年代？

新生代：⼀般创建的对象都会进入新生代；新生代中的对象大部分会快速消亡， GC 频次较高
老年代：大对象和经历了 N 次（⼀般情况默认是 15 次）垃圾回收依然存活下来的对象会从新生代移动到老年代。老生代的对象大部分生命周期较长，GC 频次较低

针对不同年龄的对象采取不同的策略，在新生代中，又分为 伊甸区和幸存区 （两块，大小一样）

新创建的对象会放到伊甸区，绝大部分的伊甸区的对象，都活不过第一轮 GC，所以幸存区比伊甸区小；

当能够活过一轮GC后，就会通过 复制算法 ，将存活的对象 从伊甸区复制到幸存区 中，而能够进行复制的对象规模很少，复制开销可控。

在幸存区中的对象也要经历 GC 扫描，每一轮 GC 都会消灭一大部分对象，剩余存活的对象再次通过复制算法，复制到另一个幸存区中。

如果这个对象在幸存区中经历了多次复制都存活下来了，对象的年龄就大了，就会晋升到老生代，在老生代中，也会经历 GC，每一轮的 GC，都是采用标记整理或者标记清楚算法扫描的。