垃圾收集器

垃圾收集器

如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。下图展示了7种不同分代的收集器，如果两个收集器之间存在连线，就说明他们可以搭配使用。并没有最好的收集器这一说，我们需要选择的是对具体应用最合适的收集器。

Serial收集器（用于新生代）

单线程，在进行垃圾收集时必须暂停其他所有的工作线程（“Stop the World”）。虚拟机运行在Client模式下的默认新生代收集器。简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程效率。

ParNew收集器（新生代）

ParNew收集器其实是Serial收集器的多线程版本，它是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial收集器外，目前只有它能与CMS收集器配合工作。

Parallel Scavenge收集器（“吞吐量优先”收集器）（新生代）

    使用复制算法，并行多线程，这些特点与ParNew一样，它的独特之处是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目的则是达到一个可控制的吞吐量（Throughput）,即CPU用于运行用户代码的时间与CPU总消耗时间的比值，吞吐量=运行用户代码时间 /（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，吞吐量就是99%。

   停顿时间越短对于需要与用户交互的程序来说越好，良好的响应速度能提升用户的体验；

   高吞吐量可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不太需要太多交互的任务。

参数设置：

-XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间。（大于0的毫秒数）停顿时间缩短是以牺牲吞吐量和新生代空间换取的。（新生代调的小，吞吐量跟着小，垃圾收集时间就短，停顿就小）。

-XX:GCTimeRatio 直接设置吞吐量大小，0<x<100的整数，允许的最大GC时间=1/(1+x)。

-XX:+UseAdaptiveSizePolicy 一个开关参数，开启GC自适应调节策略（GC Ergonomics）,将内存管理的调优任务（新生代大小-Xmn、Eden与Survivor区的比例-XX:SurvivorRatio、晋升老年代对象年龄-XX: PretenureSizeThreshold 、等细节参数）交给虚拟机完成。这是Parallel Scavenge收集器与ParNew收集器的一个重要区别，另一个是吞吐量。

Serial Old收集器（老年代）

它是Serial收集器的老年代版本，单线程，使用“标记-整理”算法。主要意义是被Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用；作为CMS 收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。运行过程同Serial收集器。

Parallel Old收集器（老年代）

它是Parallel Scavenge收集器的老年代版本，多线程，使用“标记-整理”算法。在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old收集器。工作过程如下：

CMS收集器（Concurrent Mark Sweep）

它是一种以获取最短回收停顿时间为目标的收集器。优点：并发收集，低停顿。基于“标记-清除”算法。目前很大一部分Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求。运作过程较复杂，分为4个步骤：

    初始标记（CMS initial mark）:需要“Stop The World”，标记GC Roots能直接关联到的对象，速度快。
    并发标记（CMS concurrent mark）：进行GC Roots Tracing 过程
    重新标记（CMS remark）：需要“Stop The World”,修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。停顿时间：初始标记<重新标记<<并发标记
    并发清除（CMS concurrent sweep）：时间较长。

缺点：

对CPU资源非常敏感，面向并发设计的程序都会对CPU资源较敏感。CMS默认的回收线程数: （CPU数量+3）/4

无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。并发清理阶段用户程序运行产生的垃圾过了标记阶段所以无法在本次收集中清理掉，称为浮动垃圾。CMS收集器默认在老年代使用了68%的空间后被激活。若老年代增长的不是很快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction 提高触发百分比，但调得太高会容易导致“Concurrent Mode Failure”失败。

基于“标记-清除”算法会产生大量空间碎片。提供开关参数-XX:+UseCMSCompactAtFullCollection 用于在“ 享受”完Full GC服务之后进行碎片整理过程，内存整理的过程是无法并发的。但是停顿时间会变长。

-XX:CMSFullGCsBeforeCompation 设置在执行多少次不压缩的Full GC后，跟来来一次带压缩的。

G1收集器（Garbage First）

它是当前收集器技术发展的最前沿成果。与CMS相比有两个显著改进：

• 基于“标记-整理”算法实现收集器
• 非常精确地控制停顿

G1收集器可以在几乎不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的由来）。区域划分、有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。