CMS收集器调节

重点当然是要调节CMS收集器，即要避免它在收集时停顿过长，更要避免产生promotion failed和concurrent mode failure的情况，因为这两种情况发生后都会引起CMS做Stop-The-World GC，其中第二中情况在做GC时还会做整理（Compact），因而会有更久的停顿，而我们这次是两种情况同时遇到了。要避免这两种情况的发生需要先理解为什么会发生这两种情况。

首先，我们来看看promotion failed发生的情况：
我们知道当对象到一定的年龄，或者在某次回收过程中一个Survivor无法装下所有存活的对象，或者一个对象的大小超过-XX:PretenureSizeThreshold设置的值，就会被promote到Old Gen中，而在promote过程中如果Old Gen无法装下所有的内存时就会产生promotion failed（这里说CMS是根据预估的值：Modern CMS collector estimates size of objects to be promoted using statistics from previous collections. If old space does not have enough free bytes to hold estimated promotion amount, concurrent mode failure will be raise.但是我的理解是这是ParNew做的GC，为什么由CMS来预估？所以应该是ParNew把需要promote的对象传递给CMS，然后CMS做预估决定是否有足够多的内存存放这些新promote的对象），此时就会先做一遍CMS GC，然后将新promote的对象存放到Old Gen中，由于这属于ParNew GC的范围，因而这次的CMS GC依然处于STW状态，因而这会花比较久的时间。如这次的ParNew GC，花费5.75s：
2015-07-20T08:23:00.028-0400: [GC [ParNew (promotion failed): 844305K->841244K(943744K), 0.2358120 secs][CMS: 6282619K->1891959K(9437184K), 5.5098940 secs] 7126660K->1891959K(10380928K), [CMS Perm : 67716K->66078K(112860K)], 5.7458460 secs] [Times: user=4.77 sys=0.02, real=5.75 secs]

我们当前的设置：-XX:CMSInitiatingOccupancyFraction=79 -XX:+UseCMSInitiatingOccupancyOnly，也就是只有到Old Gen占用79%后才会触发CMS GC，这里只占66.57%，因而还没能触发CMS GC，然而此时ParNew GC只回收了3061K的对象，还有841244K的对象存活，而一个Survivor只有104857.6K大小，此时需要promote大概736386.4K大小的数据到Old Gen中，此时Old Gen还有（9437184K-6282619K=3154565K）大小的内存，虽然远远大于被promote的对象，但是我们知道CMS采用标记-清除（Mark-Sweep）算法，而不主动整理（Compact），但是它在每次回收时会合并相邻的内存空间，然而跑久了难免会产生内存碎片，也就是说此时内存碎片已经很多了，无法容纳新promote的对象，要不就是新promote的对象大小太大，或者碎片太小，因而需要出发一次CMS GC来释放一些空间（此时发生的CMS是不是已经退化成Serial Old收集器算法了？即在收集的过程还是整理？），以保证能存放下所有新promote出的对象。这里GC日志中并没有显示出什么这次ParNew GC后，Young Gen还剩下多少内存，但是根据下一次ParNew GC的初始大小是838912K，小于之前存活下来的对象（841244K），因而我们可以确定这次GC的结果是把多余的对象promtoe到Old Gen中了。
所以根据分析，我们可以从两个方向调节参数：
1. 降低CMS GC的阈值。
2. 提前减少Old Gen中的碎片，即让CMS GC做整理。
对降低CMS GC阈值，我们可以调节参数：-XX:CMSInitiatingOccupancyFraction，默认大小68，我们可以将它设置成60。对提前减少Old Gen的碎片，这个比较麻烦，我们不想每次CMS GC都做整理（Compact），因而这会比较浪费，会增加GC总体的时间以及停顿的时间，而且也比较危险，因为万一某次整理时间太长会引起集群的不稳定（可以设置-XX:UseCMSCompactAtFullCollection来实现这个功能）。还有一种办法是设置每经历N次CMS后做一次整理，通过-XX:CMSFullGCsBeforeCompaction=<N>来设置，这个相对可以接受一些。当然如果能找到一个相对空闲的时间手动触发一次Full GC，并且确保让它能触发整理（这个目前还没有找到合适的方法，JConsole提供的GC按钮是一个可选项，但是不确定。我做了一下尝试：

2015-07-31T16:04:49.183+0800: [Full GC (System) [CMS: 3861443K->1072505K(9437184K), 2.9535440 secs] 4458634K->1072505K(10380928K), [CMS Perm : 68183K->67112K(112880K)], 2.9537000 secs] [Times: user=2.94 sys=0.00, real=2.95 secs]
看起来是减少了不少内存，按日志的格式，看起来像是Serial Old的算法？另外，使用这个功能要确保-XX:-DisableExplicitGC是关闭的，虽然这就是默认值）。

关于产生promotion failed，这里还有更详细的解释，如涉及到PLAB（Promotion Local Allocation Buffer）的介绍等，以及这里是对它的更正。值得注意的是，CMS在管理内存中使用空闲列表的方式，然而这种方式可能会存在某些问题，如这句话所说（具体就不展开了）：
CMS memory manager is using separate free lists for different size of chunks. Using these free lists, it can effectively fill small holes in fragmented memory space with objects of exact size. This technique is known to be fairly effective (and widely used in C/C++ memory managers). But, surprisingly, it doesn't seems to work well for JVM in many real live situations.

