垃圾算法是内存回收的方法论，垃圾收集器是内存回收的具体实现。

HotSpot虚拟机的垃圾收集器.png

注：连续表示可以搭配使用。以下具体介绍几类垃圾回收器（HotSpot1.7为例）。

一、Serial垃圾收集器（单线程、复制算法）

• 是最基本、发展历史最悠久的垃圾回收器，使用复制算法，曾是JDK1.3之前新生代唯一的垃圾收集器。

• 单线程的收集器，不仅只使用一个CPU或一条线程区完成垃圾收集工作，并且在进行垃圾回收的同时，必须暂停其他所有的工作线程（Stop the Wolrd）。

• 图解

  
  
  Serial与Serial Old收集器运行过程.png

• Serial虽在收集垃圾过程中需暂停所有其他工作线程，单它简单高效，对于限定单个CPU来说，没有线程交互的开销，可获得最高的单线程垃圾收集效率。所以Serial依然是Java虚拟机运行在Client模式下默认的新生代垃圾收集器。

二、ParNew垃圾收集器（Serial+多线程）

• Serial收集器的多线程版本，使用复制算法，除了使用多线程进行垃圾收集之外，其余行为包括所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial相同。

• 图解

  
  
  ParNew与Serial Old收集器运行过程.png
• ParNew收集器默认开启和CPU数目相同的线程数，可通过-XX:ParallelGCThread参数来限制垃圾收集器的线程数。

并行（Parallel）:指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）:指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户线程继续运行，而垃圾收集程序运行于另一个CPU上。

• ParNew虽然除了多线程外和Serial收集器几乎完全相同，但它却是许多运行在Server模式下的虚拟机首选的新生代收集器。其中一个无关性能的原因是除了Serial，只有ParNew能与CMS收集器配合工作。

三、Parallel Scavenge 收集器（多线程复制算法、高效）

• 新生代垃圾收集器，使用复制算法，多线程，它重点关注的是程序达到一个可控制的吞入量（Thoughtput）

吞吐量（Thoughput）
CPU用于运行用户代码的时间/CPU总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。
例如：虚拟机总共运行100分钟，垃圾收集时间为1分钟，那吞吐量为99%。

• 高吞吐量可以最高效率地利用CPU时间，尽快地完成程序地运算任务，主要适用于后台运算而不需要太多交互地任务。
• 提供了两个参数用于精准控制吞吐量
  1. -XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，允许的值是一个大于0的毫秒数，收集器尽可能地保证内存回收花费地时间不超过设定值。
  2. -XX:GCTimeRatio：直接设置吞吐量大小，值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比例，相当于吞吐量的倒数。如果把参数设置称19，那允许的最大GC时间就占总时间的5%（即1/(1+19)）,默认值为99。
• 也称为“吞吐量优先”收集器。除上述两个参数外，还有一个参数-XX:+UseAdaptiveSizePolicy,这是一个开关参数，当这个参数打开之后，就不需手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

• 图解

  
  
  Parallel Scavenge与Serial Old收集器运行过程.png

四、Serial Old收集器（单线程、标记-整理算法）

• Serial垃圾收集器老年代不安本，单线程，使用标记-整理算法。
• 主要是运行在Client默认的java虚拟机默认的老年代垃圾收集器。
• 在Server模式下，主要有两个用途
  1. 在JDK1.5之前版本中与新生代Parallel Scavenge收集器搭配使用。
  2. 作为老年代中使用CMS收集器的后备垃圾收集方案。

• 图解

  
  
  Serial与Serial Old收集器运行过程.png

ParNew与Serial Old收集器运行过程 - 副本.png

Parallel Scavenge与Serial Old收集器运行过程.png

五、Parallel Old收集器（多线程，标记-整理算法）

• 是Parallel Scavenge的老年代版本，多线程，使用标记-整理算法，在JDK1.6才开始使用。
• 在JDK1.6之前，新生代Parallel Scavenge只能搭配老年代的Serial Old,只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old正是为了在老年代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可优先考虑新生代Parallel Scavenge和老年代Parallel Old收集器的搭配策略。

• 图解

  
  
  Parallel Scavenge和Parallel Old收集运行过程.png

六、CMS收集器（多线程、标记-清除算法）、

• CMS(Concurrent mark sweep)收集器是一种老年代垃圾收集器，以获得最短回收停顿时间为目标（可以为交互比较高的程序提高用户体验），多线程，使用标记-清除算法。
• 它的运作过程比较复制，分为4个阶段
  1. 初始标记（CMS inital mark）
     只是标记以下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
  2. 并发标记（CMS concurrent mark）
     进行GC Roots跟踪的过程，和用户线程一起工作，不需要赞同工作线程。
  3. 重新标记（CMS remark）
     为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
  4. 并发清除（CMS concurrent sweep）
     清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。
