当我们在讨论垃圾回收器时，往往也会涉及到很多的概念；譬如并行（Parallel）与并发（Concurrent）、Minor GC 与 Major/Full GC。

从不同角度分析垃圾回收器，可以将其分为不同的类型：

我们最常用的评价垃圾回收器的指标就是吞吐量与停顿时间：

具体的指标列举如下：

在对象查找算法的帮助下我们可以找到内存可以被使用的，或者说那些内存是可以回收，更多的时候我们肯定愿意做更少的事情达到同样的目的。

1999 年随 JDK1.3.1 一起来的是串行方式的 Serial GC，它是第一款垃圾回收器；此后，JDK1.4 和 J2SE1.3 相继发布。2002 年 2 月 26 日，J2SE1.4 发布；Parallel GC 和 Concurrent Mark Sweep (CMS)GC 跟随 JDK1.4.2 一起发布，并且 Parallel GC 在 JDK6 之后成为 HotSpot 默认 GC。这三个垃圾回收器也是各有千秋，Serial GC 适合最小化地使用内存和并行开销的场景、Parallel GC 适合最大化应用程序吞吐量的场景、CMS GC 适合最小化中断或停顿时间的场景。上图即展示了多种垃圾回收器之间的关系；不过随着应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有合适的回收器就不能保证应用程序正常进行，而经常造成 STW 停顿的回收器又跟不上实际的需求，所以才会不断地尝试对搜集器进行优化。Garbage First(G1)GC 正是面向这种业务需求所生，它是一个并行回收器，把堆内存分割为很多不相关的区间(Region)；每个区间可以属于老年代或者年轻代，并且每个年龄代区间可以是物理上不连续的。

关于标记阶段有几个关键点是值得注意的：

当标记阶段完成后，GC 开始进入下一阶段，删除不可达对象。

串行回收器主要有两个特点：第一，它仅仅使用单线程进行垃圾回收；第二，它独占式的垃圾回收。在串行回收器进行垃圾回收时，Java 应用程序中的线程都需要暂停，等待垃圾回收的完成，这样给用户体验造成较差效果。虽然如此，串行回收器却是一个成熟、经过长时间生产环境考验的极为高效的 回收器。新生代串行处理器使用复制算法，实现相对简单，逻辑处理特别高效，且没有线程切换的开销。在诸如单 CPU 处理器或者较小的应用内存等硬件平台不是特别优越的场合，它的性能表现可以超过并行回收器和并发回收器。在 HotSpot 虚拟机中，使用 -XX：+UseSerialGC 参数可以指定使用新生代串行回收器和老年代串行回收器。当 JVM 在 Client 模式下运行时，它是默认的垃圾回收器。老年代串行回收器使用的是标记-压缩算法。和新生代串行回收器一样，它也是一个串行的、独占式的垃圾回收器。由于老年代垃圾回收通常会使用比新生代垃圾回 收更长的时间，因此，在堆空间较大的应用程序中，一旦老年代串行回收器启动，应用程序很可能会因此停顿几秒甚至更长时间。虽然如此，老年代串行回收器可以 和多种新生代回收器配合使用，同时它也可以作为 CMS 回收器的备用回收器。若要启用老年代串行回收器，可以尝试使用以下参数：-XX:+UseSerialGC: 新生代、老年代都使用串行回收器。

Serial GC 的工作步骤如下所示：

Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量(Throughput)。Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在 JDK 1.6 中才开始提供的。使用 -XX:+UseParallelOldGC 可以在新生代和老生代都使用并行回收回收器，这是一对非常关注吞吐量的垃圾回收器组合，在对吞吐量敏感的系统中，可以考虑使用。参数 -XX:ParallelGCThreads 也可以用于设置垃圾回收时的线程数量。

Parallel GC 的工作步骤如下所示：

CMS（Concurrent Mark-Sweep）是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器，适用于对停顿比较敏感，并且有相对较多存活时间较长的对象(老年代较大)的应用程序；不过 CMS 虽然减少了回收的停顿时间，但是降低了堆空间的利用率。CMS GC 采用了 Mark-Sweep 算法，因此经过 CMS 收集的堆会产生空间碎片；为了解决堆空间浪费问题，CMS 回收器不再采用简单的指针指向一块可用堆空间来为下次对象分配使用。而是把一些未分配的空间汇总成一个列表，当 JVM 分配对象空间的时候，会搜索这个列表找到足够大的空间来存放住这个对象。另一方面，由于 CMS 线程和应用程序线程并发执行，CMS GC 需要更多的 CPU 资源。同时，因为 CMS 标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在 CMS 回收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。也就是说，CMS 不会在老年代满的时候才开始收集。相反，它会尝试更早的开始收集，已避免上面提到的情况：在回收完成之前，堆没有足够空间分配！默认当老年代使用 68%的时候，CMS 就开始行动了。– XX:CMSInitiatingOccupancyFraction =n 来设置这个阀值。

CMS GC 工作步骤如下所示：

G1 GC 是 JDK 1.7 中正式投入使用的用于取代 CMS 的压缩回收器，它虽然没有在物理上隔断新生代与老生代，但是仍然属于分代垃圾回收器；G1 GC 仍然会区分年轻代与老年代，年轻代依然分有 Eden 区与 Survivor 区。G1 GC 首先将堆分为大小相等的 Region，避免全区域的垃圾收集，然后追踪每个 Region 垃圾堆积的价值大小，在后台维护一个优先列表，根据允许的收集时间优先回收价值最大的 Region；同时 G1 GC 采用 Remembered Set 来存放 Region 之间的对象引用以及其他回收器中的新生代与老年代之间的对象引用，从而避免全堆扫描。G1 GC 的分区示例如下图所示：

随着 G1 GC 的出现，Java 垃圾回收器通过引入 Region 的概念，从传统的连续堆内存布局设计，逐步走向了物理上不连续但是逻辑上依旧连续的内存块；这样我们能够将某个 Region 动态地分配给 Eden、Survivor、老年代、大对象空间、空闲区间等任意一个。每个 Region 都有一个关联的 Remembered Set(简称 RS)，RS 的数据结构是 Hash 表，里面的数据是 Card Table (堆中每 512byte 映射在 card table 1byte)。简单的说 RS 里面存在的是 Region 中存活对象的指针。当 Region 中数据发生变化时，首先反映到 Card Table 中的一个或多个 Card 上，RS 通过扫描内部的 Card Table 得知 Region 中内存使用情况和存活对象。在使用 Region 过程中，如果 Region 被填满了，分配内存的线程会重新选择一个新的 Region，空闲 Region 被组织到一个基于链表的数据结构(LinkedList)里面，这样可以快速找到新的 Region。

总结而言，G1 GC 的特性如下：

G1 GC 的工作步骤如下所示：

与标记对象的传统算法相比，ZGC 在指针上做标记，在访问指针时加入 Load Barrier（读屏障），比如当对象正被 GC 移动，指针上的颜色就会不对，这个屏障就会先把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速，而不存在为了保持应用与 GC 一致而粗暴整体的 Stop The World。