处理过线上问题的同学基本都遇到过系统突然运行缓慢，CPU 100%，以及 Full GC 次数过多的问题。这些问题最终导致的直观现象就是系统运行缓慢，并且有大量的报警。
本期小编集合了HeapDump性能社区内的4篇Full GC异常问题排查文章，通过几位作者记录的真实案例，提醒自己避免踩坑，顺便复习相关知识点。
1.一顿操作后，FGC频率降低到原来的1/400
作者：阿飞Javaer
https://heapdump.cn/article/2...
作者通过一个多月的努力，将 FullGC 从 40 次/天优化到近 10 天才触发一次，而且 YoungGC 的时间也减少了一半以上。第一次优化，作者提升了新生代大小，将初始化堆内存设置为最大内存，运行了5天后，YoungGC减少了一半以上的次数，时间减少了400s，但是FullGC的平均次数增加了41次，没有达到预期效果，于是进行了第二次调优。第二次排查过程中发现了内存泄漏问题，原来是在某个条件下会查询表中所有未处理的指定数据，但是由于查询的时候where条件中少加了模块这个条件，导致查询出的数量达40多万条，解决此问题后，线上服务器运行完全正常了，Full GC频率也大大降低了。
亮点：作者在经历了为时一个多月的调优后，总结出了一些小tips，如发现FullGC频繁的时候优先调查内存泄漏问题，如果访问业务没有这么大量且没有攻击的问题的话可以往数据库方面调查等。十分具有参考价值。
2.FGC实战：如何用Idea揪出开源组件调用System.gc导致频繁FGC
作者：阿飞Javaer
https://heapdump.cn/article/3...
作者收到最近发布的一个服务频繁FGC的告警，首先查看GC日志，推测出是因为某些地方调用System.gc()触发的FGC，很顺利就找到了这个时候是调用了一个导出报表数据到Excel并下载的接口，作者便模拟该段代码重现了问题，然后借助IDEA强大的搜索功能成功定位，发现是在调用WritableWorkbook的close()方法时调用了System.gc()，从而触发了FGC。最后改造代码解决了问题。
亮点：作者碰到问题不轻视不主观臆断，每一步推断都有理有据。先是用最小量的代码完美重现了问题，然后另辟蹊径借助IDEA强大的搜索功能精准定位到了问题所在，改造代码解决了问题，最后还进行了压测，重复调用该段代码重复验证保证再无问题。心思缜密，值得学习。
3.FullGC实战：业务小姐姐查看图片时一直在转圈圈
作者：阿飞Javaer
https://heapdump.cn/article/2...
这是一篇理论与实战结合的好文，不仅分享了UseAdaptiveSizePolicy 参数的相关知识，还提供了清晰的定位思路：
（1）首先确定业务场景，到底业务是做什么的，做了哪些事情，可能拖慢程序的逻辑有哪些
（2）根据猜测可能出现问题的部分进行确认，排除
（3）结合日志信息及相关知识进行问题原因分析确认
（4）模拟复现确认问题出现的根因
（5）解决问题
4.Redis client链接池配置不当引起的频繁full gc
作者：朱纪兵
https://heapdump.cn/article/1...
作者作为项目的ower，非常了解业务特征，在日常查看gc log时发现其不符合业务特征应该呈现的情况，立即使用工具进行排查，然后进行了优化。正因为对业务足够了解，专业知识过硬，所以在日常巡查中就能发现疑点并对其定位，防患于未然，十分值得学习。
