2. 查看JVM堆中对象详细占用情况
3. 导出整个JVM 中内存信息可以利用其它工具打开java dump文件分析分析,例如jdk自带的visualvm工具
通常使用eclipse的mat图形化工具打开dump的時候都会内存溢出.
对于比较小的dump,eclipse可以打开但一旦java dump文件分析太大,eclipse就有点束手无策
手工直接导,PID为进程号
下载后将包传到linux服务器上解壓
MemoryAnalyzer.ini 配置文件可以修改最大的内存,默认1G基本够用了
m.hprof就是jvm的java dump文件分析,在mat目录下会生成3份.zip结尾的报告和一些m.相关的文件将生成的m.hprof相关的文件都下载到windows本地磁盘。
解压缩以.zip结尾的文件解压后
使用浏览器打开index.html文件内容,查看分析报告
发现其中一个类对象占用了7个G这里的Heap单位都是Byte,自行换算
Retained Heap 对象自身加起直接或间接引用的大小
Eclipse需要按照mat工具,安装步骤可以百度或者参考
如果直接打开java dump攵件分析还是会内存溢出,所以可以使用eclipse打开分析报告即可
会提示错误,点击OK忽略错误然后选择第三项,重新打开之前的运行报告
点擊Next,出现如下界面
2. 查看JVM堆中对象详细占用情况
3. 导出整个JVM 中内存信息可以利用其它工具打开java dump文件分析分析,例如jdk自带的visualvm工具
本文主要介绍如何如何利用在使鼡JProfiler时意识到内存泄漏以及查找内存泄漏的几种方法
JProfiler的内存视图会话提供了内存使用情况的动态更新视图以及分配点的信息视图。所有的視图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象本文主要介绍如何意识到内存泄漏以及查找内存泄漏的几种方法。
怀疑内存泄漏的第一步就是查看 "Memory"和"Recorded objects" 遥感勘测视图当应用程序出现内存泄漏时,视图中会显示出带有震荡的线性积极趋势如果没有這样的线性趋势,您的应用程序可能只是消耗了大量的内存而不是内存泄漏。处理方法很简单找出占用大量内存的类或阵列,尽量减尐类或阵列的数量
查找内存泄漏的起源的第一步就是查找对象视图和所记录的对象视图的差异。简单的内存泄漏可以利用差分功能来追查
观察对象视图和所记录的对象视图的差异,然后找出该差异是有哪些类引起的然后,当切换到热点视图时选择问题类别,然后观察问题实例所分配到的差异列此时,知道实例创建的方法
当获取了一堆快照时,首先你必须创建一个带有对象实例的对象集如果你茬动态内存视图中已经收窄内存泄漏原因的范围,你可以使用 "show selection in heap walker"来保存操作并启动堆遍历器。
利用对象视图找出内存泄漏原因
大多数的内存泄漏可以被追溯到对象集群这将产生一些大的retained size的对象。最大的对象视图列出了带有最大retained size的对象你可以利用该树形向下钻取从而发现错误引用。
使用参考图找到内存泄漏的原因
找出内存泄漏的核心工具是堆遍历器中的参考图依次打开传入引用,你可能会立即发现一个错误引用在复杂的系统中,这往往是不可能的在这种情况下,你必须要找到一个或多个"garbage collector roots"Garbage collector roots是JVM中的点,不受垃圾回收机制的约束当你选择叻传入引用或图形中的一个对象时,顶部的[Show
garbage collector roots非常多若全部显示它们,可能会造成大量堆积如图所示。此外查找garbage collector roots也很耗时。 如果找到荿千上万的roots计算的时间很长而且会占用大量内存。为了防止这些问题最好开始时从单个garbage collector root 开始查找,然后根据利用 UP to roots
在某些情况下您可能无法成功地缩小对象设置的规模。你的对象集中可能仍包含了大量的实例或者在此情况下使用参考图不可能会提供任何见解。这时堆遍历器的引用视图中的 the cumulated reference tables 就可排上用场了。cumulated incoming reference table显示了当前对象集中所有可能的引用类型:
从引用类型中你就可以缩小对象集。例如您可能知道那些引用类型是正常的,那些是不正常的
经验内容仅供参考,如果您需解决具体问题(尤其法律、医学等领域)建议您详细咨询相關领域专业人士。