《深入理解 Java 虚拟机》阅读笔记 - 垃圾回收机制_主动式中断轮询标志得地方和安全点是重合得-优快云博客

本文链接：https://blog.youkuaiyun.com/Victorgcx/article/details/102673761

判断对象是否已死
- 引用计数算法
- 可达性分析算法
- finalize()
引用
垃圾收集算法
- 标记-清除算法
- 复制算法
- 标记-整理算法
- 分代收集算法
垃圾收集器
- Serial / Serial Old
- ParNew
- Parrallel Scavenge / Parrallel Old
- CMS
- G1
内存分配与回收策略
参考

在Java 内存运行时区域的各个部分中，程序计数器、虚拟机栈、本地方法栈属于线程私有，随线程产生和灭亡。栈中的栈帧随着方法的进入和退出而有条不紊地执行出栈和入栈操作，每一个栈帧中分配多少内存基本上是在类结构确定下来就已知的，因此这几个区域的内存分配和回收都具有确定性，不需要考虑回收的问题。

而Java 堆和方法区则不一样，只有在程序处于运行期间才知道会创建那些对象，这部分内存的分配和回收是动态的，垃圾收集关注的主要是这部分内存。而方法区又被成为永久代，里面的对象大多数在运行时长期存在，所以更进一步地，垃圾回收主要针对的是 Java 堆占据的内存区域。

判断对象是否已死

引用计数算法

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器的值就加 1；当引用失效时，计数器的值就减 1；任何时刻计数器为 0 的随想就是不可能再被使用的。

优点

实现简单，判断效率高

缺点

但是主流的 Java 虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。

可达性分析算法

通过一系列被称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索过程中走过的路径成为引用链，当一个对象到 GC Roots 没有任何引用链相连（即从任何 GC Roots 到这个对象都不可达）时，证明此对象是不可用的。

Java 语言中，可作为 GC Roots 的对象包括：

虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中 JNI（Java Native Interface，即一般所说的 Native 方法）引用的对象。

GC Roots 基本上是全局性引用（例如常量和类静态属性）与执行上下文（例如栈帧中的本地变量表）。对象的成员变量不能作为 GC Roots。

finalize()

不可达对象并非立即死亡。要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析过后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。

当对象没有覆盖 finalize() 方法或者 finalize() 方法已经被虚拟机调用过，将被视为“没有必要执行”，否则认为“有必要执行”。（finalize() 方法最多只会被系统调用一次。）

“没有必要执行”的对象将会被宣告死亡。
“有必要执行”的对象会被加入到一个叫 F-Queue 的队列里，由虚拟机中一个低优先级的线程去执行它。（仅触发，并不承诺等待它运行结束。）在 GC 对 F-Queue中的对象进行标记之前，如果对象在 finalize() 中与引用链上的任何一个对象建立关联，则自救成功，否则对其执行垃圾回收操作。

引用

JDK1.2 之后引用的概念包括四种，强度依次逐渐减弱。

强引用

代码中普遍存在的引用，类似“Object obj = new Object()”，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

软引用

描述一些还有用但并非必需的对象。在系统将要发生内存溢出异常之前，将软引用的对象列进回收范围之中进行第二次回收。如果回收之后还是没有足够的内存，才会抛出 OutOfMemoryError 异常。

弱引用

描述非必需对象，但其强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

虚引用

无法通过虚引用取得一个对象实例，设置虚引用的唯一目的是当这个对象被回收时收到一个系统通知。

垃圾收集算法

标记-清除算法

首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

不足

效率问题：标记和清除两个过程的效率都不高
空间问题：标记清除之后会产生大量不连续的内存碎片

在这里插入图片描述

复制算法

将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块的内存用完了，就将还存活的对象复制到另一块上面，然后一次性把已使用过的内存空间清理掉。这样每次都是对整个半区进行回收，也不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可。实现简单，运行高效。代价是将内存缩小为原来的一半。

在这里插入图片描述
商业虚拟机通常使用复制算法来回收新生代。新生代中的对象有 98% 是“朝生夕死”的，所以不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。当回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。

HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1。当 Survivor 空间不够用时，需要依赖其它内存（这里指老年代）进行分配担保。

标记-整理算法

标记的过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

在这里插入图片描述

分代收集算法

把 Java 堆内存分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

垃圾收集器

枚举根节点

可达性分析必须保证“一致性”，即分析期间整个执行系统看起来就像冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，这是导致 GC 进行时必须停顿所有 Java 执行线程（这件事被称为“Stop The World”）的一个重要原因。

当执行系统停顿下来的时候，不需要一个不漏地检查完所有执行上下文和全局引用。在 HotSpot 的实现中，使用一组称为 OopMap 的数据结构来达到这个目的。在类加载完成时，把对象内什么偏移量上是什么类型的数据计算出来。在 JIT 编译过程中，也会在特定位置记录下栈和寄存器中哪些位置是引用。通过解释 OopMap 就可以找到堆中的对象，这些对象就是GC Roots。这种方式也叫准确式GC。

Safepoint（安全点）

HotSpot 没有为每条指令都生成对应的 OopMap，只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来 GC，只有在到达安全点才能暂停。

Safepoint 的选定既不能太少以致于让 GC 等待时间太长（指令序列复用，例如方法调用，循环跳转，异常跳转），也不能过于频繁以致于过分增大运行时的负荷。

另一个需要考虑的问题是如何在 GC 发生时让所有线程都“跑”到最近的安全点上再停顿下来。有以下两个方案：

抢先式中断：GC 发生时，中断所有线程。如果有线程不在安全点上，恢复线程让它“跑到”安全点上。几乎没有虚拟机使用抢先式中断。
主动式中断：当 GC 需要中断线程时，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现标志为真时自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象时需要分配内存的地方。

Safe Region（安全区域）

线程处于 Sleep 状态或者 Blocked 状态，线程无法响应 JVM 的中断请求，这时候需要安全区域来解决。

安全区域指的是在一段代码片段中，引用关系不会发生辩护，在这个区域中的任意地方开始 GC 都是安全的。

在线程执行到安全区域中的代码时，首先标识自己已经进入了安全区域，在这段时间 JVM 要发起 GC 时，就不用管标识自己为安全区域状态的线程了。在线程要离开安全区域的时候，检查系统是否已经完成了根节点枚举（或者是整个 GC 过程），如果完成了，线程就继续执行，否则它必须等待直到收到可以安全离开安全区域的信号为止。

垃圾收集语境中的并行和并发
并行：多条垃圾收集线程并行工作，单此时用户线程仍然处于等待状态。
并发：用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续执行，而垃圾收集程序运行于另一个CPU 上。

HotSpot 虚拟机中的垃圾收集器

在这里插入图片描述

Serial / Serial Old

Serial 收集器使用复制算法，用于新生代。用一个 CPU 或者一条收集线程去完成垃圾收集工作，在进行垃圾收集的时候，必须暂停其他所有的工作线程，直到它收集结束。

Serial Old 收集器使用标记整理算法，用于老年代。

在这里插入图片描述

优点

简单高效，没有线程交互开销，专心垃圾收集。停顿时间短且不是频繁发生时使用。

适合运行在Client模式下，适合在单cpu环境下，不适合多线程环境

缺点

“Stop The World” 带给用户不良体验，停顿时间长难以忍受。

ParNew

ParNew 是 Serial 的多线程版本。

除了 Serial 之外，只有它能与 CMS 收集器配合工作。

CMS 是第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

在单 CPU 环境中 ParNew 不会有比 Serial 更好的效果。

在这里插入图片描述

Parrallel Scavenge / Parrallel Old

CMS 等收集器的目的是尽可能缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

停顿时间越短越适合与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量可以有效地利用 CPU 时间，尽快完成程序的运行任务，只要适合在后台运算而不需要太多交互的任务。

GC 停顿时间缩短是以牺牲吞吐量和新生代空间换来的。

Parrallel Scavenge 使用复制算法。Parrallel Old 是其老年代版本，使用多线程和“标记-整理”算法。

在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parrallel Scavenge + Parrallel Old 组合。

在这里插入图片描述

CMS (Concurrent Mark Sweep)

