GC问题排查

堆内存采用分代结构：新生代+老年代
堆的垃圾回收：YGC+FGC

YGC触发条件

对象通常在在年轻代中的Eden区进行分配，如果Eden区域没有足够的空间，那么就会触发YGC（Minor GC），YGC处理的区域只有新生代。每经过一次YGC，存活对象的年龄就会加1。

FGC触发条件

• 当晋升到老年代的对象大于了老年代的剩余空间时，就会触发FGC（Major GC）
• 老年代的内存使用率达到了一定阈值（可通过参数调整），直接触发FGC。
• Metaspace（元空间）在空间不足时会进行扩容，当扩容到了-XX:MetaspaceSize 参数的指定值时，也会触发FGC。
• System.gc() 或者Runtime.gc() 被显式调用时，触发FGC。

GC影响程序

GC会造成一定程度的程序卡顿，因此频繁的GC或者GC时间过长，会影响程序。

• FGC过于频繁：FGC通常是比较慢的，少则几百毫秒，多则几秒，正常情况FGC每隔几个小时甚至几天才执行一次。一旦出现FGC频繁（比如几十分钟就会执行一次），就肯定是存在问题的。

• YGC耗时过长：一般来说，YGC的总耗时在几十或者上百毫秒是比较正常的，但是如果YGC耗时达到了1秒甚至几秒（都快赶上FGC的耗时了），那卡顿时间就会增大，加上YGC本身比较频繁，就会导致比较多的服务超时问题。

• FGC耗时过长：FGC耗时增加，卡顿时间也会随之增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低，这种也需要关注。

• YGC过于频繁：即使YGC不会引起服务超时，但是YGC过于频繁也会降低服务的整体性能，对于高并发服务也是需要关注的。

FGC问题的排查思路

1. 因导致FGC的一些原因？

• 大对象：系统一次性加载了过多数据到内存中（比如SQL查询未做分页），导致大对象进入了老年代。
• 内存泄漏：频繁创建了大量对象，但是无法被回收（比如IO对象使用完后未调用close方法释放资源），先引发FGC，最后导致OOM.
• 程序频繁生成一些长生命周期的对象，当这些对象的存活年龄超过分代年龄时便会进入老年代，最后引发FGC. （即本文中的案例）
• 程序BUG导致动态生成了很多新类，使得 Metaspace 不断被占用，先引发FGC，最后导致OOM.
• 代码中显式调用了gc方法。
• JVM参数设置问题：包括总内存大小、新生代和老年代的大小、Eden区和S区的大小、元空间大小、垃圾回收算法等等。

2. 清楚排查问题时能使用哪些工具

• 公司的监控系统
• JDK的自带工具，包括jmap、jstat等常用命令：

# 查看堆内存各区域的使用率以及GC情况
jstat -gcutil -h20 pid 1000
# 查看堆内存中的存活对象，并按空间排序
jmap -histo pid | head -n20
# dump堆内存文件
jmap -dump:format=b,file=heap pid

• 可视化的堆内存分析工具：JVisualVM、MAT等

3. 排查指南

• 查看监控，以了解出现问题的时间点以及当前FGC的频率（可对比正常情况看频率是否正常）
• 了解该时间点之前有没有程序上线、基础组件升级等情况。
• 了解JVM的参数设置，包括：堆空间各个区域的大小设置，新生代和老年代分别采用了哪些垃圾收集器，然后分析JVM参数设置是否合理。
• 再对步骤1中列出的可能原因做排除法，其中元空间被打满、内存泄漏、代码显式调用gc方法比较容易排查。
• 针对大对象或者长生命周期对象导致的FGC，可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析，需要先定位到可疑对象。
• 通过可疑对象定位到具体代码再次分析，这时候要结合GC原理和JVM参数设置，弄清楚可疑对象是否满足了进入到老年代的条件才能下结论。