如何了解CMS垃圾碎片率

PrintFLSStatistics这个参考比较有用，因为CMS GC会有碎片问题，而随着碎片的越来越严重，GC性能会变差直到发生FullGC，而FullGC时STW通过会超过数秒，这对OLTP系统来说是致命的，通过这个参数可以在gc日志中输出free list方式分配内存后内存统计情况和碎片情况；

从CompactibleFreeListSpace的描述可知CMS使用free list分配内存

-- 源码摘自compactibleFreeListSpace.hpp：

PrintFLSStatistics参数

再看compactibleFreeListSpace.cpp中的和（prologue的中文意思是开场白，epilogue的中文意思是收场白，所以这两个方法可以理解为gc前和gc后），由两个方法的实现可知，如果JVM参数PrintFLSStatistics 不为0（负数也可以），那么每次GC前后都会调用reportFreeListStatistics()方法打印出free list的统计信息：

再看reportFreeListStatistics的具体实现，分为两个部分来看：

第一部分是_dictionary->report_statistics()输出BinaryTreeDictionary统计信息；

第二部分是当PrintFLSStatistics >1时输出的附加log即IndexedFreeLists统计信息；

第一部分即BinaryTreeDictionary统计信息：

输出free list统计信息，gc日志中输出内容如下：

Total Free Space: 25165824

Max Chunk Size: 25165824

Number of Blocks: 1

Av. Block Size: 25165824

Tree Height: 1

第二部分即IndexedFreeLists统计信息：

如果JVM参数为PrintFLSStatistics 大于1，例如-XX:PrintFLSStatistics=2，那么还会输出IndexedFreeLists的统计信息，以及如下的gc日志，能够直观的看到碎片率，frag的值越大碎片化越严重，JVM的初始化时frag的值为0.0000，即没有任何碎片：

实际GC日志

为了查询碎片化率越来越严重的GC日志，笔者基于kafka 2.11-1.1.1版本，对其GC参数进行了一些调整，从而引起不断CMS GC：

调整kafka-server-start.sh

调整kafka-run-class.sh

调整kafka-run-class.sh是为了屏蔽默认使用的G1，因为配置的CMS GC不能和G1共存。

接下来只需要启动一个kafka broker，然后利用kafka自带的压测脚本向broker发送1kw条消息（每条消息128个字节）：

jstat结果

由jstat可知，FGC非常严重，每2s就有好几次的FGC：

gc日志

再看gc日志，kafka默认开启了gc日志（位于：logs/kafkaServer-gc.log.0.current）：

由日志可知，越来越大（初始为1）。而这个值越大，表示碎片率越严重。这个参数，能够让我们确定那些由于碎片化问题导致的CMS的并发模式失败。