CMS 解决浮动垃圾的方式——2017.05消息组件性能压测学习笔记

RocketMQ在较早版本（3.X）的时候，用的就是CMS。工作中基于rocketmq改造的中间件，开始也基于3.5.8版本，2017.05我负责性能调优的时候，就发现满载的时候，经常会规律性地出现较大的tps波动.然后做了一些JVM的调优测试，也将CMS的一些学习笔记记录下来。
CMS GC要决定是否在full GC时做压缩，会依赖以下几个条件：
1.UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction 是搭配使用的.默认是true，什么时候清理浮动垃圾（压缩整理）取决于后者。
2.用户调用了System.gc()，而且DisableExplicitGC没有开启。
3.young gen报告接下来如果做增量收集会失败；简单来说也就是young gen预计old gen没有足够空间来容纳下次young GC晋升的对象。
上述三种条件的任意一种成立都会让CMS决定这次做full GC时要做压缩。

CMSFullGCsBeforeCompaction 说的是，在上一次CMS并发GC执行过后，到底还要再执行多少次full GC才会做压缩（默认0）。也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。
把CMSFullGCsBeforeCompaction配置为n，就会让上面说的第一个条件变成每隔n次真正的full GC才做一次压缩，这会减少full GC压缩的次数，节省了gc时间，也就更容易使CMS的old gen受碎片化问题的困扰。 本来这个参数就是用来配置降低full GC压缩的频率，以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact，但compaction是可选的，不做的话碎片化会严重些但这次full GC的暂停时间会短些；这是个取舍。