垃圾收集器就是内存回收操作的具体实现，HotSpot 里足足有 7 种，为啥要弄这么多，因为它们各有各的适用场景。有的属于新生代收集器，有的属于老年代收集器，所以一般是搭配使用的（除了万能的 G1）。关于它们的简单介绍以及分类请见下图。
Serial 收集器
Serial 收集器是最基本，历史最久的收集器，但是它是单线程的收集器，只会使用一个 CPU 或者一个收集线程去工作，而且它在进行垃圾收集的时候，必须暂停其他所有的工作线程，直到它收集结束。
Serial 收集器是虚拟机在 Client 模式下的默认新生代收集器，它的优势是简单高效，在单 CPU 模式下很牛。对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集，所以可以获得最高的单线程垃圾收集效率。
新生代采用标记-复制算法，老年代采用标记-整理算法。
ParNew 收集器
ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。
它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后面会介绍到）配合工作。
新生代采用标记-复制算法，老年代采用标记-整理算法。
Parallel Scavenge 收集器
Parallel Scavenge 收集器也是使用标记-复制算法的多线程收集器，它看上去几乎和 ParNew 都一样。 那么它有什么特别之处呢？
Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。
新生代采用标记-复制算法，老年代采用标记-整理算法。
这是 JDK1.8 默认收集器
使用 java -XX:+PrintCommandLineFlags -version 命令查看：
JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old，如果指定了-XX:+UseParallelGC 参数，则默认指定了-XX:+UseParallelOldGC，可以使用-XX:-UseParallelOldGC 来禁用该功能
Serial Old 收集器
Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。
Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
CMS 收集器（并发低停顿收集器）
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。
CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
初始标记
产生GC中断（Stop The World），暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快。
并发标记
同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记
重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。
并发清除
开启用户线程，同时 GC 线程开始对未标记的区域做清扫。
缺点
从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：
对 CPU 资源敏感
在并发阶段，虽然他不会导致用户线程停顿，但是因为它占用了一部分 CPU 资源从而导致系统变慢，总吞吐量降低。默认的回收线程数量是（CPU数量+3 / 4）。
无法处理浮动垃圾
什么是浮动垃圾？由于 CMS 并发清除的阶段用户线程还在运行，只要运行就会有新的垃圾产生，但是此时已经早已经标记完成了，所以只能留到下次 GC 进行清理，那么这些垃圾就属于浮动垃圾。
由于垃圾的收集阶段用户线程还需要执行，所以 CMS 收集器不能等到老年待几乎快用完了才进行收集，有个阈值，JDK1.5是 68%，JDK1.6是 92%。那么如果在 CMS 运行期间预留的内存空间不能满足用户线程的需要，那么就会出现 “Concurrent Model Failure” 的失败情况，此时就需要开启预备方案，临时启用 Serial Old 收集器来重新对老年代进行垃圾收集。但是这样停顿的时间就很长了。所以这个阈值不能太低，也不能太高。
产生大量空间碎片
它使用的回收算法是 “标记-清除” 算法，会导致收集结束时会有大量空间碎片产生。空间碎片过多则会导致在分配大对象的时候找不到足够连续的空间，从而不得不触发一次 Full GC。
为了解决这个问题，CMS 提供了一个参数用于控制当 CMS 收集器顶不住要进行 Full GC 的时候开启内存碎片的合并整理过程，但是这个过程是不会并发进行的，所以停顿时间会变长。
G1 收集器
G1 (Garbage-First) 是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器，以极高概率满足 GC 停顿时间要求的同时，还具备高吞吐量性能特征。
G1 收集器被视为 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 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。
G1 收集器的运作大致分为以下几个步骤：
- 初始标记：需要 GC 中断，耗时短。此个过程只是标记一下 GC Root 能直接关联的对象，并且修改 TAMS 指针的值，方便在并发标记阶段用户线程可以方便的在 Region 中分配新对象。
- 并发标记：从 GC Root 开始对堆中对象进行可达性分析，找出要回收的对象，此过程耗时较长，可以与用户线程并发执行。用户进程此时创建的新对象会分配在相关 Region 的两个 TAMS 指针位置上面。G1 收集器默认这个地址上的对象是存活的，不会将他们进行回收。
- 最终标记：需要 GC 中断。用于处理并发阶段结束后遗留下来的少量原始快照记录。
- 筛选回收：需要 GC 中断，对各个 Region 的回收价值和成本进行排序，根据期望的停顿时间来制定回收计划，把决定回收的那一部分的 Region 对象复制到空的 Region 中，然后清理掉原来旧的 Region 的全部空间。
G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来) 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。
从 JDK9 开始，G1 垃圾收集器成为了默认的垃圾收集器。
ZGC 收集器
ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器。ZGC 也采用 “标记-复制” 算法，不过 ZGC 对该算法做了重大改进：ZGC 在标记、转移和重定位阶段几乎都是并发的，这是 ZGC 实现停顿时间小于10ms目标的最关键原因。
ZGC 通过着色指针和读屏障技术，解决了转移过程中准确访问对象的问题，实现了并发转移。大致原理描述如下：并发转移中“并发”意味着 GC 线程在转移对象的过程中，应用线程也在不停地访问对象。假设对象发生转移，但对象地址未及时更新，那么应用线程可能访问到旧地址，从而造成错误。而在 ZGC 中，应用线程访问对象将触发“读屏障”，如果发现对象被移动了，那么“读屏障”会把读出来的指针更新到对象的新地址上，这样应用线程始终访问的都是对象的新地址。那么，JVM是如何判断对象被移动过呢？就是利用对象引用的地址，即着色指针。
ZGC 的运作过程大致可分为四个阶段，这四个阶段都是可以并发执行的！分别是：
- 并发标记
- 并发预备重分配
- 并发重分配
- 并发重映射
