如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。虚拟机具体如何进行内存回收动作，是由虚拟机所采用的GC收集器所决定的，《Java虚拟机规范》中对垃圾收集器应该如何实现并没有做出任何规定，因此不同的厂商、不同版本的虚拟机所包含的垃圾收集器都可能会有很大差别，不同的虚拟机一般也都会提供各种参数供用户根据自己的应用特点和要求组合出各个内存分代所使用的收集器。这里讨论的是在JDK 7 Update 4之后（在这个版本中正式提供了商用的G1收集器，此前G1仍处于实验状态）、JDK 11正式发布之前，OracleJDK中的HotSpot虚拟机[1]所包含的全部可用的垃圾收集器。

上图中的7个收集器，分为两块：新生代收集器，老年代收集器。如果两个收集器之间存在连线，则说明它们之间可以搭配使用。在介绍这些收集器各自的特性之前，让我们先来明确一个观点：虽然我们会对各个收集器进行比 较，但并非为了挑选一个最好的收集器出来，虽然垃圾收集器的技术在不断进步，但直到现在还没有最好的收集器出现，更加不存在“万能”的收集器，所以我们选择的只是对具体应用最合适的收集器。

由于维护和兼容性测试的成本，在JDK 8 时将 Serial+CMS、 ParNew+Serial Old 这两个组合声明为废弃（ JEP 173 ），并在 JDK 9 中完全取消了这些组合的支持（JEP214 ）。

 1、Serial收集器

Serial收集器使用“复制”算法，是一个单线程的收集器,但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。“Stop The World”这个名字也许听起来很酷,但这项工作实际上是由虚拟机在后台自动发起和自动完成的,在用户不可见的情况下把用户正常工作的线程全部停掉,这对很多应用来说都是难以接受的。

它是虚拟机运行在 Client模式(JDK6)下的默认新生代收集器。对于内存资源受限的环境，它是所有收集器里额外内存消耗（Memory Footprint）最小的；它也有着优于其他收集器的地方:简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说, Serial收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中,分配给虚拟机管理的内存一般来说不会很大,收集几十兆甚至一两百兆的新生代(仅仅是新生代使用的内存,桌面应用基本上不会再大了),停顿时间完全可以控制在几十毫秒最多一百多毫秒以内,只要不是频繁发生,这点停顿是可以接受的。所以,Serial收集器对于运行在client模式下的虚拟机来说是一个很好的选择。

2、ParNew收集器

