问题描述
最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。
问题猜测与验证
我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况：
jstat -gcutil 1 1000 #1是进程号
结果如我所料，几乎1秒钟就要做一次FGC，能安安静静的做个正常的consumer才有鬼了。
赶紧留了一台consumer拿来做分析，把别的几台consumer都重启。不管怎样，先恢复消费能力再说！
内存泄露root cause排查
1秒一次FGC，那肯定是发生内存泄露了。
二话不说，把堆dump下来先！
jmap -F -dump:format=b,file=heapDump 1 #1是进程号
生成的heapDump文件有将近2个G的大小，这么大个文件，为了不影响生产环境的机器，还是scp到本地进行分析吧！
jhat了一下，直接卡在那里不动了。没办法，祭出VisualVM来帮忙。导入文件之后，发现有一大堆HashMap的Node在那占着：
然而并不知道这是个啥，点进去看看内容，发现有一大堆node的key类型是X509CertImpl：
这时候我意识到，问题可能出在网络连接上面。但是还是没法定位到具体的代码。
没办法，接着向上找线索。不断地通过OQL查询Referrers:
接着查询：
接着查询：
这时候看到了连接池的踪迹，感觉离真相不远了！
到了这里，我心里大概知道了答案：问题一定出在阿里云OSS身上。再结合这张图：
就可以猜出是因为使用了OSS的客户端，但是没有正确的释放资源，导致client被回收时，它所创建的资源因为还有别的referrer, 却没有被回收。
再去oss github上的sample一看，果然有这么一段：
而这个shutdown方法做的正是释放Idle资源的事儿：
public void shutdown() {
IdleConnectionReaper.removeConnectionManager(this.connectionManager);
this.connectionManager.shutdown();
}
1
2
3
4
问题修复
知道了原因，修复也是很轻松的事儿。 在创建client的缓存里加个removeListener，用来主动调用client.shutdown()， 美滋滋：
---------------------
作者：沈鸿斌
来源：CSDN
原文：https://blog.csdn.net/u012422829/article/details/78154495
版权声明：本文为博主原创文章，转载请附上博文链接！
来源：oschina
链接：https://my.oschina.net/u/2244961/blog/3034612