垃圾收集器

垃圾收集器是内存回收的具体体现

3.5.1 Serial 收集器

Serial 收集器是最基本、发展历史最悠久的收集器，曾经是(JDK1.3之前)虚拟机新生代的唯一选择。单线程收集器，它在垃圾回收时必须暂停其他所有工作线程，直到它结束。下图为其工作示意图：

优点：简单且高效，对单线程CPU来说 无线程交互开销
缺点：可能会产生较长的停顿
Serial 收集器对于运行于Client模式下最好的选择

3.5.2 Serial Old 收集器

Serial Old是 serial的老年代版本， 单线程收集器，使用"标记-清理"算法
意义：

• Client模式下虚拟机使用
• Server 模式下有两种用途：一是，JDK1.5以及之前版本中于Parallel Scavenge收集器（详见3.5.4）搭配使用；另一种为CMS收集器的后备预案。工作过程详见3.5.1图

3.5.3 ParNew收集器

ParNew收集器是Serial收集器的多线程版本
除此之外，其余行为和Serial收集器相同，包括：

• Serial可用的所有控制参数（eg:-XX:SurivvorRatio、-XX：PretenureSizeThreshold、-XX:HandlePromotionFailure等）
• 收集算法
• Stop The World
• 对象分配规则
• 回收策略等
  工作过程如下图：
  
  应用场景：
  在Server模式下，虚拟机首选的新生代收集器，因为除Serial外，目前只有它能与CMS收集器配合工作；
  但在单个CPU环境中，不会比Serail收集器有更好的效果，因为存在线程交互开销。
  控制参数：
  除和Serial相同的控制参数外，他还有如下控制参数：
• -XX:+UseConcMarkSweepGC：指定使用CMS后，会默认使用ParNew作为新生代收集器；
• -XX:+UseParNewGC：强制指定使用ParNew；
• -XX:ParallelGCThreads：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；

3.5.4 Parallel Scavenge 收集器

Parallel Scavenge 是一个新生代，使用复制算法，并行的多线程收集器，java1.8默认的收集器
工作过程如下图：

特点：
它的关注点与其他收集器不同，ParallelScavenge收集器的目标则是达到一个可控制的吞吐量。
吞吐量=运行用户代码时间 / (运行用户代码时间 + 垃圾收集器时间)。假设虚拟机总共运行100分钟，垃圾收集花掉1分钟，则吞吐量为99%，
因此也被称为 “吞吐量优先”的收集器
重要参数：
重要参数有三个，分别为：

• 控制最大垃圾收集停顿时间 -XX:MaxGCPauseMillis
  参数值允许大于0 的毫秒数，收集器尽可能的保证内存回收花费时间不超过设定值。要合理设定，不要以为设置的稍小点，就能使垃圾时间变快，GC的停顿时间是以牺牲吞吐量和新生代换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
• 设置吞吐量大小的 -XX:GCTimeRatio
  GCTimeRatio的参数的值是一个 0<参数值<100 的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的单数。
  若参数设置成19 允许最大GC时间就占总时间的 1/(1+19)=5%,默认值为99，就是允许最大为 99/(99+1)=1%的垃圾时间
• 开关参数 -XX:UseAdaptiveSizePolicy
  参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）
  自适应调节策略:
  Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio参数（更关注吞吐量）给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

3.5.5 Parallel Old 收集器

Parallel Old 是Parallel Scavenge 收集器的老年代版本，JDK 1.6中才开始提供，在此之前 新生代选择了Parallel Scavenge 老年代只能选择 Serial Old 收集器。
在注重吞吐量和CPU资源敏感的场合可优先考虑 Parallel Scavenge+Parallel Old组合。
运行示意图见 3.5.4

3.5.6 CMS 收集器

CMS 收集器是一种以 获取最短停顿时间为目标 的收集器，非常符合在重视服务响应速度和系统停顿时间短的应用的需求，
CMS收集器是HotSpot虚拟机中的一款真正意义上的并发收集器，第一次实现了让垃圾回收线程和用户线程（基本上）同时工作。用CMS收集老年代的时候，新生代只能选择Serial或者ParNew收集器
运行过程：
CMS 收集器基于“标记-清除”算法，整个过程分为4个步骤：

• 初始标记

• 并发标记

• 重新标记

• 并发清除
  初始标记、重新标记这两个步骤任然需要停顿其他用户线程（Stop The World）。初始标记仅仅只是标记出GC Roots能直接关联到的对象，速度很快，并发标记阶段是进行GC Roots Tracing（根搜索会判定对象是否存活）。而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。
  由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的
  
  优点：

• 并发收集

• 低停顿
  缺点：

• 对CPU资源十分敏感，占用CPU资源，导致应用程序变慢；

• 无法处理浮动垃圾（标记过之后产生的垃圾），可能出现“Concurrent Mode Failure”失败而导致的另一次Full GC产生；

• CMS基于“标记—清除”算法实现，在垃圾收集结束后，会产生大量空间碎片，空间碎片过多时，不利于大对象的分配，从而导致提前触发 Full GC

3.5.7 G1 收集器

一款面向服务端应用的收集器，JDK1.7中HotSpot虚拟机的一个重要进化特征，与其他GC收集器相比，G1具备以下特点：

• 并发与并行：通过多CPU来缩短Stop-The-World停顿的时间
• 分代收集
• 空间整合：采用标记-整理算法
• 可预测的停顿：G1收集器除追求低停顿外，还能建立可预测的停顿模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