CMS：低延迟
- 在 JDK1.5 时，HotSpot 推出了 CMS 收集器，CMS 收集器是 HotSpot 虚拟机中第一款真正意义上的
并发收集器，它第一次实现了让垃圾收集线程和用户线程同时工作 - CMS 收集器关注尽可能地降低用户线程的停顿时间，停顿时间越短，用户的体验越好
- CMS 收集器采用
标记-清除算法和STW机制来回收内存 - CMS 作为老年代的收集器无法与之前的新生代收集器 Parallel Scavenge 配合工作，所以在 JDK1.5 时使用 CMS 收集老年代，新生代只可以选择 ParNew 或者 Serial
CMS收集过程
CMS收集过程较为复杂，分为4个阶段：
- 初始标记：会出现 STW，所有工作线程停止，该阶段主要
标记与GC Roots能直接关联的对象，由于直接关联的对象很少，所以速度很快 - 并发标记：从GC Roots的
直接关联对象开始遍历整个对象图的过程，这个阶段比较耗时但是不需要暂停用户线程 - 重新标记：在并发标记阶段，由于用户线程和垃圾收集线程同时运行，因此在这个阶段
修正并发标记阶段因为用户线程运行而产生变动的对象的标记，这个阶段速度虽然比初始标记阶段慢点，但是比并发标记阶段快多了 - 并发清除：
清除标记阶段判断的已经死亡的对象，释放内存空间
虽然 CMS 是并发收集器，但是仍然存在短暂的 STW 时间
并且在 CMS 回收过程中，需要确保用户线程有足够的内存可以使用，因此在堆内存使用率达到某一阈值，就需要开始内存回收，如果 CMS 运行期间预留的内存不够用户线程使用的话，会临时启动 Serial Old 收集器来回收老年代。
优点
- 并发收集
- 低延迟
缺点
- 使用标记-清除算法，会有内存碎片。在无法分配大对象的情况下，不得不提前触发Full GC
- CMS收集器对CPU资源非常敏感。虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用线程变慢，总吞吐量降低
- CMS收集器无法处理浮动垃圾。如果在并发标记阶段产生新的垃圾对象，CMS收集器将无法对这些垃圾对象进行标记，只能等下一次执行GC的时候进行回收
JDK后续版本中CMS的变化
- JDK9 中，CMS 被标记为 Deprecate，即 CMS 未来将会被废弃
- JDK14 中，删除 CMS 垃圾收集器
G1：区域化分代式
G1（Garbage-First）垃圾收集器是在 Java7 update4 之后引入的一个新的垃圾收集器，它开创了收集器面向局部收集的设计思路和基于 Region 的内存布局形式
- G1的出现就是为了适应
不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间，同时兼顾良好的吞吐量 - G1是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU以及大容量内存的机器，兼顾了低GC停顿时间和高吞吐量
- 在 JDK1.7 正式启用，是 JDK 9以后的默认垃圾收集器，取代了 CMS 以及 Parallel+Parallel Old 的组合，被 Oracle 官方称为“全功能的垃圾收集器”
为什么叫做 Garbage First 呢？
- Garbage First 也就是垃圾优先，G1 是一个并行回收器，将堆内存分割为多个不相关区域，称为 Region，使用不同的 Region 来表示 Eden、Survivor0、Survivor1、老年代等
- G1有计划地避免在整个 Java 堆中进行全区域的垃圾收集，G1跟踪各个Region的垃圾堆积的价值大小，在后台维护一个优先级列表，每次根据允许的收集时间，优先回收价值最大的Region，G1侧重于回收垃圾最大量的区间，因此称之为Garbage-First 垃圾优先
G1 应用场景
- 服务端应用，针对具有大内存、多处理器的机器
- 最主要的应用是需要低 GC 延迟、并且具有大堆的应用程序
- HotSpot 除了 G1，其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作，而 G1 采用应用线程承担后台运行的 GC 工作，即当 JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程
G1 执行过程
- 初始标记：标记一下 GC Roots 能直接关联到的对象，需要停顿线程，但耗时很短
- 并发标记：是从 GC Roots 开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
- 最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录
- 筛选回收：对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划
Humongous 区域：
在G1中，有一种特殊的区域叫Humongous区域
- 如果一个对象占用的空间超过了分区容量 50% 以上，G1 收集器就认为这是一个巨型对象。 这些巨型对象，默认直接会被分配在老年代
- 但是，如果是一个短期存在的巨型对象，在分区之间来回拷贝，就会对垃圾收集器造成负面影响。为了解决这个问题，G1 划分了 Humongous 区，它用来专门存放巨型对象。如果一个 H 区装不下一个巨型对象，那么 G1 会寻找连续的 H 分区来存储
G1 相关参数：
-XX:+UseG1GC
# 使用 G1 垃圾收集器
-XX:MaxGCPauseMillis=
# 设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认值是 200 毫秒。
-XX:G1HeapRegionSize=n
# 设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。
# 目标是根据最小的 Java 堆大小划分出约 2048 个区域。
# 默认是堆内存的1/2000。
-XX:ParallelGCThreads=n
# 设置并行垃圾回收线程数，一般将n的值设置为逻辑处理器的数量，建议最多为8。
-XX:ConcGCThreads=n
# 设置并行标记的线程数。将n设置为ParallelGCThreads的1/4左右。
-XX:InitiatingHeapOccupancyPercent=n
# 设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。优势
并行与并发
- 并行：G1 在回收期间，可以有多个 GC 线程同时工作，此时用户线程 STW
- 并发：G1 部分工作可以和应用程序同时执行
分代收集
- G1 将堆空间分为若干个区域 Region，这些区域包含了逻辑上的新生代和老年代
- 之前的垃圾收集器要么工作在新生代，要么工作在老年代，而 G1 同时
兼顾了新生代和老年代
空间整合
- G1 将堆内存划分为若干 Region，内存回收以 Region 为单位，Region 之间是
复制算法，整体上可以看作是标记-压缩算法，两种算法都可以避免出现内存碎片
可预测的停顿时间模型
- G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过N毫秒
ZGC：低延迟
在 JDK11 中引入的一种可扩展的低延迟垃圾收集器，在 JDK15 中发布稳定版
ZGC 的目标是在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小都可以把垃圾收集的停顿时间限制在 10 ms 以内（在 JDK16 之前是 10 ms，在 JDK16 之后目标是 1 ms 的低延迟）的低延迟
ZGC 收集器也是基于 Region 内存布局，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低延迟为首要目标的一款垃圾收集器。ZGC 的核心是一个并发垃圾收集器，这意味着所有繁重的工作都在 Java 线程继续执行的同时完成。这极大地限制了垃圾收集对应用程序响应时间的影响
ZGC 的关键技术
ZGC 通过 染色指针 和 读屏障 技术解决了对象转移过程中准确访问对象的问题，实现了垃圾回收过程中对象的并发转移
具体细节这里先略过，可以参考美团技术团队的文章新一代垃圾回收器ZGC的探索与实践