一次JVM GC排查过程及解决方案

背景介绍：

dispatcher-queue-consumer主要负责订阅rocketmq的topic，消费消息进行业务逻辑处理。目前一共有14个消费组，其中轨迹类消费组(3组，其他11类消费组tps量级较低)tps峰值高达10000，均值5000，单机 tps约为5000/8.

prod环境堆内存为2G,垃圾回收算法组合使用Parallel Scavenge+Parallel Old.

统计时段: 所有数据统计均以15-18点为准

优化前fgc 1次/24小时，ygc 6-7次/1分钟， ygc平均耗时在50ms+(1min内累计ygc耗时)

 

                                                                           jvm ygc次数统计（分钟为单位，下同）

                                                                          jvm gc耗时（1min ygc累计耗时，下同）

业内评价gc是否需要优化的标准一般为： ygc耗时<50ms，fgc耗时<1s，fgc频次尽可能低，ygc频次则视qps等情况而定。不少系统ygc 10次/min，仍然可以满足线上应用良好运转。由此可见系统的指标基本正常，但让人诧异的是fgc 1次/24小时，有些频繁。因为这个系统主要是处理消息的，单条消息处理速度在10-ms级别，处理消息时会生产大量的临时对象，但大部分应该是短命的，不应该进入老年代。

对象何时进入老年代：

              1.对象年纪超过MaxTenuringThreshold值，在ygc时直接进行老年代

              2.Survivor区中相同年龄的对象大小的总和大于Survivor空间的一半，年龄>=该年龄的对象直接进入到老年代（有误，参考jvm误区--动态对象年龄判定）

              3.ygc时，survivor空间过小，放不下的对象直接进入老年代参考 

              4.大对象直接进入老年代

探索之路一：

            查看gc.log时，意外发现

  from space 2560K, 86% used [0x00000000ffb00000,0x00000000ffd2c010,0x00000000ffd80000)
  from space 2560K, 86% used [0x00000000ffb00000,0x00000000ffd2c010,0x00000000ffd80000)
  from space 2560K, 100% used [0x00000000ffd80000,0x0000000100000000,0x0000000100000000)
  from space 2560K, 100% used [0x00000000ffd80000,0x0000000100000000,0x0000000100000000)
  from space 3072K, 97% used [0x00000000ffa00000,0x00000000ffcf0000,0x00000000ffd00000)
  from space 3072K, 97% used [0x00000000ffa00000,0x00000000ffcf0000,0x00000000ffd00000)
  from space 3072K, 99% used [0x00000000ffd00000,0x00000000ff