垃圾回收器

垃圾收集算法

标记-清除算法

  算法分为“标记”和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它的不足之处有两个：一是效率问题，标记和清除的效率都不高；另一个是空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能导致以后在程序运行过程中需分配较大对象时，无法找到足够的连续内存而触发另一次垃圾收集动作。

复制算法

  复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的空间一次清理掉。
  现在商业虚拟机都采用这种收集算法来回收新生代，新生代98%的对象“朝生夕死”，所以并不需要按照1:1来划分内存空间，而是将内存空间分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块survivor。当回收时，将Eden和Survivor中还存活着的对象一次性复制到另一块survivor空间上，最后清理掉用过的空间。HotSpot虚拟机默认的Eden和Survivor的比例是8:1。

标记整理算法

  复制算法在对象存活率较高时需要进行较多的肤质操作，效率会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对内存中100%对象都存活的极端情况，所以老年代一般不采用这种算法。
  标记整理算法的标记过程与标记清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向另一端移动，然后清理掉边界以外的内存。

分代收集算法

  这种算法根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样可以根据各个年代的特点采用适当的收集算法。在新生代中，采用复制算法，而老年代中，使用标记-清理或者标记整理算法来进行回收。

垃圾收集器

  Java虚拟机规范中对垃圾收集器应如何实现没有任何规定，这里讨论JDK1.7Update 14之后的HotSpot虚拟机，这个虚拟机包含的所有收集器入下图所示。如果两个收集器之间存在连线，就说明它们可以搭配使用。

1349278110_8410.jpg

Serial收集器

  这个收集器是一个单线程的收集器，她在垃圾收集时，必须暂停其他所有的工作线程，直到收集结束。

Serial.jpg

ParNew收集器

  ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略都与Serial收集器完全一样。除Serial收集器外，目前只有ParNew收集器能与CMS收集器配合工作。

ParNew.jpg

Parallel Scavenge收集器

  Parallel Scavenge收集器的目标是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。
  Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
  MaxGCPauseMillis允许的值是一个大于0的毫秒数，收集器将尽可能地保证花费时间不超过设定值。GCTimeRatio应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值99。

Par Scavenge.jpg

Serial Old收集器

   Serial Old时Serial收集器的老年代版本，它同样是单线程收集器，使用标记-整理算法。可与Parallel Scavenge收集器搭配使用，也可作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Serial Old.jpg

Parallel Old收集器

   Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程的标记-整理算法。在注重吞吐量以及Cpu资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

Parallel Old.jpg

CMS收集器

   CMS收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器基于标记-清除算法，整个过程分为4个步骤：
      初始标记（需Stop the world）
      并发标记
      重新标记（需Stop the world）
      并发清除
   CMS收集器有以下3个明显的缺点：
    对CPU资源非常敏感，CMS默认启动的回收线程数是（CPU数量+3)/4，当CPU数量不足时，CMS对用户的影响可能很大。
    CMS无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full Gc的产生。由于CMS并发清理阶段用户线程还在运行，会有垃圾不断产生，CMS无法在当次收集中处理它们，只好等待下一次GC。
    CMS基于标记清除算法，会产生大量碎片。

CMS.jpg

G1收集器

  G1(Garbage First)收集器是JDK1.7提供的一个新的面向服务端应用的垃圾收集器，其目标就是替换掉JDK1.5发布的CMS收集器。其优点有：
  1.并发与并行：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或CPU核心）来缩短停顿（Stop The World）时间。
  2.分代收集：G1不需要与其他收集器配合就能独立管理整个GC堆，但他能够采用不同方式去处理新建对象和已经存活了一段时间、熬过多次GC的老年代对象以获取更好收集效果。
  3.空间整合：从整体来看是基于“标记-整理”算法实现，从局部（两个Region之间）来看是基于“复制”算法实现的，但是都意味着G1运行期间不会产生内存碎片空间，更健康，遇到大对象时，不会因为没有连续空间而进行下一次GC，甚至一次Full GC。
  4.可预测的停顿：降低停顿是G1和CMS共同关注点，但G1除了追求低停顿，还能建立可预测的停顿模型，可以明确地指定在一个长度为M的时间片内，消耗在垃圾收集的时间不超过N毫秒
  5.跨代特性：之前的收集器进行收集的范围都是整个新生代或老年代，而G1扩展到整个Java堆(包括新生代，老年代)。
