垃圾收集器组合

JDK7/8后，HotSpot虚拟机所有收集器及组合（连线），如下图：

image

• 图中展示了7种不同分代的收集器：
  Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1；

• 而它们所处区域，则表明其是属于新生代收集器还是老年代收集器：
  新生代收集器：Serial、ParNew、Parallel Scavenge；
  老年代收集器：Serial Old、Parallel Old、CMS；
  整堆收集器：G1；

• 两个收集器间有连线，表明它们可以搭配使用

• 其中Serial Old作为CMS出现"Concurrent Mode Failure"失败的后备预案

CMS收集器

并发标记清理（Concurrent Mark Sweep，CMS）收集器也称为并发低停顿收集器（Concurrent Low Pause Collector）或低延迟（low-latency）垃圾收集器；

1、特点

针对老年代；
基于"标记-清除"算法(不进行压缩操作，产生内存碎片)；
以获取最短回收停顿时间为目标；
并发收集、低停顿；
需要更多的内存

2、应用场景

与用户交互较多的场景；
希望系统停顿时间最短，注重服务的响应速度，以给用户带来较好的体验；
如常见WEB、B/S系统的服务器上的应用；

3、设置参数

"-XX:+UseConcMarkSweepGC"：指定使用CMS收集器；

4、CMS收集器运作过程

分4步：
（1）初始标记（CMS initial mark）
仅标记一下GC Roots能直接关联到的对象；
速度很快；
但需要"Stop The World"；
（2）并发标记（CMS concurrent mark）
进行GC Roots Tracing的过程；
刚才产生的集合中标记出存活对象；
应用程序也在运行；
并不能保证可以标记出所有的存活对象；
（3）重新标记（CMS remark）
为了修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象的标记记录；
需要"Stop The World"，且停顿时间比初始标记稍长，但远比并发标记短；
采用多线程并行执行来提升效率；
（4）并发清除（CMS concurrent sweep）
回收所有的垃圾对象；

整个过程中耗时最长的并发标记和并发清除都可以与用户线程一起工作；
所以总体上说，CMS收集器的内存回收过程与用户线程一起并发执行；
CMS收集器运行示意图如下：

image

5、CMS收集器3个明显的缺点

（1）对CPU资源非常敏感
并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低。
CMS的默认收集线程数量是=(CPU数量+3)/4；
当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。

（2）无法处理浮动垃圾，可能出现"Concurrent Mode Failure"失败

• 浮动垃圾（Floating Garbage）
  在并发清除时，用户线程新产生的垃圾，称为浮动垃圾；
  这使得并发清除时需要预留一定的内存空间，不能像其他收集器在老年代几乎填满再进行收集；
  也可以认为CMS所需要的空间比其他垃圾收集器大；
  "-XX:CMSInitiatingOccupancyFraction"：设置CMS预留内存空间；
  如：
  -XX:CMSInitiatingOccupancyFraction=70
  CMS垃圾收集器，当老年代达到70%时，触发CMS垃圾回收。
• "Concurrent Mode Failure" 失败
  如果CMS预留内存空间无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败；
  这时JVM启用后备预案：临时启用Serail Old收集器，而导致另一次Full GC的产生；
  这样的代价是很大的，所以CMSInitiatingOccupancyFraction不能设置得太大。

（3）产生大量内存碎片
由于CMS基于"标记-清除"算法，清除后不进行压缩操作；
产生大量不连续的内存碎片会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。
解决方法：

• -XX:+UseCMSCompactAtFullCollection
  使得CMS出现上面这种情况时不进行Full GC，而开启内存碎片的合并整理过程；
  但合并整理过程无法并发，停顿时间会变长；
  默认开启（但不会进行，结合下面的CMSFullGCsBeforeCompaction）；
• -XX:+CMSFullGCsBeforeCompaction
  设置执行多少次不压缩的Full GC后，来一次压缩整理；
  为减少合并整理过程的停顿时间；
  默认为0，也就是说每次都执行Full GC，不会进行压缩整理；