JVM调优03所有垃圾收集器总结

Serial 收集器

serial收集器是一个单线程的收集器，这里的“单线程”并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在他进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集完毕。

ParNew 收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为和Serial收集器完全一样。看上去没什么大变化，但是ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。其中有一个与性能无关但很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。

Serial Old 收集器

Serial Old收集器是CMS 收集器的后备预案，在并发收集发生Concurrent Mode Failure 的时候使用。

Parallel Scavenge收集器

该收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew都一样，那它有什么特别之处呢？它是一个吞吐量优先的收集器。

它的特点是他关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。

吞吐量：所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间段比值，即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那么吞吐量就是99%。

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

它有三个参数：

-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间（大于0的毫秒数）
-XX:GCTimeRatio 直接设定吞吐量大小的值（0~100的正数，默认是99即允许最大1%的垃圾收集时间）
-XX:+UseAdaptiveSizePolicy 这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的最大吞吐量。这种调节方式称为：GC自适应的调节策略。

使用Parallel Scavenge收集器配合自适应调节策略，只要把最基本的内存数据设置好（如-Xmx最大堆），然后使用MaxGcPauseMillis参数(更关注最大停顿时间)或GCTimeRatio(更关注吞吐量)参数给虚拟机设立一个优化目标即可。

自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

Parallel Old 收集器

它是Parallel Scavenge收集器的老年代版本，使用多线程和“标记--整理”算法。如果在关注吞吐量以及CPU资源敏感的场合的话，那么理想的搭配方式为：Parallel Scavenge + Parallel Old 收集器。

CMS 收集器

CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。

目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，已给用户带来较好的体验。

从字面上可以看出CMS收集器是基于“标记--清除”算法实现的。整个过程分为4个步骤：

初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

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

CMS 运行期间预留的内存无偿满足程序需要，就会出现一次"Concurrent Mode Failure"，一般这是由于参数-XX:CMSInitiatingOccupancyFraction设置得太高导致的。这时虚拟机将启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就会很长。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活进行垃圾收集。而在JDK1.6中，CMS启动阀值已经提升至92%。出于安全或者高性能方面出发，一般设置为：70%~80%之间是最好的，我的服务器设置的是75%。

收集结束时会产生大量空间碎片。CMS 基于“标记一清除”算法实现。多次垃圾收集后，空间碎片过多，给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC，CMS收集器要进行FullGC时开启内存碎片整理。使用-XX:+UseCMSCompactAtFullCollection开关设置，默认是开启的命令表明GC后要进行空间碎片整理，虚拟机还提供了另外一个参数用于设置执行多少次不压缩的Full GC后再进行碎片整理：-XX:CMSFullGCsBeforeCompaction默认值为0，表示每次进入FullGC 时都进行碎片整理。

G1收集器

G1收集器的特点
　　G1是一款面向服务端应用的垃圾收集器，Sun（Oracle）赋予它的使命是未来可以替换掉JDK 5中发布的CMS（Concurrent Mark Sweep）收集器，与其他GC收集器相比，G1具备如下特点：

并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：与CMS的“标记-清理”算法不同，G1从整体看来是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上看是基于“复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
可预测的停顿：这是G1相对于CMS的另外一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器特征了。

实现思路
　　在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
　　G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回价值最大的 Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

在G1收集器中Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查引是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的emembered Set之中。当进行内存回收时，GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

　　提示：后续我会针对G1垃圾收集器展开详细的介绍与使用说明，帮助想要更加深入学习G1的朋友打开一个窗口。