记录一次老年代内存激增，导致full gc,系统停顿。第三方HTTP服务访问 Read Time out的排除记录

事情的经过是这样子：

       中午12点正打算休息，其他组的开发人员反馈调用我们的系统异常问我们是不是中午升级了（还算留点情面）。我说没有啊，然后紧接着钉钉消息开始告警了。线下运营也开始打电话说系统特别卡，查询特别慢。也等不了定位问题了。先联系运维赶紧把服务逐一重启一下。重启完没到3分钟，又开始卡了。我开始慌了，脑子快速运转最近也没有重大上线啊。我赶紧打开elk日志，查下错误日志。果然有调用其他业务线的服务异常了都是Read time out。最起码问题已经定位了。然后联系这个业务线的负责人一起排查啊。不知道到大家有没有这个感觉，发现问题不是自己的，心情就没有那么紧张，思路也就活泛了。

       1.先看一下jvm监控

    

 

 

上面的两张图也就说明事情了，在11:30之后jvm fullGC 次数明显激增，jvm老年代的也是激增状态。fullGC一次都会给系统带来卡顿。

2.查看dump文件

   运维人员也是专业，没等我们要，早已经将dump文件放到ftp上了等我们自己取了。Eclipse Memory Analyzer 赶紧的。如果打开文件提示 java heap size。那就先修改一下MemoryAnalyzer.ini 文件，我这里设置了-Xmx4096m。

3.分析dump文件

    1.根据Leak Suspects快速查看泄露的可疑点

 

查看一下详情

 

120w条记录。和同事沟通了一条记录差不多500 bytes。然后下面看一下是那条sql执行的吧

 

4.定位出问题的sql

 

 

问题定位到了。赶紧人员先下架这个功能。