1. 背景
线上某一个服务虽然没有Full GC， 但是Young GC耗时一直居高不下，更重要的是Olden区的最大使用量与日递增。集群机器配置是8C16G， 使用的是G1垃圾回收器， 目标停顿时间是200ms， Xmx和Xms配置是12.8G(机器内存的80%)。
Young GC次数与耗时如图1所示，Eden、Survivor、老年代使用情况如图2、3、4所示，为展示效果，时间段截取某次发布后的多天，可以明显地看到老年代的最大使用量一直在递增。
图1 Young GC次数与耗时
图2 Eden使用情况
图3 Survivor使用情况
图4 老年代使用情况
2. 排查与优化
刚开始怀疑是有内存泄露，但是通过MAT排查没有发现问题，从老年代使用情况来看，不断地有对象进入老年代。在排除其他可能后，将怀疑的目光聚集在Region Size。该服务是一个方案排序服务，报文比较大，几兆到十几兆不等。
我们知道G1垃圾收集器与之前垃圾收集器最大的不同就是化整为零，将内存区域分成多个Region，每个Region可能是E、S、O、H的一种，如图5所示。
图5 G1内存布局
其中H代表Humongous，表示这些Region存储的是巨大对象（humongous object，H-obj），即大小大于等于region一半的对象。H-obj有如下几个特征：
- H-obj直接分配到老年代，防止被反复拷贝移动。
- H-obj在global concurrent marking阶段的cleanup 和 full GC阶段回收。
- 在分配H-obj之前先检查是否超过 initiating heap occupancy percent和the marking threshold, 如果超过的话，就启动global concurrent marking，为的是提早回收，防止 evacuation failures 和 full GC。
Region size通过heapSize/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region size为32M)，Region size必须是2的指数，取值范围从1M到32M。针对于12.8G的堆内存，Region Size是4M， 前面提到内部有很多对象的大小为几兆到十几兆，远大于4M的一半，因此这些对象会被分配到H区，造成老年代的使用不断增加。
将Region大小调到16M或者32M时，GC情况会有明显的好转，当region size 为32M时(16M效果近似)，Young GC次数与耗时如图6所示，Eden、Survivor、老年代使用情况如图7、8、9所示。
- Young GC次数：调整前每分钟平均10次左右，调整后为5次左右
- Young GC耗时：调整前平均耗时400ms，调整后50ms
- Eden使用情况： 调整前平均2GB，调整后3.3GB
- Survivor使用情况：调整前24MiB，调整后50MiB
- 老年代使用情况： 调整前不断增加，调整后稳定在295MiB
图6 调整后Young GC次数与耗时
图7 调整后Eden使用情况
图8 调整后Survivor使用情况
图9 调整后老年代使用情况
网友评论