dump分析帮助

dump分析帮助

ID:40751562

大小:172.92 KB

页数:6页

时间:2019-08-07

dump分析帮助_第1页
dump分析帮助_第2页
dump分析帮助_第3页
dump分析帮助_第4页
dump分析帮助_第5页
资源描述:

《dump分析帮助》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、用IBMHeapAnalyzer和MOD4J分析Java内存泄漏(2009年7月5日)使用的较多的是MemoryDumpDiagnosticforJava(MDD4J)和IBMHeapAnalyzer,这两个工具都能支持几乎所有JDK版本所生成的堆转储文件。先说一下IBMHeapAnalyzer,下载之后首先阅读一下readme,详细写了HeapAnalyzer的使用方法。可以在命令行中输入java–Xmx[heapsize]–jarha26.jar来启动工具并加载heapdump文件。对于比较大的heapdump,将-Xmx设置一个较大的值(

2、大于heapdump的大小),来避免加载过程中的OOM。对于64位机器上产生的超大heapdump,个人机器上分析就不大可能了。打开heapdump文件后,我一般点击“Analysis”里的“TreeView”,以树的形式从根节点展示内存对象分配的信息第一行java.lang.ref.Refenrence这个class及它的76个children占用了67%的已用堆大小(31M/46M),它本身仅占用了76bits。双击java.lang.ref.Refenrence,我们可以看到它所引用的两个子节点。其中一个子节点java.lang.ref.Finalizer后的67%指引我们内存泄漏的问

3、题应该在它的引用上。接下去你可以逐级展开,或者右键点击“Locatealeaksuspect”,让HeapAnalyzer帮你找到泄漏可能发生的地方。泄漏一般发生在那些拥有“超乎寻常多”的引用(子节点)的class上,正是这些创建后没有释放、累积了成千上百的对象,造成了OutOfMemory。右键中的“Gotothelargestdropsubtrees”也是以此为原理而设的,它的解释为:“Searchfortotalsizedrop”willfindasizedropbetweenthetotalsizeofaparentandthebiggesttotalsizeofchildofthe

4、parent.因为出现泄漏的点,每个子节点占用的内存空间不大,但是巨大的数量会导致父节点占用的totalsize很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的,否则也不需要我们来分析了。更多细节的内容,可以看这篇PPTMemoryDumpDiagnosticforJava(MDD4J)则是IBMSupportAssistant(ISA)里的一个工具,可以在ISA里加载。它的使用方法和HeapAnalyzer类似,不过它会自动列出“可疑泄漏点”供分析。所依据的,是“分析算法查找父对象与子对象之间对象大小的显著变化。这些发生显著变化的父对象可能是基于数组的容器对象,它们包含大量不

5、断增大的子对象。”具体的使用方法可以参考《WebSphereApplicationServer中的内存泄漏检测与分析:第2部分:用于泄漏检测与分析的工具和功能》一文中的实际案例。(不过文中的版本应该比较低,现在能下到的2和3版本有些不同,不过不妨碍使用).Heapdump工具的使用很简单,难点在于找到“内存泄漏的真正原因”,一般需要通过多个heapdump文件的对比才能找到。比较分析用于对运行内存泄漏应用程序期间(即可用Java堆内存流失时)获取的两个内存转储进行分析。在运行泄漏应用程序的早期触发的内存转储被称为基线内存转储,发生泄漏的应用程序运行一段时间(以允许泄漏程度加大)后触发的内存转

6、储被称为主内存转储。在发生了内存泄漏的情况下,主内存转储可能包含大量对象,而这些对象占用的Java堆空间量会比基线内存转储大很多。为了获得更好的分析结果,建议使主内存转储的触发点与基线内存转储的触发点在时间上拉开一定距离,从而使总耗用堆大小在两个触发点之间大幅增长。如果发现“主内存转储”中的某个对象数量大大大于“基线内存转储”,那么这个对象一般就是发生泄漏的点。但是要避免在appserver刚启动时就做heapdump,否则会把正常需要分配的对象当作泄漏嫌疑点。比如原先运行3天会发生OOM,那么可以:缩小堆大小,让OOM提早发生;在运行4个小时后每隔4小时手动做一次Heapdump直到OOM

7、发生。这些动作也许不适合在生产环境下进行,可以另建测试环境进行。之前几篇文章中介绍的分析gclog,和本文讲到的分析heapdump,都是脱机分析法。它们的缺陷就是无法找到代码引起的“性能低下”的原因,正如《用HPjtune分析GC日志》里所看到的那样,系统性能很差,但是没有OOM发生,可用堆在每次fullgc后还不断减少的现象不能简单怪罪为内存泄漏,毕竟最后都回收下来了,如果手动做heapdump,可能有问

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。