系统频繁Full GC导致系统卡顿是怎么回事?以下为业务场景出现的问题:
机器配置:2核4GJVM内存大小:2G系统运行时间:7天期间发生的Full GC次数和耗时:500多次,200多秒期间发生的Young GC次数和耗时:1万多次,500多秒
大致算下来每天会发生70多次Full GC,平均每小时3次,每次Full GC在400毫秒左右;
每天会发生1000多次Young GC,每分钟会发生1次,每次Young GC在50毫秒左右。
JVM参数设置如下:
‐ Xms1536M ‐ Xmx1536M ‐ Xmn512M ‐ Xss256K ‐ XX : SurvivorRatio = 6 ‐ XX : MetaspaceSize = 256 M ‐ XX : MaxMetaspaceSize = 256 M ‐ XX : + UseParNewGC ‐ XX : + UseConcMarkSweepGC ‐ XX : CMSInitiatingOccupancyFraction = 75 ‐ XX : + UseCMSInitiatingOccupancyOnly
经过分析对象挪动到老年代的规则,可以大致感觉到是对象动态年龄判断机制导致频繁FullGC。
所以启jstat命令,分析堆内存各部分的使用情况,大致如下图所示:
对于对象动态年龄判断机制导致的full gc较为频繁可以先试着优化下JVM参数,把年轻代适当调大点:
‐ Xms1536M ‐ Xmx1536M ‐ Xmn1024M ‐ Xss256K ‐ XX : SurvivorRatio = 6 ‐ XX : MetaspaceSize = 256 M ‐ XX : MaxMetaspaceSize = 256 M ‐ XX : + UseParNewGC ‐ XX : + UseConcMarkSweepGC ‐ XX : CMSInitiatingOccupancyFraction = 92 ‐ XX : + UseCMSInitiatingOccupancyOnly
设置程序启动参数后,JVM内存模型如下图所示:
优化完发现没什么变化,full gc的次数比minor gc的次数还多了:
我们可以推测下full gc比minor gc还多的原因有哪些?
1、元空间不够导致的多余full gc
2、显示调用
System.gc()
造成多余的
full gc
,这种一般线上尽量通过
XX:+DisableExplicitGC
参数禁用,如果加上了这个
JVM
启动参数,那
么代码中调用
System.gc()
没有任何效果
3
、老年代空间分配担保机制
最快速度分析完这些我们推测的原因以及优化后,我们发现young gc和full gc依然很频繁了,而且看到有大量的对象频繁的被挪动到老年代,这种情况我们可以借助jmap命令大概看下是什么对象
查到了有大量User对象产生,这个可能是问题所在,但不确定,还必须找到对应的代码确认,如何去找对应的代码了?
1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)
2、如果生成User对象的地方太多,无法定位具体代码,我们可以同时分析下占用cpu较高的线程,一般有大量对象不断产生,对应的方法代码肯定会被频繁调用,占用的cpu必然较高。
这时候我们就需要用到jstack或者jvisualvm来定位cpu使用较高的代码,最终定位到代码如下:
1 import java . util . ArrayList ;23 @RestController4 public class IndexController {56 @ RequestMapping ( "/user/process" )7 public String processUserData () throws InterruptedException {8 ArrayList < User > users = queryUsers ();910 for ( User user : users ) {11 //TODO 业务处理12 System . out . println ( "user:" + user . toString ());13 }14 return "end" ;15 }1617 /**18 * 模拟批量查询用户场景19 * @ return20 */21 private ArrayList < User > queryUsers () {22 ArrayList < User > users = new ArrayList <> ();23 for ( int i = 0 ; i < 5000 ; i ++ ) {24 users . add ( new User ( i , "zhuge" ));25 }26 return users ;27 }28 }
可以看到,代码也需要优化,一次性查询出5千个对象,大约1个User对象是1KB,那么5千个就是500M,也就是说一次性需要查询出500M的新生对象,那么根据老年代担保机制,年轻代每minor gc之前JVM都会计算下老年代剩余可用空间 ,如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象),那么就会触发一次fullGC,显然我们的老年代根本无法存储新生的对象,需要触发一次FullGC,然后再执行一次MinoGC,执行完之后,如果存活的对象还是大于老年代剩余空间,就又会导致一次FullGC,相当于一次MinorGC,会导致两次FullGC,依次类推,系统运行下去,FullGC的频率会不断增大,导致我们的系统运行会越来越卡顿。
综上所述,我们需要尽量减少这种朝生夕死对象导致的FullGC。
总结一下自己的JVM调优思路,仅供参考:
1)尽量减少YongGC后存活的对象大于Survivor区50%,让存活对象尽量保留在年轻代,尽量别让对象进入老年代。
2)尽量减少FullGC的频率,避免频繁FullGC对JVM性能的影响。