真实项目中，由于内存泄漏(OOM)，导致1W多次full gc，最终项目宕机

一、背景

由于要做http全链路调用追踪，我们团队修改了httpclient底层代码，加了http调用日志，并且和我们配置中心打通，可以通过配置中心动态的控制日志输出，正是由于加了这个动态开关，导致的内存泄漏。
下面我们看下具体的排查过程：

二、正文

1、首先看下dump文件，我是用的JProfiler打开dump文件。

这是按照“保留大小”降序排序的。
“保留大小”不明白的，可以看下这篇文章：https://www.jianshu.com/p/aaddf00a1d83
我们可以看到，第三个RedirectExec这个类，实例数有100多万个，保留大小由5个G，基本可以确定问题就出在这里了。
2、然后我们选定第三条，右键选择“使用选定对象”，如下图：

“引用”这选择“传入引用（incoming references）”。
解释下：incoming references和outgoing references
outgoing references ：这个对象引用了哪些对象
incoming references ：哪些对象引用了这个对象

如上图所示：可以看到configChangeListener这个类引起的oom，这个类的作用是我们自己的配置中心的监听器，监听zk节点变化，动态更新配置文件用的类。

问题分析：
由于修改了httpClient底层的代码，在RedirectExec这个类的构造函数中，引入了监听器。feigen和单实例的httpClient这两种情况，这个监听器只会初始化一次。但要是每次http请求都new httpClient，这种多实例的就会发生问题，会new很多监听器，这个httpclient就由于有监听器这个引用，所以就不会被GC回收，最后就会进入老年代，不断进行full gc，full gc会导致程序变慢，并且这些监听器不会被释放，就会一直在内存中，最后把内存打满，发生oom。

三、总结

写代码的时候，要认真考虑和测试各种情况，上面就是没有考虑到多实例的httpclient这种情况，导致发生oom。平常要多去思考，谨慎对待每一次的版本发布。