俗说 GC 之 Heap 区内存模型的演进

1 篇首

最近看到 GC 这个异常古老的话题又被抛了出来，OpenJDK11 中出现了大道至简、返璞归真的 Epsilon GC 垃圾回收器，ZGC，Shenandoah GC 作为在 G1 的基础之上的两个分别合入了 OpenJDK11 和 OpenJDK12 的项目，两个项目的代号分别为分别为 JEP333、JEP189，这两款目前正在发展中的垃圾回收器成为了与 CMS、G1 两款早期并发回收器进行性能对比的主角。然后我就突然找到了一个主题，那就是比较两款垃圾回收器的性能就是在比较什么？要比较的究竟是哪些性能？是否有一款垃圾回收器能够在性能维度的方方面面碾压另一款垃圾回收器？这个问题我心里有自己的一些看法。我也一直在思考，在 JVM 这方面，周志明老师的大作《深入理解 Java 虚拟机》第三版于2019年中完成，其中对 ZGC，ShenandoahGC 两个面向低延时的垃圾回收器已经做了详细的原理解析，是否还需要再写文章做一些说明呢。但是转念又想，对于 JVM 垃圾回收器这部分虽然有如此多的珠玉在前，但是如果我自己的观点哪怕只有一点点是有价值的，那么不分享出来让大家看到也是一种知识价值的浪费。所以几番犹豫后，还是决定把自己对于 JVM GC 的理解写下来分享给大家。

那么我们说的 JVM 垃圾回收器不可能的三角是个什么规模的事情呢？先看一张图，我们都知道，我们可以把 JDK、JRE、JVM 的关系这样来表示：

而我们本文需要讨论的内容仅仅是 Java HotSpot Client and Server VM 中的一部分：垃圾回收器

描述一个垃圾回收器最重要的指标是哪些呢？

按照周志明老师在《深入理解 Java 虚拟机》2019年第三版中的描述:
分别是——

a. Heap 区间的内存占用(堆外辅助内存空间大小)
b. 无 GC 情况下的吞吐量(读写屏障的影响)
c. 延迟停顿( STW 时长)，这三个指标形成了一个类似于事务的 CAP 理论的不可能三角。

我们在形容垃圾回收器的时候所采用的所有维度说明，都是为了解决这三件事之间的矛盾，无外乎是选择谁、牺牲谁或者给谁多点、给谁少点的问题。

再看一张图，我们在讨论垃圾回收器的时候通常会讨论如下问题：

下面我们对这三组分类：内存模型分类、回收算法按执行过程分类和回收算法按算法理念分类，逐一做一个简单说明，本文限于篇幅，核心关注点是按照内存模型进行分类。

根据 java 虚拟机规范，java 虚拟机管理的内存将分为下面五大区域。

严格来说，下面的图不能够叫内存模型，应该叫内存的划分：

JVM 垃圾回收器主要管理的是这五大内存区域中的堆区间，我们所说的内存模型主要说的就是 JVM 堆区的内存模型。

对于 JVM 来说，通过我的总结，堆内存空间的类型大致分为四类：

A.分代模型 B.分代分区模型 C.分区模型 D.分层分区模型

援引我司冯志明老师对于内存模型的一段解释性说明，这段说明娓娓道来、简单明确，不援引出来分享给大家十分可惜：

内存模型（也叫内存一致性模型）这个概念是来自硬件的。是为了解决 CPU 缓存和内存一致性问题所构造出来的一个概念。
因为有读写两个操作，所以一致性场景有4个：LoadLoad，LoadStore，StoreLoad，StoreStore 。
每款 CPU 都有自己的内存模型。有的是强一致性模型，比如 x86，就只有 StoreLoad 场景下，会有一致性问题。有的是弱一致性模型，比如 ARMv7，就是4个场景都有一致性的问题。

一致性模型越弱，CPU 结构会越简单，性能也会越高。但是对于软件开发者的要求也越高。
Linux 提供了3种汇编原语，来应对不同的一致性场景，那就是：写屏障，读屏障和全屏障。就是为了针对不同 CPU 下，不同内存模型下，做好数据同步操作。
JVM 是软件，也是虚拟机（虚拟的 CPU），所以 JVM 也一定也会有自己的内存模型（JMM）。
这个内存模型还要涵盖所有 CPU 下的内存模型，所以 JMM 就更通用也更晦涩。

所以以前的 JMM 定义了8大操作（已经过时的概念