如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别。这里仅讨论HotSpot虚拟机中的垃圾收集器。

垃圾收集器组合

HotSpot虚拟机的所有收集器如下：

新生代收集器：Serial、ParNew、Parallel Scavenge

老年代收集器：CMS、Serial Old（MSC）、Parallel Old

整堆收集器：G1

图中连线的收集器表示可以搭配使用，Serial Old 可以作为CMS出现（Concurrent Mode Failed）失败的后备方案

并发收集器和并行收集器

并行

指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待态。

如：ParNew、Parallel Scavenge、Parallel Old；

并发

指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

Serial收集器

特点

1. 针对新生代
2. 采用赋值算法
3. 单线程收集，进行垃圾收集时，会停止所有用户线程直到完成。

Serial/Serial Old组合收集器运行过程，Serial在新生代使用复制算法收集，Serial Old在老年代使用标记-整理收集

ParNew收集器

特点

ParNew是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集意外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器一样

ParNew/Serial Old组合收集器运行过程如下：

应用场景

在Server模式下，ParNew是一个非常重要的收集器，因为除了Serial外，只有ParNew能够和CMS进行组合。

Parallel Scavenge收集器

Parallel Scavenge垃圾收集器因为与吞吐量关系密切，也称为吞吐量优先收集器（Throughput Collector）。

特点

1. 新生代收集器
2. 采用复制算法
3. 并行的多线程收集器
4. 与CMS等关注与缩短停顿时间不同，Parallel Scavenge收集器关注于达到一个可控制的吞吐量。

吞吐量：CPU运行于用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间 + 垃圾收集时间）

应用场景

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合后台运算而不需要太多交互的任务。

参数设置

Parallel Scavenge收集器提供两个参数用于精确控制吞吐量：

1. -XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，大于0的毫秒数
2. -XX:GCTimeRatio：设置垃圾收集时间占总时间的比率，0<n<100的整数；

还有一个-XX:+UseAdptiveSizePolicy参数，相当于一个开关，参数打开之后，GC自适应的调节策略，不用手工指定一些细节参数，如新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等；

Serial Old收集器

特点

1. 针对老年代
2. 采用“标记-整理法”收集（还有压缩Mark-Sweep-Compact）
3. 单线程收集

应用场景

主要用于Client模式；

而在Server模式有两大用途：

1. 在JDK1.5及之前，与Parallel Scavenge收集器搭配使用（JDK1.6有Parallel Old收集器可搭配）；
2. 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

Parallel Old收集器

Parallel Old是Parallel Scavengeh收集器的老年代版本。,在JDK1.6中开始提供

特点

1. 针对老年代
2. 采用“标记-整理法”
3. 多线程收集

Parallel Scavengeh/Parallel Old收集器工作过程如下：

应用场景

在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavengeh/Parallel Old收集器

CMS（Concurrent Mark Sweep）收集器

CMS是一种以获取最短回收停顿时间为目标的收集器,也叫做并发低停顿收集器

特点

1. 针对老年代
2. 基于“标记-清除”算法(不进行压缩操作，产生内存碎片)
3. 并发收集，低停顿

是HotSpot在JDK1.5推出的第一款真正意义上的并发（Concurrent）收集器;第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；

过程

1. 初识标记（需要停顿）：仅标记一下GC Roots能直接关联到的对象，速度很快；
2. 并发标记（可以并发）：就是GC Roots Tracing（可达性分 大专栏  JVM学习（八）垃圾收集器析）的过程
3. 重新标记（需要停顿）：修正并发标记阶段因用户程序继续运行导致标记产生变动的那一部分对象标记记录。这个阶段的停顿时间一般会比初始标记阶段稍长一点，但是远比并发标记时间短。
4. 并发清除（可以并发）：回收垃圾对象。

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

缺点

对CPU资源敏感

