共计 1468 个字符，预计需要花费 4 分钟才能阅读完成。
解决过线上问题的同学根本都遇到过零碎忽然运行迟缓，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 性能社区