FullGC问题分析及解决办法总结

一、常见的FullGC场景分析

1.1、频繁的大对象，大对象直接被分配到老年代。

1.2、系统高负载运行，请求量很大，jvm来不及将对象转移到老年代，直接到老年代分配对象。

1.3、系统内存泄漏，导致对象长时间在老年代，得不到释放。

二、产生FullGC的原因

2.1、System.gc()方法的调用

在代码中调用System.gc()方法会建议JVM进行Full GC，但是注意这只是建议，JVM执行不执行是另外一回事儿，不过在大多数情况下会增加Full GC的次数，导致系统性能下降，一般建议不要手动进行此方法的调用，可以通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

2.2、老年代的空间不足

在Survivor区域的对象满足晋升到老年代的条件时，晋升进入老年代的对象大小大于老年代的可用内存，这个时候会触发Full GC。

2.3、Metaspace区内存达到阈值

从JDK8开始，永久代(PermGen)的概念被废弃掉了，取而代之的是一个称为Metaspace的存储空间。Metaspace使用的是本地内存，而不是堆内存，也就是说在默认情况下Metaspace的大小只与本地内存大小有关。-XX:MetaspaceSize=21810376B（约为20.8MB）超过这个值就会引发Full GC，这个值不是固定的，是会随着JVM的运行进行动态调整的。

jdk8 Metaspace 调优

Survivor区域对象晋升到老年代有两种情况：

1、 一种是给每个对象定义一个对象计数器，如果对象在Eden区域出生，并且经过了第一次GC，那么就将他的年龄设置为1，在Survivor区域的对象每熬过一次GC，年龄计数器加一，等到到达默认值15时，就会被移动到老年代中，默认值可以通过-XX:MaxTenuringThreshold来设置。

2、另外一种情况是如果JVM发现Survivor区域中的相同年龄的对象占到所有对象的一半以上时，就会将大于这个年龄的对象移动到老年代，在这批对象在统计后发现可以晋升到老年代，但是发现老年代没有足够的空间来放置这些对象，这就会引起Full GC。

这个参数可以通过-XX:PretenureSizeThreshold进行设定，大对象或者长期存活的对象进入老年代，典型的大对象就是很长的字符串或者数组，它们在被创建后会直接进入老年代，虽然可能新生代中的Eden区域可以放置这个对象，在要放置的时候JVM如果发现老年代的空间不足时，会触发GC。

2.4、老年代连续空间不足

JVM如果判断老年代没有做足够的连续空间来放置大对象，那么就会引起Full GC，例如老年代可用空间大小为200K，但不是连续的，连续内存只要100K，而晋升到老年代的对象大小为120K，由于120＞100的连续空间，所以就会触发Full GC。

三、常见的分析办法

第一步：使用jstat –gcutil命令关注full gc次数、full gc执行时间以及老年代占比变化情况；发现老年代的占比增加快则说明大对象较多或者年轻代配置过小对象进入老年代快；发现老年代长时间占用高且执行full gc后占比基本无变化或者变化很小，则说明对象一直存在引用未释放。

第二步：查看gc日志，关注full gc触发时老年代中对象回收前和回收后的情况和执行回收消耗时间，还有可以明确是什么原因触发了full gc，如果看到System.gc导致的则说明代码中有调用执行full gc。

第三步：确定堆内存存在问题先使用jmap –histo命令查看当前应用堆内存占用情况，分析那些是应用服务产生的对象且占用内存高，这种对象重点关注和分析。

第四步：需要分析对象调用链路，先执行jmap -dump:live,format=b,file 将堆内存dump下来，然后再用mat工具打开查看。