并发收集虽然不会导致用户线程停顿，但是会占用一部分线程（或者CPU资源），会导致应用程序变慢，总吞吐量降低。CMS的默认收集线程数量是=(CPU数量+3)/4；当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。

解决方案：采用增练市并发收集器，类似使用抢占式来模拟多任务机制的思想，让收集线程和用户线程交替运行，减少收集线程运行时间。但是效果不理想，JDK1.6后被弃用。

无法处理浮动垃圾

由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这部分垃圾在标记过程之后，CMS无法再档次收集集中处理掉它们，只好留待到下一次GC时处理，这就是“浮动垃圾”。

由于在垃圾收集阶段用户线程还需要运行，那也就需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能想起他收集器那样等到老年代几乎完全被填满了在进行收集，需要预留一部分 空间提供并发收集时的程序运作使用。

解决方案：CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failed”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样收集时间就比较长了。

产生空间碎片

空间碎片产生太多，无法找到足够大的连续空间来分配当前对象，提前触发一次Full GC。

解决方案：CMS提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认是开启的），用于CMS收集器在顶不住要记性Full GC时，开启内存碎片合并整理过程。内存整理过程是无法并发的，停顿时间变长。

应用场景

与用户交互较多的场景，希望系统停顿时间最短，注重服务的响应速度，以给用户带来较好的体验，如常见WEB、B/S系统的服务器上的应用；

G1收集器

G1是一款面向服务端应用的垃圾收集器。

特点

1. 并行与并发：G1能够充分利用多CPU、多核环境下的硬件优势，来缩短Stop-The-World时间，也可以并发让垃圾收集与用户程序同时进行。
2. 分代收集：能独立管理整个堆而不需要和其他垃圾收集器组合；能够采用不同方式处理不同时期的对象。
3. 空间整合：从整体看是标记-整理算法，从局部（两个Region）看是基于“复制”算法，这两种算法都意味着G1运行期间不会产生内存碎片。
4. 可预测停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型，可以明确指定M毫秒时间片内，垃圾收集消耗的时间不超过N毫秒

G1收集器介绍

G1收集器将整个Java堆内存划分为多个大小相等的区域（Region），虽然还保留有新生代和老年代的概念，但是新生代和老年代不在是物理隔离的了，它们都是一部分Region的集合。

为什么可以预测停顿

• 有计划的避免在整个Java堆中进行全区域的垃圾收集
• 跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表。
• 每次根据允许的收集时间，优先回收价值最大的Region

这就保证了再有限时间内可以获取尽可能稿的收集效率。

过程

1. 初识标记
2. 并发标记
3. 最终标记
4. 筛选回收

初始标记

标记一下GC Roots能直接关联到的对象

并发标记

可达性分析，耗时较长，按时可以与用户线程并发，

最终标记

修正在并发标记期间因用户线程继续运作而导致标记产生变动的那一部分标记记录。

筛选回收

对各个Region回收价值和成本进行排序，根据用户所期望的GC停顿时间来定制回收计划。可以与用户程序并发进行，但是因为指挥手一部分Region，时间用户可控制的，停顿用户线程将大幅度提高收集效率，所以不需要并发。

对象引用问题

不同区之间的对象引用问题、不同年代对象引用问题。

问题描述：一个Region不可能是孤立的，不同Region之间存在互相引用，判断对象是否存活，是否要扫描整个Java堆才能保证正确。

其他垃圾收集器也存在类似的问题：回收新生代是否需要扫描老年代，从而降低Minor GC效率。

解决方案：使用Remembered Set避免全堆扫描

G1中每个区都有一个Remembered Set，在对Reference类型数据进行写操作时，就会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region（在分代中是否老年代中的对象引用了新生代的对象），如果是，便将相关引用记录到被饮用对象所属的Region的Remembered Set之中，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

应用场景

面向服务端应用，针对具有大内存、多处理器的机器；

最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案；

原文地址：https://www.cnblogs.com/wangziqiang123/p/11696919.html