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