• 由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户线程一起并发工作，所以总体上来看CMS的收集器的内存回收和用户线程是一起并发执行的。

• 图解

  
  
  CMS收集器运行示意图.png
• 三个缺点
  1. 对CPU资源非常敏感
     其实面向并发设计的程序都对CPU资源比较敏感。CMS默认启动的回收线程数是（CPU数量+3）/4 ;
  2. 无法处理浮动垃圾（Floating Garbage）
     可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时在清理掉，这一部分垃圾就称为“浮动垃圾”。
  3. 基于标记-清除算法
     收集结束后会产生大量的空间碎片。

七、G1收集器

• Garbage first收集器时当今收集器理论发展的最前沿成果，一款面向服务端应用的垃圾收集器，与其他GC收集器相比，它具有如下特点。
  1. 并行与并发
     能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop The World停顿时间，仍可通过并发的方式来让Java程序继续执行。
  2. 分代收集
     虽能独立管理GC堆，但它能采用不同的方式区处理新创建的对象和已经存活了一段时间的旧对象以获取更好的收集效果。
  3. 空间整合
     采用“标记-整理”算法，不产生内存碎片。
  4. 可预测的停顿
     可非常精准控制停顿时间，在不牺牲吞吐量的前提下，实现低停顿垃圾回收。有点实时Java(RTSJ)的垃圾收集器的特征。
• G1避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域（Region），并且根据这些区域的垃圾收集进度，同时在后台维护一个优先列表，每次根据所允许的收集时间，优先回收价值最大（回收所获得的空间大小以及回收所需时间的经验值）的区域。区域划分和优先级区域回收机制，确保G1收集器可以在有限时间获得最高的垃圾收集效率。
• 在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，JVM都是通过Remembered Set来避免全堆扫描的。每个Region都有与之对应的Remembered Set。当进行垃圾回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
• 如果不计算Remembered Set操作，G1收集器的运作大致可划分为以下几个步骤
  1. 初始标记（Initial Marking）
  2. 并发标记（Concurrent Marking）
  3. 最终标记（Final Marking）
  4. 筛选回收（Live Data Counting and Evacuation）

• 图解

  
  
  G1收集器运行示意图.png

理解GC日志

例如如下两段典型的GC日志：

33.125: [GC [DefNew: 3324K->152K(3712K), 0.0025925 secs] 3324K->152K(11904K), 0.0031680 secs]

100.667: [Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)],0.0150007 secs] [Times: user=0.01 sys=0.00,real=0.02 secs]

• "33.125"与“100.667”：代表GC发生的时间，这个数字的含义时从JVM启动以来经过的秒数。
• GC日志的开头的“[ GC”和“[ Full GC "说明这次垃圾收集的停顿类型，有"Full"表示经过了Stop The World。
• 接下来“DefNew”、“Tenured”、“Perm ”表明GC发生的区域。
• 后面方括号内部的“3324K->152K(3712K)”含义是“GC前该内存区域已使用容量->GC后该内存区域已使用容量（该内存区域总容量）”
• 方括号之外的“3324K->152K(11904K)”表示“GC 前Java堆已使用容量->GC后Java堆已使用容量（Java堆总容量）”
• “0.0025925 secs”表示该内存区域GC所占用的时间。

垃圾收集器参数总结

UseSerial

虚拟机运行在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)的收集器组合进行内存回收。

UserParallelOldGC

打开此开关后，使用Parallel Scavenge + Parallel Old的收集器组合进行内存回收。

SurvivorRatio

新生代中 Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Survivor=8:1

PretenureSizeThreshold

直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配。

MaxTenuringThreshold

晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后，年龄就增加1，当超过这个参数值时就进入老年代。

UseAdaptiveSizePolicy

动态调整Java堆中各个区域的大小以及进入老年代的年龄。

HandlePromotiveFaliure

是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况。

ParallelGCTreads

设置并行GC时进行内存回收的线程数。

GCTimeRatio

GC时间占总时间的比率，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge收集器时生效。

MaxGCPauseMills

设置GC的最大停顿时间。仅在使用Parallel Scavenge收集器时生效。

CMSInitiatingOccupancyFraction

设置CMS收集器在老年代空间被使用多少后触发垃圾收集器，默认值为68%，仅在使用CMS收集器时生效。

UseCMSCompactAtFullCollection

设置CMS收集器在完成垃圾收集后是否进行一次内存碎片整理。仅在使用CMS收集器时生效。

CMSFullGCsBeforeCompaction

设置CMS收集器在进行若干次垃圾收集器后再启动一次内存碎片整理。仅在使用CMS收集器时生效。