关于JVM虚拟机的垃圾收集器7种——摘自《深入理解java虚拟机》（每天学一点Day20191114）

虚拟机的垃圾收集器（98页）
1.Serial（串行）收集器：最基本、发展历史最悠久的收集器。虚拟机运行在Client模式下的默认新生代收集器。新生代采用复制算法暂停所有用户线程。老年代采用标记-整理算法暂停所有线程。
单线程收集器：它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，同时在它进行垃圾收集时，必须暂停其他所有的工作线程，直到他收集结束。
优点：简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

2.ParNew收集器：Serial收集器的多线程版本。虚拟机运行在Server模式下的首选的新生代收集器，主要原因是出Serial收集器外，目前只有它能与CMS收集器配合工作。新生代采用复制算法暂停所有用户线程，老年代采取标记整理算法暂停所有用户线程。
ParNew收集器也是使用-XX：+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX：+UseParNewGC选项来强制制定它。
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至存在交互开销。默认开启的收集线程数与CPU的数量相同。在CPU多的情况下，可以使用-XX:ParallelGCThread参数来限制垃圾收集的线程数。

**拓展**：
**并行（Parallel）**：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
**并发（Concurrent）**：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

3.Parallel Scavenge收集器：新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
特点：Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。即：CPU用于运行用户代码的时间与CPU总消耗时间的比值，吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。停顿时间短适合与用户交互的程序，提升用户体验。高吞吐量则高效利用CPU完成运算任务，适合后台运算。
Parallel Scavenge收集器提供了两个参数用于控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的—XX:GCTimeRatio参数。-XX:+UseAdaptiveSizePolicy虚拟机动态调整新生代大小等参数，简称：GC自适应的调节策略，也是ParNew和Parallel Scavenge收集器的重要区别。

4.Serial Old收集器：Serial收集器的老年代版本，同样是单线程收集器，使用“标记-整理算法”。主要用于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要用途是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failue时使用。

5.Parallel Old收集器：使用多线程和“标记-整理”算法。（jdk1.6以后提供） 用于Parallel Scavenge收集器配合使用。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

6.CMS（Concurrent Mark Sweep）收集器：一种以获取最快回收停顿时间为目标的收集器。并发收集，低停顿。适用于重视服务的相应速度，给用户带来较好体验的服务端。
>>CMS是基于“标记-清除”算法实现的，包括四个步骤：初始标记（stop the world）→并发标记→重新标记（stop the world）→并发清除。CMS初始标记仅仅只是标记下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些。
>>CMS收集器对CPU资源非常敏感，并发阶段虽然不会导致用户线程停顿，但是占用线程会导致程序运行变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3/4）。也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随CPU数量的增加而下降。当CPU不足4个时，CMS对用户程序的影响就可能变得很大。
>>CMS收集器无法处理浮动垃圾，会产生"Concurrent Mode Failure"失败而导致另一次Full GC的产生。浮动垃圾：CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会不断有新的垃圾产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾称为“浮动垃圾”。CMS收集器不能像其他收集器那样等老年代几乎完全填满了在进行收集，需要预留一部分空间提供并发收集时的程序运作使用。要是CMS运行期间保留的内存无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败，此时虚拟机将启动后备预案：临时启用Serial Old收集器来进行重新老年代的垃圾收集。 -XX:CMSInitiatingOccupancyFraction设置太高很容易导致大量"Concurrent Mode Failure"失败，性能反而降低。
>>CMS是基于标记清除算法实现的收集器，收集结束会有大量空间碎片产生。空间碎片过多，会给大对象分配带来很大麻烦。为此，CMS收集器提供了一个-XX：+UseCMSCompactAtFullCollection开关参数（默认开启），用于在CMS收集器顶不住要进行FullGC时，开启内存碎片的合并整理过程，单线程整理停顿时间延长。虚拟机设计者还提供了另外一个参数-XX：CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着一次压缩的（默认为0，表示，每次进入Full GC时都进行碎片整理）。

7.G1收集器：面向服务端应用的垃圾收集器。
>>特点：
1）并行与并发：G1通过使用多个CPU来缩短Stop the World停顿的时间
2）分代收集：G1不需要与其他收集器配合（新生代+老年代配合），独立管理整个GC堆，且它能够采用不同的方式去处理新建对象和已经存活一段时间、熬过多次GC的旧对象，以获取更好的收集效果。
3）空间整合：与CMS的“标记-整理”算法不同，G1从整体看是基于“标记-整理算法”实现的收集器，从局部看（两个Region之间）是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。
4）可预测的停顿：降低停顿时间是G1和CMS共同的关注点，但G1除了追求停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
>>在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离了，它们都是一部分Region的集合。
>>G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的由来）。这种Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
>>G1收集器的运作四个步骤：
初始标记→并发标记→最终标记→筛选回收
前两步跟CMS收集器相似，初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一个阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这个阶段耗时较长，但可与用户程序并发执行。而最终标记阶段是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在Remembered Set中，这阶段需要停顿线程，但是可以并行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，与用户程序并发执行。