Memory Leak分析分享

最新推荐文章于 2025-06-19 16:55:18 发布

原创

最新推荐文章于 2025-06-19 16:55:18 发布 · 3.9k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#leak #ibatis #测试 #数据库 #mysql #loadrunner

本文分享了在处理内存泄漏问题时的两个关键点：连接池泄漏和LinkedBlockingQueue问题。通过JProfiler进行分析，发现连接池由于特定的业务场景和数据库查询导致资源未释放。在ibatis的Throttle中，等待状态的线程导致了连接池耗尽的假象。此外，LinkedBlockingQueue的poll方法在高并发场景下可能导致内存泄漏。尽管1.6版本的JDK有所改进，但问题仍然存在，使用take方法可能是个更好的选择。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

问题一：连接池泄漏

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

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

JProfiler截图：

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