3. 垃圾收集器（CMS和G1垃圾收集器）

根据作用代不同分类七种垃圾收集器

新生代收集器

Serial、ParNew、Parallel Scavenge

老年代收集器

CMS、Serial Old、Parallel Old

整堆收集器

G1

JVM（HotSpot）7种垃圾收集器

1、Serial收集器（串行收集器）

Serial收集器是最基本、发展历史最悠久的收集器，曾是（JDK1.3.1之前）虚拟机新生代收集的唯一选择。
Serial收集器是一个单线程的收集器。“单线程”的意义不仅仅是它只会使用一个CPU或一条收集器线程去完成垃圾收集工作，更重要的是它在垃圾收集的时候，必须暂停其他所有工作的线程，直到它收集结束。
Serial收集器是HotSpot虚拟机运行在Client模式下的默认新生代收集器。
Serial收集器具有简单而高效，由于没有线程交互的开销，可以获得最高的单线程收集效率（在单个CPU环境中）。
“-XX:+UseSerialGC”：添加该参数来显式的使用Serial垃圾收集器。

2、ParNew收集器

ParNew收集器是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Word、对象分配规则、回收策略等都与Serial收集器一样。
ParNew收集器是许多运行在Server模式下的虚拟机首选的新生代收集器，其中一个原因是，除了Serial收集器之外，目前只有ParNew收集器能与CMS收集器配合工作。

“-XX:+UseConcMarkSweepGC”：指定使用CMS后，会默认使用ParNew作为新生代收集器。

“-XX:+UseParNewGC”：强制指定使用ParNew。

“-XX:ParallelGCThreads”：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同。

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

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

3、Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，使用复制算法，且是并行的多线程收集器。

Parallel Scavenge收集器关注点是达到一个可控制的吞吐量（吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）），而其他收集器关注点在尽可能的缩短垃圾收集时用户线程的停顿时间。

Parallel Scavenge收集器提供了两个参数来用于精确控制吞吐量，一是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数，二是控制吞吐量大小的 -XX：GCTimeRatio参数；

“ -XX：MaxGCPauseMillis” 参数允许的值是一个大于0的毫秒数，收集器将尽可能的保证内存垃圾回收花费的时间不超过设定的值（但是，并不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然GC停顿时间下来了，但是吞吐量也下来了）。

“ -XX：GCTimeRatio”参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（即1/（1+99））的垃圾收集时间。

“-XX：UseAdaptiveSizePolicy”参数是一个开发，如果这个参数打开之后，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的比例、老年大大小等细节参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略。

4、Serial Old收集器

Serial Old收集器是Seria收集器的老年代版本，他同样是一个单线程收集器，使用" 标记-整理" 算法。

Serial Old收集器主要用于Client模式下的虚拟机使用。

Server模式下的两大用途：一、在JDK1.5及之前的版本与Parallel Scavenge收集器搭配使用；二、作为CMS收集器的后备方案，在并发收集发生Conturrent Mode Failure时使用。

5、Paraller Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

6、CMS（Conturrent Mark Sweep）收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器

CMS收集器运行过程

CMS收集器是基于“标记-清除”算法实现，它的整个运行过程可以分为：

初始登记

标记一下GC Roots能直接关联到的对象，这个过程速度很快

并发标记

进行GCRoots Tracing的过程

重新标记

修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，速度稍慢

并发清除

清除死亡的对象

---

初始标记和重新标记仍然需要停顿用户线程

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

---

优点

并发收集、低停顿

缺点

1. CMS收集器对CPU资源非常敏感。虽然在两个并发阶段不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是（CPU数量+3）/4
2. CMS收集器无法处理浮动垃圾。由于CMS并发清除阶段用户线程还在运行，伴随着程序还在产生新的垃圾，这一部分垃圾出现在标记之后，CMS无法在当次收集中处理掉它们，只能留到下次再清理，这一部分垃圾称为“浮动垃圾”。也正是由于在并发清除阶段用户线程还在运行，那么也就需要预留有足够的内存空间给用户线程使用
3. 由于CMS收集器是一个基于“标记-清除”算法的收集器，那么意味着收集结束会产生大量碎片，有时候往往还有很多内存未使用，可是没有一块连续的空间来分配一个对象，导致提前触发一次Full GC

7、G1（Garbage-First）收集器

特点

• 并行与并发：G1 能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短用户线程停顿时间，通过并发的方式让Java程序继续运行
• 分代收集：G1 能够独自管理整个Java堆，并且采用不同的方式去处理新旧对象
• 空间整合：G1 基于“标记-整理”来实现的收集器，筛选回收部分使用的是“复制”算法实现的，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能够提供整体的可用内存
• 可预测停顿：G1 除了低停顿之外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒

垃圾收集过程

初始标记

仅标记 GC Roots 能直接关联到的对象并且修改指针的值，使得下一阶段用户线程并发运行时，能正确地在可用的 Region 中分配新对象（需要停顿用户线程，但耗时很短，且是借用 Minor GC 时同步完成的）

并发标记

从 GC Roots 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象（耗时较长，可与用户程序并发执行）

最终标记

处理并发标记结束后仍遗留下来的最后少量的原始快照记录（需要暂停用户线程，时间较短）

筛选回收

更新 Region 统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划（由于涉及存活对象的移动，需要暂停用户线程）