然后，再来看看concurrent mode failure的情况：
依然是这篇文章，作者说concurrent mode failure是在Young GC发生前，它会预估Old Gen是否有足够的空间存放从Young Gen中promote上来的对象，CMS收集器根据之前统计来预估这些对象的大小，如果Old Gen没有足够的空间存放这个预估的值，就会发生concurrent mode failure。此时不一定会产生Full GC，有些时候JVM只是等待当前并行收集完成，但是用户程序此时还是会STW直到这次收集技术。
At beginning  of each young GC, collector should ensure that there is enough free memory in old space to promote aged objects from young space. Modern CMS collector estimates size of objects to be promoted using statistics from previous collections. If old space does not have enough free bytes to hold estimated promotion amount, concurrent mode failure will be raise. Concurrent mode failure doesn't necessary lead to Full GC, in certain cases JVM will just wait for concurrent collection cycle to finish, but application will remain in STW pause until young collection will be finished.

然而根据我的观察，concurrent mode failure都是发生在CMS已经开始，但是在中间阶段，出现ParNew的promotion failed。
如这是发生在CMS-concurrent-abortable-preclean阶段：

这是发生在CMS-concurrent-sweep阶段：

这是发生在CMS-concurrent-mark阶段：

虽然分析了那么多，还有一个疑问没能解决，对这个问题的调节方法还是一样的：1. 降低CMS GC的阈值；2. 提前减少Old Gen中的碎片，即让CMS GC做整理。这里不再赘述。

最后，我们可以看看其他的调节方式：
1. 我们知道CMS收集器很多过程是并发进行的，因而我们可以控制并发线程的个数：-XX:ParallelCMSThreads=4，我们采用的值是4，和ParNew相同。CMS默认的回收线程数是(CPU个数+3)/4。
2. 在历史上还出现过增量式并发收集器（Incremental Concurrent Mark Sweep，i-CMS）。因为对少于4个CPU的时候，如果GC占用一般左右的CPU资源，会影响用户线程的吞吐量，因而增量式并发收集器的思想是在并发标记和并发清理时让用户线程和GC线程交替运行以减少GC占用太多的资源，特别是在只有一个CPU的情况下，即使在CMS并发阶段，还是会产生STW的现象，因而可以使用i-CMS来避免这种情况。然而i-CMS已经不再推荐使用，具体可以参考这里。大概的原因是现在已经很少只有一个CPU的硬件了，而且i-CMS在线程切换时会花费更多的资源和时间，它更加复杂，有更多的参数，难以调节，会产生更多的碎片。

3. 可以简单介绍一下CMS的整个过程（还可以参考这里，或者这里，虽然这里用的例子是1.4.2的版本，我用的是1.6.30，会有一些区别）。以一个正常的CMS为例：

1 CMS-initial-mark：初始标记标记阶段，STW，CMS起始点，标记所有Root对象直接可达的对象，7462216K是CMS触发时Old Gen的内存大小，7583692K是Old Gen＋Young Gen的内存大小。
CMS-concurrent-mark：重新标记阶段，和用户线程同时处理，遍历初始标记出来的对象的所有直接或间接可达对象。CPU时间0.365s，总共0.365s（wall time）。这里times时间不是那么准确，因为起于该阶段的开始，但是中间可能包含其他的事情，如用户线程的执行影响等。

CMS-concurrent-preclean：preclean阶段，这个阶段依然和用户线程同时处理，它会继续查看在重新标记阶段新产生的对象：从Young Gen promote上来的对象，新分配的对象，或被修改的对象。这个阶段主要用于减少下一次重新标记（remark）的时间，因为重新标记会STW。CPU时间0.020s，总共0.020s（wall time）。
CMS-concurrent-abortable-preclean：可中断的preclean阶段，和用户线程同时处理，当preclean已经结束的时候就可以开始remark了，然而如果这样设计，由于CMS-concurrent-preclean和用户线程一起运行，当它结束的时候，Young Gen已经使用了很多了，但是这里面有很多是可以回收的，为了提升效率就可以先ParNew GC回收掉多余的对象，然后就会接着执行remark，就可以减少remark的时间；而如果Young Gen使用的很少，就可以立即启动remark过程；而如果介于之间，就可以先等待一会让eden占用一些空间后再启动remark，从而将ParNew GC的STW和remark的STW错分开。因而CMS的设计者就想出remark的执行时机还依赖于eden的使用情况（因为新对象总是先分配到eden空间），即通过两个变量来控制：CMSScheduleRemarkEdenSize和CMSScheduleRemarkEdenPenetration，它们的默认值分别是2M和50%，表示在CMS-concurrent-preclean结束后，如果eden只使用了少于2M，则直接启动remark；如果超过2M，但没有超过50%，则先启动CMS-concurrent-abortable-preclean，直到eden的使用率超过了50%，然后启动remark过程，这样就保证了remark和ParNew GC中间会有一定的时间间隔；如果已经超过了50%，就等待下次ParNew GC完成，然后再做remark？貌似只有这样才能解释的通这些日志，当remark阶段准备好后它可以随时被中断，它的中断不是错。如这种日志：

这个日志表示preclean结束后eden使用少于2M，因而跳过abortable-preclean，直接开始remark阶段。

1 CMS-remark：重新标记阶段，STW，这里YG occupancy表示该阶段开始时Young Gen的大小，因为这个阶段的时间长短部分依赖于Young Gen的大小；Rescan用于多线程扫描程序停止时存活的对象，花费0.1319540s；weak refs processing用于处理weak reference的情况，花费0.0001s，如果这个阶段花费太长时间，可以打开开关：-XX:+ParallelRefProcEnabled来调节；然后开始重新标记，即重新从Root对象遍历标记存活对象。
CMS-concurrent-sweep：并发清理，和其他线程同时执行，做真正的清理工作，如把可以回收的内存放回空闲列表，合并相邻内存空间等。

CMS-concurrent-reset：重置CMS的状态用于下一次执行。