jvm GC参数调优

(本篇主要以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在内存不吃紧的情况下会可以做到灵活回收和大大降低大堆停顿.