Memory Leak分析分享

       越是忙，杂七杂八的事情越多，最近正在优化Memcache的客户端代码，这时候SIP突然出现OOM的问题（Out of Memory），作开发最头痛就是这种问题，压力测试都作过，早期的几个版本都没有出现这样的问题，因此怀疑可能是最近一次发布修改引起的。借助JProfiler在测试环境搭了一套系统，开始做压力测试，来分析Memory到底流到了哪里去了。

 

问题一：连接池泄漏

       看到这个问题，我想很多人都说，都什么年代了，使用开源的现成连接池，怎么还会有这样的问题，又不是那些使用jdbc的年代了。那来看看现象吧。

 

场景：测试部用loadRunner往死里压，发现很多业务对象不断增长，但是按照业务场景来说，这些业务对象处理以后就自动释放了。（在本地的开发环境验证了是会自动释放的）

 

JProfiler截图：

 

       上图中可以看到有很多业务对象已经累积占用了不少内存，在让测试部同学停掉压力测试以后，等待了一会儿，然后用JProfiler主动发起垃圾回收，也看到了Jboss后台有GC回收的记录输出以后，发现这些对象依然存在，也就是说这些对象成为了Memory泄漏的诱因之一。但是就如我所说的，在本地测试以及白盒测试来看，这些对象在一次请求以后，处理完毕一定会被释放，没有被其他Map等Reference，然后通过JProfiler看了看这些对象的Allocation Call Tree