那么是怎么实现的呢？
  1.如何实现新生代和老年代全范围收集：其实它的Java堆布局就不同于其余收集器，它将整个Java堆划分为多个大小相等的独立区域（Region），仍然保留新生代和老年代的概念，可是不是物理隔离的，都是一部分Region（不需要连续）的集合。
  2.如何建立可预测的停顿时间模型：是因为有了独立区域Region的存在，就避免在Java堆中进行全区域的垃圾收集，G1跟踪各个Region里面的垃圾堆积的价值大小（回收可以获得的空间大小和回收所需要的时间的经验值），后台维护一个优先队列，根据每次允许的收集时间，优先回收价值最大的Region（Garbage-First理念）。因此使用Region划分内存空间以及有优先级的区域回收方式，保证了有限时间获得尽可能高的收集效率。
  3.如何保证垃圾回收真的在Region区域进行而不会扩散到全局：由于Region并不是孤立的，一个Region的对象可以被整个Java堆的任意其余Region的对象所引用，在做可达性判定确定对象是否存活时，仍然会关联到Java堆的任意对象，G1中这种情况特别明显。而以前在别的分代收集里面，新生代规模要比老年代小许多，新生代收集也频繁得多，也会涉及到扫描新生代时也会扫描老年代的情况，相反亦然。解决：G1收集器Region之间的对象引用以及新生代和老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描。G1中每个Region都有一个与之对应的Remembered Set,虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中(分代的例子中就检查是否老年代对象引用了新生代的对象)，如果是则通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中，当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可避免全堆扫描。
忽略Remembered Set的维护，G1的运行步骤可简单描述为：
  ①.初始标记(Initial Marking)
  ②.并发标记(Concurrenr Marking)
  ③.最终标记(Final Marking)
  ④.筛选回收(Live Data Counting And Evacution)
  1.初始标记：初始标记仅仅标记GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新的对象。这阶段需要停顿线程，不可并行执行，但是时间很短。
  2.并发标记：此阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，此阶段时间较长可与用户程序并发执行。
  3.最终标记：此阶段是为了修正在并发标记期间因为用户线程继续运行而导致标记产生变动的那一份标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这段时间需要停顿线程，但是可并行执行。
  4.筛选回收：对各个Region的回收价值和成本进行排序，根据用户期望的GC停顿时间来制定回收计划。
  如果现有的垃圾收集器没有出现任何问题，没有任何理由去选择G1，如果应用追求低停顿，G1可选择，如果追求吞吐量，和Parallel Scavenge/Parallel Old组合相比G1并没有特别的优势。

常用参数总结

参数 描述
UseSerialGC 虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old的收集器组合进行内存回收
UseParNewGC 打开此开关后，使用ParNew+Serial Old的收集器组合进行内存回收
UseConcMarkSweepGC 打开此开关后，使用ParNew+CMS+Serial Old的收集器组合进行内存回收。Serial Old收集器将作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器使用
UseParallelGC 虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old（PS MarkSweep）的收集器组合进行内存回收
UseParallelOldGC 打开此开关后，使用Parallel Scavenge + Parallel Old的收集器组合进行内存回收
SurvivorRatio 新生代中Eden区域与Survivor区域的容量比值，默认值为8，代表Eden：Survivor=8：1
PretenureSizeThreshold 直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
MaxTenuringThreshold 晋升到老年代的对象年龄，每个对象在坚持过一次Minor GC之后，年龄就增加1，当超过这个参数时就进入老年代
UseAdaptiveSizePolicy 动态调整Java堆中各个区域的大小以及进入老年代的年龄
HandlePromotionFailure 是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况
ParallelGCThreads 设置并行GC时进行内存回收的线程数
GCTimeRatio GC时间占总时间的比率，默认值为99，即允许1%的GC时间。仅在使用Parallel Scavenge收集器时生效
MaxGCPauseMillis 设置GC的最大停顿时间，仅在使用Parallel Scavenge收集器时生效
CMSInitingOccupancyFraction 设置CMS收集器在老年代空间被使用多少后触发垃圾收集。默认值为68%，仅在使用CMS收集器时生效
UseCMSCompactAtFullCollection 设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理，仅在使用CMS收集器时生效
CMSFullGCsBeforeCompaction 设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理。仅在使用CMS收集器时生效