实战Java内存泄漏问题分析 -- hazelcast2.0.3使用时内存泄漏 -- 1

本文详细分析了一起由于使用Hazelcast 2.0.3导致的Java内存泄漏问题。通过JRockit jrcmd命令获取的堆和线程信息,发现HashEntry不断增长但无法被清除。深入研究Hazelcast的源码,特别是`startCleanup`函数,发现可能的原因包括`startCleanup`未被调用或其内部逻辑错误。目前怀疑与`lastCleanup`时间戳更新及`shouldRun`和`cleanupActive`的compareAndSet操作有关,但硬件或操作系统错误也可能导致问题。下篇将继续探讨调用栈以找出问题根源。
摘要由CSDN通过智能技术生成


公司当年有一个自己缓存集群用户session的Java library,是基于hazlcast2.0.3实现的,最近在customer site集群环境中某个blade报了Out of Memory Exception, 其他blades都正常,马上用jrockit jrcmd命令dump了堆和线程进行分析。

printf “##################### heap ##################\n”

su -p occas -c "/opt/jrockit-jdk/bin/jrcmd `ps -ewf | grep weblogic.Name=traffic | grep -v grep | awk '{print $2}'` heap_diagnostics "

printf “#####################threads ##################\n”su -p occas -c "/opt/jrockit-jdk/bin/jrcmd `ps -ewf | grep weblogic.Name=traffic | grep -v grep | awk '{print $2}'` print_threads"


用eclippse memory analyer打开dump回来的heap文件,打开Dominator Tree,发现hazelcast的ConcurrentMapManager吃掉了大部分的系统内存,其持有的CMap包含的java.util.concurrent.ConcurrenthashMap hashentry的数目无比巨大(近80w), 如图

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值