Java各大垃圾回收器
上面的图片展示了Java的垃圾回收器，他们配合使用是有条件的，每一种都会有不同的使用方式，选择哪一种要根据业务的需要，环境不同则使用不同。下面简单的介绍他们的每一个特点：
1 Serial 收集器
Serial(串行)收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是 一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成 垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程( "Stop The World"、STW )，直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。
虚拟机的设计者们当然知道 Stop The World 带来的不良用户体验，所以在后续的垃圾收集器设 计中停顿时间在不断缩短(仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续)。
但是 Serial 收集器有没有优于其他垃圾收集器的地方呢?当然有，它简单而高效(与其他收集器 的单线程相比)。Serial 收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial 收集器对于运行在 Client 模式下的虚拟机来说是个不错的选择。
2 ParNew 收集器
ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为(控制参数、收集算法、回收策略等等)和 Serial 收集器完全一样。新生代采用复制算法，老年代采用标记-整理算法。
它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收 集器(真正意义上的并发收集器，后面会介绍到)配合工作。
并行和并发概念补充:
并行(Parallel) :指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行，可能会交 替执行)，用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。
3 Parallel Scavenge 收集器
Parallel Scavenge 收集器也是使用复制算法的多线程收集器，它看上去几乎和 ParNew 都一样。那么它有什么特别之处呢?
-XX:+UseParallelGC
使用 Parallel 收集器+ 老年代串行
-XX:+UseParallelOldGC
使用 Parallel 收集器+ 老年代并行
Parallel Scavenge 收集器关注点是吞吐量(高效率的利用 CPU)。CMS 等垃圾收集器的关注 点更多的是用户线程的停顿时间(提高用户体验)。所谓吞吐量就是 CPU 中用于运行用户代码 的时间与 CPU 总消耗时间的比值。Parallel Scavenge 收集器提供了很多参数供用户找到最合适
的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错 的选择。
新生代采用复制算法，老年代采用标记-整理算法。
4 Serial Old 收集器
Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。
5 Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
6 CMS 收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它 非常符合在注重用户体验的应用上使用。
CMS(Concurrent Mark Sweep)收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器， 它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 “标记-清除”算法实现的，它的 运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤:
初始标记: 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ;
并发标记: 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结 束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引 用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引 用更新的地方。
重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生 变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍⻓， 远远比并发标记阶段时间短
并发清除: 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。
从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下 面三个明显的缺点:
对 CPU 资源敏感; 无法处理浮动垃圾; 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
7 G1 收集器
G1 (Garbage-First) 是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征. 被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备一下特点:
并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU(CPU 或者 CPU 核心)来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。
分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
空间整合：与 CMS 的“标记--清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的 收集器;从局部上来看是基于“复制”算法实现的。
可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指 定在一个⻓度为 M 毫秒的时间片段内。
G1 收集器的运作大致分为以下几个步骤:
初始标记
并发标记
最终标记
筛选回收
G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字 Garbage-First 的由来)。这种使用 Region 划分内存空间以及有优先 级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率(把内存化整为零)。
8 低延时垃圾回收器
全并发的ZGC：所谓的低延时，也就是说无论内存空间多大，都可以在10ms内回收完毕。它采用的是读屏障和着色指针实现的。
与CMS中的ParNew和G1类似，ZGC也采用标记-复制算法，不过ZGC对该算法做了重大改进：ZGC在标记、转移和重定位阶段几乎都是并发的，这是ZGC实现停顿时间小于10ms目标的最关键原因。
ZGC垃圾回收周期如下图所示：
ZGC只有三个STW阶段：初始标记，再标记，初始转移。其中，初始标记和初始转移分别都只需要扫描所有GC Roots，其处理时间和GC Roots的数量成正比，一般情况耗时非常短；再标记阶段STW时间很短，最多1ms，超过1ms则再次进入并发标记阶段。即，ZGC几乎所有暂停都只依赖于GC Roots集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加。与ZGC对比，G1的转移阶段完全STW的，且停顿时间随存活对象的大小增加而增加。
(PS：https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html)