ParNew收集器其实就是Seria收集器的多线程版本,除了使用多条线程进行垃圾收集之外,其余行为包括Serial收集器可用的所有控制参数(例如:-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、 Stop The World、对象分配规则、回收策略等都与 Serial收集器完全一样,在实现上,这两种收集器也共用了相当多的代码。 

ParNew收集器除了多线程收集之外,其他与 Serial收集器相比并没有太多创新之处,但它却是许多运行在 Server模式下的虚拟机中首选的新生代收集器,其中有一个与性能无关但很重要的原因是,除了 Seria收集器外,目前只有它能与CMS收集器配合工作。在JDK1.5时期, HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器CMS收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发(Concurrent)收集器,它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。

ParNew收集器也是使用-XX:+UseConcMarkSweepGC选项后的默认新生代收集器,也可以使用-XX:+UseParNewGC选项来强制指定它。ParNew收集器在单CPU的环境中绝对不会有比 Serial收集器更好的效果,甚至由于存在线程交互的开销,该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越 Serial收集器。当然,随着可以使用的CPU的数量的增加,它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同,在CPU非常多的环境下,可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

从 ParNew 收集器开始，后面还将会接触到若干款涉及 “ 并发 ” 和 “ 并行”概念的收集器。 在大家可能产生疑惑之前，有必要先解释清楚这两个名词。并行和并发都是并发编程中的专业名词， 在谈论垃圾收集器的上下文语境中，它们可以理解为：

并行（ Parallel）：并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线 程在协同工作，通常默认此时用户线程是处于等待状态。

并发（Concurrent）：并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行。由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于 垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。

3、Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器,它也是使用标记-复制算法的收集器,又是并行的多线程收集器，特点是它的关注点与其他收集器不同,CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而 Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。

吞吐量=运行用户代码时间/(运行用户代码时间+运行垃圾收集时间)

停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户体验,而高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的 -XX:GCTimeRatio参数。

MaxGCPausemillis参数允许的值是一个大于0的毫秒数,收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快,GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的:系统把新生代调小一些,收集300MB新生代肯定比收集500MB快吧,这也直接导致垃圾收集发生得更频繁一些,原来10秒收集一次、每次停顿100毫秒,现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降,但吞吐量也降下来了。

GCTime Ratio参数的值应当是一个大于0且小于100的整数,也就是垃圾收集时间占总时间的比率,相当于是吞吐量的倒数。如果把此参数设置为19,那允许的最大GC时间就占总时间的5%(即1/(1+19),默认值为99,就是允许最大1%(即1/(1+99))的垃圾收集时间。

由于与吞吐量关系密切, Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。

除上述两个参数之外, Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数,当这个参数打开之后,就不需要手工指定新生代的大小(-Xmn)、Eden与 Survivor区的比例(-XX:Survivorratio、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量,这种调节方式称为GC自适应的调节策略( GC Ergonomics)。如果对于收集器运作原来不太了解,手工优化存在困难的时候,使用 Parallel Scavenge收集器配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好(如-Xmx设置最大堆),然后使用 MaxGCPausemillis参数(更关注最大停顿时间)或 GCTimeRatio
(更关注吞吐量)参数给虚拟机设立一个优化目标,那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是 Parallel Scavenge收集器与 ParNew收集器的一个重要区别。

4、Serial Old收集器

Serial Old是 Serial收集器的老年代版本,它同样是一个单线程收集器,使用“标记一整理”算法。这个收集器的主要意义也是在于给 Client模式下的虚拟机使用。如果在 Server模式下,那么它主要还有两大用途:一种用途是在JDK1.5以及之前的版本中与 Parallel Scavenge收集器搭配使用,另一种用途就是作为CMS收集器的后备预案,在并发收集发生Concurrent mode failure时使用。

需要说明一下， Parallel Scavenge 收集器架构中本身有 PS MarkSweep收集器来进行老年代收集，并非 直接调用 Serial Old 收集器，但是这个 PS MarkSweep 收集器与 Serial Old的实现几乎是一样的，所以在官 方的许多资料中都是直接以 Serial Old 代替 PS MarkSweep 进行讲解

5、Parallel Old收集器

Parallel Old是 Parallel Scavenge收集器的老年代版本,使用多线程和“标记一整理”算法。这个收集器是在JDK1.6中才开始提供的,在此之前,新生代的 Parallel Scavenge收集器一直处于比较尴尬的状态。原因是,如果新生代选择了 Parallel Scavenge收集器,老年代除了 Serial Old( PS MarkSweep)收集器外别无选择(还记得上面说过 Parallel Scavenge收集器无法与CMS收集器配合工作吗?)。由于老年代 Serial Old收集器在服务端应用性能上的拖累”,使用了 Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果,由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力,在老年代很大而且硬件比较高级的环境中,这种组合的吞吐量甚至还不一定有 ParNew加CMS的组合“给力”直到 Parallel Old收集器出现后,“吞吐量优先”收集器终于有了比较名副其实的应用组合,在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑 Parallel Scavenge加 Parallel Old收集器。 

6、CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

从名字(包含“Mark Sweep”)上就可以看出,CMS收集器是基于“标记一清除”算法实现的,它的运作过程相对于前面几种收集器来说更复杂一些,整个过程分为4个步骤,包括:

• 初始标记(CMS initial mark)
• 并发标记(CMS concurrent mark)
• 重新标记(CMS remark)
• 并发清除(CMS concurrent sweep)

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录（详见并发的可达性分析增量更新的讲解），这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作,所以,从总体上来说,CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS主要优点:并发收集、低停顿。但是CMS还远达不到完美的程度,它有以下3个明显的缺点:

• CMS收集器对CPU资源非常敏感。在并发阶段,它虽然不会导致用户线程停顿,但是会因为占用了一部分线程(或者说CPU资源)而导致应用程序变慢,总吞吐量会降低。CMS默认启动的回收线程数是(CPU数量+3)/4,也就是当CPU在4个以上时,并发回收时垃圾收集线程不少于25%的CPU资源,并且随着CPU数量的增加而下降。但是当CPU不足4个(譬如2个)时,CMS对用户程序的影响就可能变得很大,如果本来CPU负载就比较大,还分出一半的运算能力去执行收集器线程,就可能导致用户程序的执行速度忽然降低了50%,其实也让人无法接受。为了缓解这种情况，虚拟机提供了一种称为“增量式并发收集器”（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器变种，所做的事情和以前单核处理器年代PC机操作系统靠抢占式多任务来模拟多核并行多任务的思想一样，是在并发标记、清理的时候让收集器线程、用户线程交替运行，尽量减少垃圾收集线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得较少一些，直观感受是速度变慢的时间更多了，但速度下降幅度就没有那么明显。实践证明增量式的CMS收集器效果很一般，从JDK 7开始，i-CMS模式已经被声明为“deprecated”，即已过时不再提倡用户使用，到JDK 9发布后i-CMS模式被完全废弃。
• CMS收集器无法处理浮动垃圾(Floating Garbage),可能出现“Concurrent mode Failure”失败而导致另一次 Full GC的产生。由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好留待下一次GC时再清理掉。这部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行,那也就还需要预留有足够的内存空间给用户线程使用,因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,需要预留一部分空间提供并发收集时的程序运作使用。在JDK1.5的默认设置下,CMS收集器当老年代使用了68%的空间后就会被激活,这是一个偏保守的设置,如果在应用中老年代增长不是太快,可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比,以便降低内存回收次数从而获取更好的性能,在JDK1.6中,CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要,就会出现一次“Concurrent mode failure”失败,这时虚拟机将启动后备预案:临时启用 Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高很容易导致大量“ Concurrent Mode Failure”失败,性能反而降低。
• CMS是一款基于“标记一清除”算法实现的收集器,这意味着收集结束时会有大量空间碎片产生。空间碎片过多时,将会给大对象分配带来很大麻烦,往往会出现老年代还有很大空间剩余,但是无法找到足够大的连续空间来分配当前对象,不得不提前触发一次 Full GC。为了解决这个问题,CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数(默认就是开启的，此参数从JDK 9开始废弃),用于在CMS收集器顶不住要进行 FulI GC时开启内存碎片的合并整理过程,内存整理的过程是无法并发的,空间碎片问题没有了,但停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction（此参数从JDK 9开始废弃）,这个参数是用于设置执行多少次不压缩的Full GC后,跟着来一次带压缩的(默认值为0,表示每次进入 Full GC时都进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理）。

7、G1收集器

G1 将堆内存 “ 化整为零 ” 的 “ 解题思路 ”，看起来似乎没有太多令人惊讶之处，也完全不难理解，但其中的实现细节可是远远没有想象中那么简单，否则就不会从 2004 年 Sun 实验室发表第一篇关于 G1的论文后一直拖到 2012 年 4 月 JDK 7 Update 4 发布，用将近 10 年时间才倒腾出能够商用的 G1收集器来。G1 收集器至少有（不限于）以下这些关键的细节问题需要妥善解决：

譬如，将 Java 堆分成多个独立 Region 后， Region 里面存在的跨 Region引用对象如何解决？解决的思路我们已经知道（见 3.3.1 节和 3.4.4 节）：使用记忆集避免全堆作为 GC Roots 扫描，但在 G1收集器上记忆集的应用其实要复杂很多，它的每个 Region 都维护有自己的记忆集，这些记忆集会记录下别的Region指向自己的指针，并标记这些指针分别在哪些卡页的范围之内。 G1的记忆集在存储结构的本质上是一种哈希表， Key 是别的 Region 的起始地址， Value是一个集合，里面存储的元素是卡表的索引号。这种 “ 双向 ” 的卡表结构（卡表是 “ 我指向谁 ” ，这种结构还记录了 “ 谁指向我 ”）比原来的卡表实现起来更复杂，同时由于 Region 数量比传统收集器的分代数量明显要多得多，因此 G1收集器要比其他的传统垃圾收集器有着更高的内存占用负担。根据经验， G1 至少要耗费大约相当于 Java 堆容量 10% 至 20%的额外内存来维持收集器工作。

譬如，在并发标记阶段如何保证收集线程与用户线程互不干扰地运行？这里首先要解决的是用户线程改变对象引用关系时，必须保证其不能打破原本的对象图结构，导致标记结果出现错误，该问题的解决办法笔者已经抽出独立小节来讲解过（见 3.4.6 节并发的可达性分析）： CMS 收集器采用增量更新算法实现，而G1收集器则是通过原始快照（ SATB）算法来实现的。此外，垃圾收集对用户线程的影响还体现在回收过程中新创建对象的内存分配上，程序要继续运行就肯定会持续有新对象被创建， G1 为每一个 Region设计了两个名为 TAMS （ Top at Mark Start ）的指针，把 Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。 G1收集器默认在这个地址以上的对象是被隐式标记过的，即默认它们是存活的，不纳入回收范围。与 CMS中的 “Concurrent Mode Failure” 失败会导致 Full GC类似，如果内存回收的速度赶不上内存分配的速度，G1 收集器也要被迫冻结用户线程执行，导致 Full GC 而产生长时间 “Stop The World” 。

譬如，怎样建立起可靠的停顿预测模型？用户通过 -XX ： MaxGCPauseMillis参数指定的停顿时间只意味着垃圾收集发生之前的期望值，但 G1 收集器要怎么做才能满足用户的期望呢？ G1收集器的停顿预测模型是以衰减均值（ Decaying Average ）为理论基础来实现的，在垃圾收集过程中， G1收集器会记录每个 Region 的回收耗时、每个 Region记忆集里的脏卡数量等各个可测量的步骤花费的成本，并分析得出平均值、标准偏差、置信度等统计信息。这里强调的 “ 衰减平均值 ”是指它会比普通的平均值更容易受到新数据的影响，平均值代表整体平均状态，但衰减平均值更准确地代表 “ 最近的 ”平均状态。换句话说， Region的统计状态越新越能决定其回收的价值。然后通过这些信息预测现在开始回收的话，由哪些 Region 组成回收集才可以在不超过期望停顿时间的约束下获得最高的收益。

如果我们不去计算用户线程运行过程中的动作（如使用写屏障维护记忆集的操作）， G1收集器的运作过程大致可划分为以下四个步骤：

初始标记 （ Initial Marking ）：仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的 Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行 Minor GC 的时候同步完成的，所以 G1收集器在这个阶段实际并没有额外的停顿。

并发标记 （ Concurrent Marking ）：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理 SATB 记录下的在并发时有引用变动的对象。

最终标记 （ Final Marking）：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的 SATB 记录。

筛选回收 （ Live Data Counting and Evacuation ）：负责更新 Region 的统计数据，对各个 Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分 Region 的存活对象复制到空的 Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行 完成的。

从上述阶段的描述可以看出，G1收集器除了并发标记外，其余阶段也是要完全暂停用户线程的，换言之，它并非纯粹地追求低延迟，官方给它设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才能担当起 “ 全功能收集器 ” 的重任与期望 [4] 。

从 Oracle 官方透露出来的信息可获知，回收阶段（ Evacuation）其实本也有想过设计成与用户程序一起并发执行，但这件事情做起来比较复杂，考虑到 G1 只是回收一部分 Region，停顿时间是用户可控制的，所以并不迫切去实现，而选择把这个特性放到了 G1 之后出现的低延迟垃圾收集器（即 ZGC）中。另外，还考虑到 G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。通过图 3-13 可以比较清楚地看到 G1收集器的运作步骤中并发和需要停顿的阶段。

毫无疑问，可以由用户指定期望的停顿时间是 G1收集器很强大的一个功能，设置不同的期望停顿时间，可使得 G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。不过，这里设置的 “期望值”必须是符合实际的，不能异想天开，毕竟G1是要冻结用户线程来复制对象的，这个停顿时间再怎么低也得有个限度。它默认的停顿目标为两百毫秒，一般来说，回收阶段占到几十到一百甚至接近两百毫秒都很正常，但如果我们把停顿时间调得非常低，譬如设置为二十毫秒，很可能出现的结果就是由于停顿目标时间太短，导致每次选出来的回收集只占堆内存很小的一部分，收集器收集的速度逐渐跟不上分配器分配的速度，导致垃圾慢慢堆积。很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间，但应用运行时间一长就不行了，最终占满堆引发 Full GC反而降低性能，所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

从 G1开始，最先进的垃圾收集器的设计导向都不约而同地变为追求能够应付应用的内存分配速率（ Allocation Rate ），而不追求一次把整个Java堆全部清理干净。这样，应用在分配，同时收集器在收集，只要收集的速度能跟得上对象分配的速度，那一切就能运作得很完美。这种新的收集器设计思路从工程实现上看是从 G1 开始兴起的，所以说 G1 是收集器技术发展的一个里程碑。

G1 收集器常会被拿来与 CMS收集器互相比较，毕竟它们都非常关注停顿时间的控制，官方资料 [5] 中将它们两个并称为 “The Mostly Concurrent Collectors” 。在未来， G1 收集器最终还是要取代CMS的，而当下它们两者并存的时间里，分个高低优劣就无可避免。

相比 CMS ， G1 的优点有很多，暂且不论可以指定最大停顿时间、分 Region的内存布局、按收益动态确定回收集这些创新性设计带来的红利，单从最传统的算法理论上看， G1 也更有发展潜力。与CMS的 “ 标记 - 清除 ” 算法不同， G1 从整体来看是基于 “ 标记 - 整理 ” 算法实现的收集器，但从局部（两个Region之间）上看又是基于 “ 标记 - 复制 ” 算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。这种特性有利于程序长时间运行，在程序为大对象分配内存时不容易因无法找到连续内存空间而提前触发下一次收集。

不过， G1 相对于 CMS 仍然不是占全方位、压倒性优势的，从它出现几年仍不能在所有应用场景中 代替 CMS 就可以得知这个结论。比起 CMS ， G1的弱项也可以列举出不少，如在用户程序运行过程中， G1 无论是为了垃圾收集产生的内存占用（ Footprint）还是程序运行时的额外执行负载（ Overload ）都要比 CMS 要高。

就内存占用来说，虽然 G1 和 CMS 都使用卡表来处理跨代指针，但 G1的卡表实现更为复杂，而且堆中每个 Region ，无论扮演的是新生代还是老年代角色，都必须有一份卡表，这导致 G1的记忆集（和其他内存消耗）可能会占整个堆容量的 20% 乃至更多的内存空间；相比起来CMS的卡表就相当简单，只有唯一一份，而且只需要处理老年代到新生代的引用，反过来则不需要，由于新生代的对象具有朝生夕灭的不稳定性，引用变化频繁，能省下这个区域的维护开销是很划算的 [6] 。

在执行负载的角度上，同样由于两个收集器各自的细节实现特点导致了用户程序运行时的负载会有不同，譬如它们都使用到写屏障， CMS 用写后屏障来更新维护卡表；而 G1除了使用写后屏障来进行同样的（由于 G1的卡表结构复杂，其实是更烦琐的）卡表维护操作外，为了实现原始快照搜索（ SATB）算法，还需要使用写前屏障来跟踪并发时的指针变化情况。相比起增量更新算法，原始快照搜索能够减少并发标记和重新标记阶段的消耗，避免 CMS那样在最终标记阶段停顿时间过长的缺点，但是在用户程序运行过程中确实会产生由跟踪引用变化带来的额外负担。由于 G1对写屏障的复杂操作要比 CMS 消耗更多的运算资源，所以 CMS 的写屏障实现是直接的同步操作，而 G1就不得不将其实现为类似于消息队列的结构，把写前屏障和写后屏障中要做的事情都放到队列里，然后再异步处理。

以上的优缺点对比仅仅是针对 G1 和CMS两款垃圾收集器单独某方面的实现细节的定性分析，通常我们说哪款收集器要更好、要好上多少，往往是针对具体场景才能做的定量比较。按照笔者的实践经验，目前在小内存应用上 CMS 的表现大概率仍然要会优于 G1 ，而在大内存应用上 G1则大多能发挥其优势，这个优劣势的 Java 堆容量平衡点通常在 6GB 至 8GB之间，当然，以上这些也仅是经验之谈，不同应用需要量体裁衣地实际测试才能得出最合适的结论，随着 HotSpot 的开发者对 G1的不断优化，也会让对比结果继续向 G1 倾斜。

[1] JEP 291 ： Deprecate the Concurrent Mark Sweep(CMS)Garbage Collector 。

[2] JEP 304 ： Garbage Collector Interface 。

[3] 图片来源： https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All 。

[4] 原文是： It meets garbage collection pause time goals with a high probability ，while achieving high throughput 。

[5] 资料来源： https://docs.oracle.com/en/java/javase/11/gctuning/available-collectors.html 。

[6] 代价就是当 CMS 发生 Old GC 时（所有收集器中只有 CMS 有针对老年代的 Old GC），要把整个新生代作为 GC Roots 来进行扫描。

8、HotSpot GC组合方式

9、垃圾收集器参数