【JVM补充】频繁fullgc的解决思路

本文主要是介绍【JVM补充】频繁fullgc的解决思路，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

最近在整理JVM的知识体系，想到了大家平时都会讨论了一个话题，当然也是面试常问的一个话题，就是发生频繁fullGC的情况，我们应该如何应对，如何找到问题并且如何解决问题，这是让人头大的事情。

发现问题

我们先思考一下，我们平时是怎么发现频繁fullgc的，它的表现形式有哪些，这里只列举出来我能想到的几个点，可能还有其他的表现形式。

CPU满载告警
API响应时间过长
内存反复波动
fullgc频繁告警(存在监控的情况下)

其实发生CPU满载或者内存波动的原因可能会有很多，但是当我们发现这些情况，是可以往频繁fullgc上面想的，毕竟线上一旦出现问题，肯定要全面排查的嘛。

常用命令：
jps：查看本机java进程信息
jstack：打印线程的栈信息，制作线程dump文件
jmap：打印内存映射信息，制作堆dump文件
jstat：性能监控工具
jhat：内存分析工具，用于解析堆dump文件并以适合人阅读的方式展示出来
jconsole：简易的JVM可视化工具
jvisualvm：功能更强大的JVM可视化工具

定位问题

当我们发现了以上情况以及其他可以情况，就可以查看一下是否是频繁了fullgc，这里有个前提，就是什么频率算得上是频繁，这个要根据业务量和公司规定来的，比如我们公司，因为我们的项目是对B的，没有这么高的并发量，所以低于两天一次fullgc就属于频繁了，如果一天发生多次fullgc，那就一定出现问题了，就需要排查优化了，所以当我们确定了是频繁fullgc，就要开始定位，究竟是什么原因导致的fullgc。

查看项目启动的GC命令，检查是否有异常指令：
比如有些同事可能对于GC参数理解的不是很透彻，本来想着优化的目的，但是却起了反作用。
查看yonggc的频率：
这一步主要是为了查看是否存在递归或者频繁创建对象，并且频繁回收，导致yonggc频繁，进而导致fullgc频繁，如果ygc频繁，则需要检查代码中是否存在不符合规范的地方了。
查看每一次fullgc的回收率：
如果ygc正常，但是fullgc频繁，那么这一步是为了查看是否存在内存泄漏，定位是否存在对象的长时间引用，内存泄露会占用大量内存空间，且无法正常回收，导致fullgc越发频繁，且stw时间越发长。
查看堆栈情况，找到占用内存较大的对象：
查看当前的堆栈信息，如果有监控工具可以直接使用，没有的话就使用JDK自带的一些命令，找到是否存在大对象的频繁创建。
查看元数据区的回收频率：
Metadata GC Threshold，当我们发现以上情况都不存在，然后dump一下看看是否发生元数据区导致的频繁fullgc，当然这种情况很少见，但是可以定位排除一下。