CMS 垃圾回收

http://blog.csdn.net/java2000_wl/article/details/8030172

先说并发

4.1并发意味着多线程抢占CPU资源，即GC线程与用户线程抢占CPU。这可能会造成用户线程执行效率下降。

CMS默认的回收线程数是(CPU个数+3)/4。这个公式的意思是当CPU大于4个时,保证回收线程占用至少25%的CPU资源，这样用户线程占用75%的CPU，这是可以接受的。

4.2 并发清理阶段用户线程还在运行，这段时间就可能产生新的垃圾，新的垃圾在此次GC无法清除，只能等到下次清理。这些垃圾有个专业名词：浮动垃圾。

由于垃圾回收阶段用户线程仍在执行，必需预留出内存空间给用户线程使用。因此不能像其他回收器那样，等到老年代满了再进行GC。

CMS 提供了CMSInitiatingOccupancyFraction参数来设置老年代空间使用百分比,达到百分比就进行垃圾回收。

这个参数默认是92%，参数选择需要看具体的应用场景。

设置的太小会导致频繁的CMS GC，产生大量的停顿；反过来想，设置的太高会发生什么？

假设现在设置为99%，还剩1%的空间可以使用。

在并发清理阶段，若用户线程需要使用的空间大于1%，就会产生Concurrent  Mode Failure错误，意思就是说并发模式失败。

这时，虚拟机就会启动备案：使用Serial Old收集器重新对老年代进行垃圾回收.如此一来，停顿时间变得更长。

4.3 前两个问题是由并发引起的，接下来要说的问题就是由标记-清除算法引起的。

使用标记-清除算法可能造成大量的空间碎片。空间碎片过多，就会给大对象分配带来麻烦。

往往老年代还有很大剩余空间，但无法找到足够大的连续空间来分配当前对象,不得不触发一次Full GC。

CMS的解决方案是使用UseCMSCompactAtFullCollection参数(默认开启)，在顶不住要进行Full GC时开启内存碎片整理。

这个过程需要STW，碎片问题解决了,但停顿时间又变长了。

虚拟机还提供了另外一个参数CMSFullGCsBeforeCompaction，用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认为0，每次进入Full GC时都进行碎片整理）。