大家好，分享一个线上GC案例，相信会对大家有所帮助。
本人曾任职于阿里，每日优鲜等互联网公司，任技术总监。
在分享案例前，先聊聊哪些场景会导致频繁full gc：
? ? 1，内存泄漏（代码有问题，对象引用没及时释放，导致对象不能及时回收）
????2，死循环
????3，大对象
????尤其是大对象，80%以上的情况就是他。
那么大对象从哪里来的呢？
1，数据库（包括mongodb等nosql数据库），结果集太大
2，第三方接口传输的大对象
3，消息队列，消息太大
根据多年一线互联网经验，绝大部分情况是数据库大结果集导致。
好，现在我们开始介绍这次线上故障：
在没有任何发布的情况下，pop服务突然开始疯狂full gc，观察堆内存监控没内存泄漏，回滚到前一版本，问题仍然存在。
按照常规做法，一般先用jmap导出堆内存快照（jmap -dump:format=b,file=文件名 [pid]），然后用mat等工具分析出什么对象占用了大量空间，再查看相关引用找到问题代码。这种方式定位问题周期会比较长，如果是关键服务，长时间不能定位解决问题，影响太大。
下面来看看我们的做法，我先安排一个架构师按照常规做法分析堆内存快照。与此同时另外的同学去查看数据库网络IO监控，如果网络IO有明显上升，并且时间点吻合，基本可以确定是大结果集导致了full gc，赶紧找DBA快速定位大SQL（对DBA来说很简单，分分钟搞定，如果DBA不知道怎么定位，那他要被开除了，哈哈），定位到sql后再定位代码就非常简单了。原来是一个接口有个必传的参数没传，也没加校验，导致sql语句where后面少了一个条件，一次查几万条记录出来，真坑??！
这种方法是不是要快很多，哈哈，5分钟搞定。
欢迎关注个人微信公众号：架构师进阶之路
作者简介：15年电商研发经历，曾任职于阿里巴巴，楚楚街，每日优鲜等公司，任技术总监。个人微信公众号：架构师进阶之路
