解决过线上问题的同学根本都遇到过零碎忽然运行迟缓，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时发现其不合乎业务特色应该出现的状况，立刻应用工具进行排查，而后进行了优化。正因为对业务足够理解，专业知识过硬，所以在日常巡逻中就能发现疑点并对其定位，防患于未然，非常值得学习。
浏览更多性能文章，请移步 HeapDump性能社区