(本篇主要以CMS-GC为主,如果对G1感兴趣的我后面也可以补充)
一、GC参数说明与介绍
1.1 jvm启动参数分为三类:
| 类型 | 描述 |
|---|---|
| 第一类是标准参数（-） | 所有的JVM实现都必须实现这些参数的功能，而且向后兼容 |
| 第二类是非标准参数（-X） | 默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容 |
| 第三类是非Stable参数（-XX） | 此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用；此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用 |
1.2 jvm内存相关的配置
1.3 GC收集器相关的配置
1.4 通用参数相关的配置
1.5 CMS重要配置参数
1.6 日志输出相关配置参数
二、STW指标(重点)
众所周知CMS-GC是采用标记清除算法, CMS-GC主要分成7个步骤:
初始标记(Initial Mark)：为了收集应用程序的对象引用需要暂停应用程序线程，该阶段完成后，应用程序线程再次启动。
并发标记(Concurrent Mark)：从第一阶段收集到的对象引用开始，遍历所有其他的对象引用。
并发预清理(Concurrent Preclean)：改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果。
可终止的并发预清理(Concurrent Abortable Preclean)：这个阶段尝试着去承担STW的Final Remark阶段足够多的工作。这个阶段持续的时间依赖好多的因素，由于这个阶段是重复的做相同的事情直到发生aboart的条件（比如：重复的次数、多少量的工作、持续的时间等等）之一才会停止
重新标记(Final Remark)：最后一个STW的阶段, 在这里所有不再被应用的对象将从堆里被清除掉。这个阶段会标记老年代全部的存活对象，包括那些在并发标记阶段更改的或者新创建的引用对象. 尽管先前的pre clean阶段尽量应对处理了并发运行时用户线程改变的对象应用的标记，但是不可能跟上对象改变的速度，只是为final remark阶段尽量减少了负担
并发清理(Concurrent Sweep)：这个阶段主要是清除那些没有标记的对象并且回收空间
并发重置(Concurrent Reset)：收集器做一些收尾的工作，以便下一次GC周期能有一个干净的状态。
其中5个阶段(名字以Concurrent开始的)与实际的应用程序是并发执行的，而其他2个阶段需要暂停应用程序线程(STW), 而且STW时间主要耗时在remark阶段(大约占了80%)
下面是我截的一台应用服务器当时的GC日志图, 我们的告警里面的STW时间实际是统计只有remark阶段的耗时,其实并没有统计初始标记阶段的耗时,严格意义上来说是不准确的,换句话来说实际我们的STW时间更长远超了810毫秒.
其实从耗时上我们可以看出, 主要耗时在处理引用上面,看JVM源码，weak refs processing主要包括SoftReference、WeakReference、FinalReference、PhantomReference以及JNI Weak Reference这五种Reference对象的处理，处理的主要内容是对之前标记的Reference对象重新处理，重新判断是否需要标记（不标记就是要回收的），如果不标记就需要放到refqueue里，等待java ReferenceHandler线程处理。
所以从工作的主要内容看各种Reference的处理时间跟reference的个数成正比。那么接下来我们需要做的是确定是哪种Reference比较耗时，然后进行针对性优化。所以加了个参数-XX:+PrintReferenceGC，来具体显示各种Reference的个数和处理时间。
三、重要参数的调整:
-
3.1 -XX:+CMSScavengeBeforeRemark
在CMS GC前启动一次young Gc,目的在于减少old Gen对young Gc Gen的引用, 降低remark阶段的开销, 但是也存在一些情况不生效:
下面是笨神的回复:
3.2 -XX:+ParallelRefProcEnabled
并行处理Reference，加快处理速度，缩短耗时3.3 我看到也有同事 配置了-XX:CMSInitiatingOccupancyFraction=55 , 调小了参数想提前CMS启动垃圾回收, 这个视情况而定, 有可能会增加GC的频次.关于CMSInitiatingOccupancyFraction这个参数(标志来命令JVM不基于运行时收集的数据来启动CMS垃圾收集周期),如果你搭配了UseCMSInitiatingOccupancyOnly一起使用, 它会每次都按照这个域值去触发, 不然垃圾回收器会根据自己的决策去浮动(只有第一次按照这个值去触发). 所以这里想说明的一点是, 你的参数设置如果没有基于大量的测试, 还不如交由CMS自己去做决策.
四、什么是FullGC
- 触发STW的才是真正的FullGC, 这个容易和Major Gc混淆, 因为Major Gc的作用域仅仅只是老年代空间
五、 FullGC发生的条件
- 调用System.gc
- 老年代空间不足
- 永久代空间不足
- gc 担保失败
- Cocurrent mode failure
六、可以发布其中一台服务后做横向对比,观察一段时间
七、选型
如果是对于大内存的服务, 比如你的服务器是16G、32G其实完全可以用G1, 目前G1也是java9默认的垃圾回收器,G1在内存不吃紧的情况下会可以做到灵活回收和大大降低大堆停顿.
