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

背景

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

发现问题

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

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

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

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

定位问题

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

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

PS： 别忘了，还有一种可能，就是内存分配的太小了，大家往往会想到复杂的情况，也许调一下堆大小，就决解了呢。