`
netment
  • 浏览: 58999 次
文章分类
社区版块
存档分类
最新评论

OnOutOfMemoryError的一些经验

阅读更多
 最近后台服务器周期地出现OnOutOfMemoryError,导致整个系统crash。遇到这样问题很郁闷,这很有可能是因为后台程序的内存泄漏引起的。但是要定位引起内存泄漏的代码比较困难。

     还好后台运行的JVM的版本是1.5的,在抛出OnOutOfMemoryError的时候还告诉你是堆内存。为了解决这个问题,尝试了很多方法,最先是增大堆内存,通过调整JVM的启动参数如添加 -server -Xms1024m -Xmx1024m 将堆内存设置为1G,通过设置-verbosegc 让JVM输出垃圾回收的日志,但好像效果都不大,堆内存还是随着服务运行的时间不断增加,通过ulimit -s 2048改变Linux线程堆栈内存大小效果也不是很明显。

     后来google了一下Java程序的内存分析工具,发现了JMemProfhttp://oss.metaparadigm.com/jmemprof/,用了一下效果不大好,而且好像其堆sun的JVM支持还不怎样:

  • Currently runs really slow in Sun JDK due to inefficiencies in its profiler interface implementation. Please use IBM JDK if you want reasonable performance.
  • Object arrays appear as unknown[] in IBM JDK due to a fault in its JVMPI interface. The class id is not set for object arrays.
  • Many unknown objects appear when using Sun J2SDK. The class ids in the object alloc events don't correspond to a loaded class. I'm not sure yet what these objects are.
  • Still some race conditions during shutdown.

启动JMemProf系统的性能急剧下降。最后干脆将JDK升级到1.6,将堆内存的使用dump出来分析,这个做法比较好,特别是在生产环境下,通过jmap -heap -dump:format=b,file=heap.bin pid将正在运行的JVM的heap内存dump出来,如果堆内存不是很大的话很快就可以做完,如果堆内存比较大的时候则比较郁闷了,要dump很久。将dump出来的heap.bin用jhat来分析,发现效果还不错,它能确定heap快照中某个类的对象实例有多少个,从而能很好地找到出现问题的程序,令外JDK1.6还有一个很有用的参数就是-XX:+HeapDumpOnOutOfMemoryError,它告诉vm在出现堆内存是将堆内存dump出来。这对生产环境中程序调试是很有用的。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics