16、JVM实战:FullGC相关总结

文章目录

    1. 对象进入老年代的情况
    1. 触发 Full GC 的情况
    1. 频繁 Full GC 的情况
    1. 如何定位及解决频繁 Full GC

1. 对象进入老年代的情况

  • 分配担保规则:新生代GC过后,存活对象太多,Survivor区放不下了,这个时候就需要通过分配担保进入老年代;

  • 达到年龄阈值:对象在新生代熬过了15次(-XX:MaxTenuringThreshold)GC,达到了年龄阈值,会晋升到老年代;(这种对象一般很少,只有在系统中的确需要长期存在的核心组件等,它们一般不能被回收)

  • 动态年龄判断:在新生代Survivor区的对象,如果:年龄1 + 年龄2 + 年龄3 + 年龄N 的对象大小占比大于了Survivor区的50%以上,那年龄N及以上的对象就会晋升到老年代;

  • 大对象直接进入老年代;(-XX:PretenureSizeThreshold)

  • 默认值为0,当不主动设置值时,不管多大的对象都会先在新生代分配内存;

  • 当手动设置了这个值时,如果生成一个大于这个大小的对象(比如一个超大的数组或者其他对象),就会直接在老年代中为这个对象分配内存;

  • G1收集器中有专门的大对象Region,大对象不存在老年代;

上面的几种情况中,分配担保动态年龄判断都是很关键的;通常如果新生代的Survivor区内存设置过小,就可能导致这两种情况频繁发生,然后导致大量对象快速进入老年代,在老年代对象过多的时候,就会触发 Full GC。

2. 触发 Full GC 的情况

  • 老年代占用比例参数(-XX:CMSInitiatingOccupancyFaction 默认92%),老年代使用内存达到这个阈值会触发 Full GC;
  • 执行YGC之前,如果 老年代可用内存大小 < 历次 YGC后升入老年代对象的平均大小,先执行 Full GC;
  • 执行YGC之后,如果 存活对象大小 > 老年代可用内存大小,执行 Full GC;

3. 频繁 Full GC 的情况

  • JVM内存分配不合理,导致存活对象频繁进入老年代,发生Full GC;(可使用jstat 分析)
  • JVM内存分配已经很大,然而系统运行时产生大量对象,并且处理很慢,YGC后存活太多对象进入老年代,发生Full GC(或者超过对象年龄阈值);(使用MAT分析占用大量内存的对象,追踪执行堆栈,优化代码)
  • 系统发生 内存泄漏,大量对象无法回收,老年代中驻留了大量对象,导致一有部分对象进入老年代,就会发生Full GC;(可使用jmap导出内存快照,使用 MAT 分析)(加载了太多静态缓存)
  • 加载类过多,导致元数据空间占用太大,发生Full GC;(可使用 -XX:TraceClassLoading -XX:TraceClassUnloading 进行分析)(反射会导致)
  • 手动频繁执行 System.gc();(可使用 -XX:+DisableExplicitGC 屏蔽显示GC)

4. 如何定位及解决频繁 Full GC

根据频繁Full GC的几种情况,进行一一排查,使用jstat查看JVM运行模型:

  • 如果表现为:每次YGC后,老年代规律性增大,然后几次YGC后就触发FGC:

  • 则可能是:JVM内存分配不合理,查看JVM内存分配,看是否新生代和Survivor区分配太小,导致每次YGC后存活对象Survivor区都放不下,然后进入老年代;

  • 解决方案:合理分配JVM内存模型,扩大新生代和Survivor区大小;

  • 如果表现为:平常时候FGC频率很低,突然在短时间内连续发生FGC:

  • 则可能是:突然系统承受高并发的请求,短时间内创建大量的对象;

  • 解决方案:使用jstat等工具计算出高并发请求下,每秒新生代产生对象的大小,及每次YGC后存活对象大小,合理的对新生代和老年代进行扩容和分配内存模型;

  • 如果查到JVM内存分配已经很大,并且当前系统正常情况下的负载量不会产生这么大对象:(执行时间较长产生的内存泄漏,无法及时回收)

  • 则可能是:代码执行时,存在产生大量对象后,执行耗时时间很长(YGC都会存活)的异常代码;

  • 解决方案:使用jmap导出内存快照,使用 MAT 分析 -> 追踪执行堆栈,定位错误代码;

  • 如果表现为:在系统运行着的时候,每隔一段时间老年代突然增大,然后YGC后偶尔有对象进入老年代触发Full GC:

  • 则可能是:代码执行过程中,每隔一段时间就会产生“大对象”进入老年代;(比如从数据库中不带where条件查出很多对象)(G1收集器大对象不会放在老年代)

  • 解决方案:使用jmap导出内存快照,使用 MAT 分析 -> 找出是什么对象占用内存过大;

  • 如果表现为:老年代内存持续的增大,每次YGC后都有存活对象进入老年代,“且发生FGC后回收掉的对象很少”:(代码本身的内存泄漏,无法回收)

  • 则可能是:发生了内存泄漏,老年代中一直驻留了太多的对象,并且这些对象无法回收;(比如加载了太多静态数据、错误使用JVM静态缓存等)

  • 解决方案:使用jmap导出内存快照,使用 MAT 分析 -> 找出是哪些对象占用内存过大;

  • 如果表现为:老年代内存占用一直都很正常,但是元数据空间呈现规律性的减小增大情况;或者GC日志中显示 [Full GC(Metadata GC Threshold)]:

  • 则可能是:加载类过多,导致元数据空间占用太大,发生Full GC;(错误的使用反射可能会导致)

  • 解决方案:在JVM启动参数中添加:-XX:TraceClassLoading -XX:TraceClassUnloading -> 追踪到是什么类一直在频繁的加载和卸载;

  • 如果以上情况都没有,则可能是在代码中手动执行 System.gc():

  • 解决方案:使用 -XX:+DisableExplicitGC 屏蔽显示GC;