记一次内存泄露排查

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u013592964/article/details/83617811

1.事发背景

这是一个爬虫项目中遇到的问题,众所周知爬虫必然需要代理,公司内部有获取单个代理ip和port的接口,每次爬取都取请求一个代理是不合理的,所以我自己维护了一个ip池,项目启动时会初始化获取200个IP,如果在爬取中发现代理不好用,便废弃该代理,重新获取。

2.处理过程

有天我上去看该进程的内存情况,发现保存代理信息的类HttpHost的实例超多

2:        607868       19451776  org.apache.http.HttpHost

这里使用

jmap -histo:live 进程号 > txt

jmap工具查看当前存活的实例情况,当时就知道发生内存泄漏了,实例这么多,还是先看下gc情况(虽然也知道是因为对象的引用没法释放造成的,肯定不会发生没有触发gc的,毕竟该实例已经18M多了,eden区才7128byte,肯定触发gc了)

jstat -gc 进程号 打印间隔

发现YGC和FGC都有触发,HttpHost没有被gc掉,肯定是其索引没有释放。

我这个爬虫使用了apache的HttpClient进行请求,里面设置了代理类,一开始想是不是http链接类的链接没有关闭,导致代理一直没有释放,但是发现HttpPost类的实例是一个正常的数值,于是有些困惑了。好吧先把内存数据dump出来吧

jmap -dump:format=b,file=chelib.dump 进程号

使用MAT分析
在这里插入图片描述
这里先解释一下我代理池的做法,用一个List维护所有的HttpPost,如果碰到不好用的host就先获取一个新的host,然后把不好用的list.remove掉,这里不该有这么多实例啊。还是看看删除代码把。
好吧,该死,竟然没有调用list.remove方法把不好用的去掉。

3.总结

虽然犯的错误很傻,但这次线上分析的方法论还是可以记录的。很期待能碰到一些真正的疑难杂症(哈哈,还是线上稳定点好!)

3.1常用分析命令总结

查看堆内存使用情况

jmap -heap 进程号

查看线程相关信息及死锁

jstack -l PID
展开阅读全文

没有更多推荐了,返回首页