CMS 收集器是一种以获取最短回收停顿时间为目标的收集器，基于“标记-清除”算法实现。整个过程分为 4 个步骤：

初始标记

仅仅标记 GC Roots 能直接关联到的对象，速度很快。

并发标记

进行 GC Roots Tracing 的过程。

重新标记

修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。这一过程定顿时间一般比初始标记阶段稍长一点，但远比并发标记的时间短。

并发清理

GC 操作。

在这里插入图片描述

整个过程中耗时最长的并发标记和并发清理过程收集器线程都可以与用户线程一起工作。所以从总体上说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。

优点

并发收集，低停顿。

缺点

**对 CPU 资源敏感。**面向并发的程序都对 CPU 资源比较敏感。在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程（CPU 资源）而导致应用程序变慢，总吞吐量降低。
**CMS 收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生。**在并发清理阶段用户线程在继续运行，会产生浮动垃圾，所以必须为用户线程预留足够的内存空间。如果预留空间无法满足程序需要，就会出现“Concurrent Mode Failure”失败，将会临时启用 Serial Old 收集器重新精心老年代垃圾收集，这样停顿时间会很长。
**“标记-清除”算法会产生大量空间碎片。**分配大对象时，虽然有很大空间剩余，但无法找到连续空间分配当前对象，不得不提前触发一次 Full GC。

G1 (Garbage First)

G1 和 CMS 一样，也是一个以缩短停顿时间为目标的收集器。

G1 收集器的特点：

并行与并发：利用多个 CPU 缩短 Stop-The-World 的时间。
分代收集：不需要其它收集器配合就能管理整个 GC 堆。
空间整合：整体来看基于“标记-整理”，局部（两个 Region 之间）来看基于“复制算法”实现。 G1 不会产生内存空间碎片。
可预测的停顿：建立可预测的停顿时间模型，长度为 M 毫秒的时间片段内，垃圾收集时间不超过 N 毫秒。

将整个 Java 堆分成多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但不再是物理隔离的，都是一部分 Region（不需要连续）的集合。

G1 跟踪每个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的手机时间，优先回收价值最大的 Region（Garbage-First 名字的由来）。（以此来实现可预测停顿时间模型。）

G1 中每个 Region 都有一个与之对应的 Remembered Set，记录区域之间的对象相互引用信息，以此来保证不进行全堆扫描。

G1 收集器的运作分为以下几个步骤：

初始标记
并发标记
最终标记
筛选回收：首先对各个 Region 的回收价值和成本进行排序，根据用户期望的 GC 停顿时间制定回收计划。

内存分配与回收策略

Minor GC 和 Major GC (Full GC) 的区别
新生代 GC（Minor GC）：非常频繁，一般回收速度也比较快。
老年代 GC（Major GC / Full GC）：发生在老年代的垃圾回收，一般速度比 Minor GC 慢 10 倍以上。

对象主要分配在新生代的 Eden 区上，如果启动了本地线程分配缓冲，将按线程优先在 TLAB 上分配。少数情况下直接分配在老年代中。

TLAB
内存分配的动作，可以按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer）。

下面是几条普遍的内存分配原则：

对象优先在 Eden 分配

当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

-XX:+PrintGCDetail 打印日志参数
-Xms20M 堆最小值为 20M
-Xmx20M 堆最大值为 20M
-Xmn10M 10M 分配给新生代
-XX:SurvivorRatio=8 Eden 与一个 Survivor 的空间比例是 8:1

大对象直接进入老年代

典型的大对象就是很长的字符串和数组。

-XX:PretenureSizeThreshold 令大于这个设置值的对象直接在老年代分配。目的是避免在 Eden 和两个 Survivor 之间发生大量的内存复制。（新生代采用复制算法搜集内存）。

长期存活的对象将进入老年代

每个对象定义一个对象年龄（Age）计数器。对象在 Eden 出生并经过第一次 Minor GC 后仍然存货，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间，并且年龄设置为 1。在 Survivor 区中每熬过一次 Minor GC，年龄增加 1 岁。年龄增加到一定程度（默认 15 岁），就会被晋升到老年代。