基于JDK1.7Update14之后的HotSpot虚拟机垃圾收集器

HotSpot虚拟机垃圾收集器概览图，收集器工作的内存区域以及收集器之间的配合使用情况。如下图所示：

1.Serial收集器

Serial是最基本，历史最悠久的收集器，在Jdk1.3以前是虚拟机唯一的新新生代收集器。
它的特点：

 1. 单线程收集器，它只会使用一个CUP或者说一条收集线程来完成垃圾收集；
 2. Stop The World,当进行垃圾收集时必须暂停所有的工作线程，直到它收集结束。
 3. 使用“复制”算法，

现状及优势

 1. 现在目前国止，它依然是虚拟机运行在Client模式下的默认新生代收集器
 2. 相比其他单线程收集器简单而高效，针对单CPU环境来说，没有线程交互开销。
 3. 对于用户桌面应用来说，新生代使用的内存不会太大，停顿时间完全可以控制在几十毫秒以内，完全能胜任。

2.ParNew收集器

ParNew是Serial收集器的多线程版本， 除了多线程的区别外，其他作为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、回收策略等都与Serial完全一样。
它的特点：

 1. 是Serial收集器的多线程版本，
 2. 也是新生代收集器，
 3. 使用“复制”算法
 4. 它是许多运行在Server模式下的虚拟机中首选的新生代收集器，
 5. ParNew是能与CMS收集器配合工作的其中一个，另一个就是Serial收集器。
 6. ParNew在单CPU环境并不比Serial收集器更好，反而可能由于线程交互而使性能不如Serial
 7. ParNew默认开启的线程数与CPU数量相同。
 8. -XX:+UseParNewGC 添加该虚拟机参数后，虚拟机强制使用ParNew收集器。
 9. -XX:ParallelGCThreads参数来限制垃圾收集器的线程数。

3.Parallel Scavenge收集器

它是一个新生代收集器，它使用复制算法，且是并行的多线程收集器。Parallel Scavenge收集器的目的是达到一个可控制的吞吐量（Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗的时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。虚拟机总共运行了100分钟，用于垃圾收集花了1分钟，那么吞吐量就是99%。
它的特点：

 1. 新生代收集器，
 2. 使用“复制”算法；
 3. 并行的多线程收集器；
 4. 关注点在于，可控制的吞吐量
 5. 提供两个参数实现吞吐量的控制，
     -XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间，允许设置大于0的毫秒数
     -XX:GCTimeRatio 直接设置吞吐量大小。取值为大于0小于100的整数
     -XX:+UseAdaptiveSizePolicy 让虚拟机根据系统情况动态调整新生代大小，eden与Survivor比例、晋升老年代对象年龄等参数；若设置了此参数，用户只需要设置最大堆大小（-Xmx）和MaxGCPauseMillis或XX:GCTimeRatio

4.Serial Old收集器

Serial Old 是Serial收集器的老年代版本，它同样是单线程收集器，使用“标记——整理”算法。它主要意义在于给Client模式 下的虚拟机使用。若在Server模式 下，它主要还有两大用途：一种是在JDK1.5以及之前的版本 与Parallel Scavenge收集器搭配使用；另一种是作为CMS收集器的后备预案。
它的特点：

 1. 老年代收集器，Serial的老年代版本；
 2. 单线程收集器；
 3. 使用“标记——整理”算法；
 4. 可与Parallel Scavenge收集器搭配使用；
 5. Stop The World

5.Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程“标记——整理”算法，在JDK1.6中开始提供使用。Parallel Old出现之前，Parallel Scavenge只能与Serial Old配合使用，Serial Old单线程的特性导致老年代垃圾收集瓶颈所以Parallel Scavenge略显尴尬。在Parallel Old收集器出现以后，Parallel Scavenge的“吞吐量优先”收集器才变得名副其实。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge +Parallel Old收集器组合。
它的特性：

 1. 老年代收集器；
 2. 多线程；
 3. 使用“标记——整理”算法；
 4. Stop The World;

6.CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获得最短回收停顿时间为目标的收集器。对于重视服务的响应速度，希望系统停顿时间最短，以给用记带来较好的体验的应用（互联网或B/S系统服务端），CMS非常符合这类应用需求。它基于“标记——清除”算法。收集过程分为4步：

 1. 初始标记（Stop The Wold）,标记GC Root能直接关联到的对象，速度快
 2. 并发标记（与用户线程并行执行），GC Roots Tracing,标记与GC Root关联对象引用的对象；
 3. 重新标记,（Stop The Wold），修正并发标记期间因用户程序继续动作而导致标记变动的部分对象的标记记录；
 4. 并发清除（与用户线程并行），运行时间稍长，但由于与用户线程并发，所以影响不大。

优点：

 1. 并发收集；
 2. 低停顿。

缺点：

 1. CMS收集器对CPU资源非常敏感，CMS默认启动的回收线程数是（CPU数量+3）/4。
 2. CMS无法处理浮动垃圾，浮动垃圾就是收集过程中由于用户线程执行新产生的垃圾
 3. 会产生大量的空间碎片；也提供了参数设置，执行多少次垃圾收集后进行一次碎片合并整理]
     -XX:UseCMSCompactAtFullCollection 默认开启，在fullGC时开启内存碎片合并整理
     -XX:CMSFullGCsBeforeCompaction 设置多少次fullGc后执行一次碎片合并整理。

7.G1收集器

G1收集器是当今收集器技术发展的最前沿成果之一，它是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予化的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1此具备如下特点：

 1. 并行与并发，G1能充分复用CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The_World停顿的时间，部分其他收集器原需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

 2. 分代收集，当G1无需与其他收集器配合就能独立管理整个GC堆。但它采取的方式与一般的收集器有所不同。

 3. 空间整合，与CMS的“标记——清理”算法不同，G1从整体来看是基于“标记——整理”算法的收集器，从局部上来看是基于“复制”算法实现的，但两种算法都意味着G1动作期间不会产生内存空间碎片。

 4. 可预测的停顿，这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS其同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java的垃圾收集器的特征了。

它的原理：

1. 它将整个java堆划分 为多个大小相等的独立区域（Region），虽然还保留有新生代和老年低的概念，但新生代和老年代不再是物理隔离的，它们都是一部分Region（不需要连续）的集合。
2. G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾信积的价值大小（回收所获得的空间大小 以及回收所需时间的经验值），在后台维护一个优先列表， 每次根据允许的收集时间，优先回收价值了大的Region（这也是Garbage_first名称的由来）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获得尽可能 高的收集效率。
3. 每个Region维护一个Remembered Set 来维护区域中引用对象的信息，这样避免GC是的全堆扫描。

它的执行步骤：

 1. 初始标记，仅仅是标记一下GC Roots能直接关联到的对象，运行很快，会Stop The World.
 2. 并发标记，从GC Root开始对堆中的对象进行可达性分析，找出存活对象，耗时较长，但与用户线程同时运行，
 3. 最终标记，则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，停顿用户线程。
 4. 筛选回收，首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。这阶段会停顿用户线程，该阶段其实也可能用户线程并发执行，但因为只回收一部分Region，时间是用户控制的，所以停顿用户线程提高收集效率。