Eclipse Memory Analyzer 安装使用

我就是我 2022-05-31 12:08 416阅读 0赞

转载地址：

##### [Eclipse Memory Analyzer 使用技巧][Eclipse Memory Analyzer] #####

# [Eclipse Memory Analysis的安装和使用][Eclipse Memory Analysis] #

## 1. 安装 ##

在Eclipse help -> Eclipse Marketplace下搜索Memory:   
![搜索MAT插件][MAT]

按照步骤安装完成重启即可。

安装方式主要有2种：eclipse插件和软件版的。

1、eclipse插件安装很简单，点击help ---install new software------add 然后添加新地址，路径为：http://download.eclipse.org/mat/1.3/update-site/    然后

2、软件版的安装路径为：[http://www.eclipse.org/mat/downloads.php][http_www.eclipse.org_mat_downloads.php] ，下载windows即可。

### 配置环境参数 ###

安装完成之后，为了更有效率的使用 MAT，我们还需要做一些配置工作。因为通常而言，分析一个堆转储文件需要消耗很多的堆空间，为了保证分析的效率和性能，在有条件的情况下，我们会建议分配给 MAT 尽可能多的内存资源。你可以采用如下两种方式来分配内存更多的内存资源给 MAT。

一种是修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g

另一种是编辑文件 MemoryAnalyzer.ini，在里面添加类似信息 -vmargs – Xmx4g。

至此，MAT 就已经成功地安装配置好了，开始进入实战吧。

Eclipse中的运行参数设置

-Dfile.encoding=UTF-8 -Xms20m -Xmx20m ##设置堆大小20m，并将最小和最大值设置相等，避免扩展 -XX:+HeapDumpOnOutOfMemoryError ##dump出当前的内存堆转储快照 -XX:HeapDumpPath=E:\job ##指定路径(转储文件还是挺大的) -XX:SurvivorRatio=8 ## 存活比2:8

*  1
 *  2
 *  3
 *  4
 *  5
 *

编写内存溢出程序如下：

程序1：

\[java\]  [view plain][]  [copy][view plain]

[![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **public** **class** HeapOOM \{  
2.    
3.      **static** **class** oomObject\{\}  
4.      **public** **static** **void** main(String\[\] args)\{  
5.          List<oomObject> list=**new** ArrayList<oomObject>();  
6.          **while**(**true**)  
7.               list.add(**new** oomObject());  
8.      \}  
9.  \}

程序2：

\[java\]  [view plain][]  [copy][view plain]

[![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  清单 1. 内存泄漏的代码段  
2.   **while** (1<2)   
3.   \{        
4.       Person person = **new** Person("name","address",i);   
5.       v.add(person);   
6.       person = **null**;   
7.   \}

### 获得堆转储文件 ###

巧妇难为无米之炊，我们首先需要获得一个堆转储文件。为了方便，本文采用的是 Sun JDK 6。通常来说，只要你设置了如下所示的 JVM 参数：

\-XX:+HeapDumpOnOutOfMemoryError

JVM 就会在发生内存泄露时抓拍下当时的内存状态，也就是我们想要的堆转储文件。

如果你不想等到发生崩溃性的错误时才获得堆转储文件，也可以通过设置如下 JVM 参数来按需获取堆转储文件。

\-XX:+HeapDumpOnCtrlBreak

除此之外，还有很多的工具，例如 [JMap][]，JConsole 都可以帮助我们得到一个堆转储文件。本文实例就是使用 JMap 直接获取了 Eclipse Galileo 进程的堆转储文件。您可以使用如下命令：

JMap -dump:format=b,file=<dumpfile> <pid>

不过，您需要了解到，不同厂家的 JVM 所生成的堆转储文件在数据存储格式以及数据存储内容上有很多区别， MAT 不是一个万能工具，它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式，例如 Sun, HP, SAP 所采用的 HPROF 二进制堆存储文件，以及 IBM 的 PHD 堆存储文件等都能被很好的解析（您需要安装额外的插件，请参考 [相关说明][Link 1]，本文不作详细解释）。

然后为你的eclipse或者TOMCAT加上生产 .hprof文件的配置，

![09321484.png][]

然后就到了参数设置的页面,按照A,B的顺序设置参数:(-XX:+HeapDumpOnOutOfMemoryError)避免写错误可以copy

![09321485.png][]

运行错误的程序代码会看见以下结果:

![09321486.png][]

那么这时候就生成了一个文件java\_pid3708.hprof,这个文件 在你的项目的根目录下

## 生成分析报告 ##

首先，启动前面安装配置好的 Memory Analyzer tool , 然后选择菜单项 File- Open Heap Dump 来加载需要分析的堆转储文件。文件加载完成后，你可以看到如图 4 所示的界面：

##### 图 4. 概览 #####

![图 4. 概览][4.]

通过上面的概览，我们对内存占用情况有了一个总体的了解。先检查一下 MAT 生成的一系列文件。

##### 图 5. 文件列表 #####

![图 5. 文件列表][5.]

可以看到 MAT 工具提供了一个很贴心的功能，将报告的内容压缩打包到一个 zip 文件，并把它存放到原始堆转储文件的存放目录下，这样如果您需要和同事一起分析这个内存问题的话，只需要把这个小小的 zip 包发给他就可以了，不需要把整个堆文件发给他。并且整个报告是一个 HTML 格式的文件，用浏览器就可以轻松打开。

接下来我们就可以来看看生成的报告都包括什么内容，能不能帮我们找到问题所在吧。您可以点击工具栏上的 Leak Suspects 菜单项来生成内存泄露分析报告，也可以直接点击饼图下方的 Reports->Leak Suspects 链接来生成报告。

##### 图 6. 工具栏菜单 #####

![图 6. 工具栏菜单][6.]

[回页首][Link 2]

## 分析三步曲 ##

通常我们都会采用下面的“三步曲”来分析内存泄露问题：

首先，对问题发生时刻的系统内存状态获取一个整体印象。

第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象

接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。

下面将用一个基本的例子来展示如何采用“三步曲”来查看生产的分析报告。

### 查看报告之一：内存消耗的整体状况 ###

##### 图 7. 内存泄露分析报告 #####

![图 7. 内存泄露分析报告][7.]

如图 7 所示，在报告上最醒目的就是一张简洁明了的饼图，从图上我们可以清晰地看到一个可疑对象消耗了系统 99% 的内存。

在图的下方还有对这个可疑对象的进一步描述。我们可以看到内存是由 java.util.Vector 的实例消耗的，com.ibm.oti.vm.BootstrapClassLoader 负责这个对象的加载。这段描述非常短，但我相信您已经可以从中找到很多线索了，比如是哪个类占用了绝大多数的内存，它属于哪个组件等等。

接下来，我们应该进一步去分析问题，为什么一个 Vector 会占据了系统 99% 的内存，谁阻止了垃圾回收机制对它的回收。

### 查看报告之二：分析问题的所在 ###

首先我们简单回顾下 JAVA 的内存回收机制，内存空间中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的，它的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。

在垃圾回收机制中有一组元素被称为根元素集合，它们是一组被虚拟机直接引用的对象，比如，正在运行的线程对象，系统调用栈里面的对象以及被 system class loader 所加载的那些对象。堆空间中的每个对象都是由一个根元素为起点被层层调用的。因此，一个对象还被某一个存活的根元素所引用，就会被认为是存活对象，不能被回收，进行内存释放。因此，我们可以通过分析一个对象到根元素的引用路径来分析为什么该对象不能被顺利回收。如果说一个对象已经不被任何程序逻辑所需要但是还存在被根元素引用的情况，我们可以说这里存在内存泄露。

现在，让我们开始真正的寻找内存泄露之旅，点击“Details ”链接，可以看到如图 8 所示对可疑对象 1 的详细分析报告。

##### 图 8. 可疑对象 1 的详细分析报告 #####

![图 8. 可疑对象 1 的详细分析报告][8. _ 1]

1.  我们查看下从 GC 根元素到内存消耗聚集点的最短路径：

##### 图 9. 从根元素到内存消耗聚集点的最短路径 #####

![图 9. 从根元素到内存消耗聚集点的最短路径][9.]

我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的集合，如果你对代码比较熟悉的话，相信这些信息应该能给你提供一些找到内存泄露的思路了。

接下来，我们再继续看看，这个对象集合里到底存放了什么，为什么会消耗掉如此多的内存。

##### 图 10. 内存消耗聚集对象信息 #####

![图 10. 内存消耗聚集对象信息][10.]

在这张图上，我们可以清楚的看到，这个对象集合中保存了大量 Person 对象的引用，就是它导致的内存泄露。

[Eclipse Memory Analyzer]: http://blog.csdn.net/albertfly/article/details/51446943
[Eclipse Memory Analysis]: http://blog.csdn.net/wizard_rp/article/details/73266194
[MAT]: /images/20220531/93aff1baf8b74ebeb4a17632af0675d3.png
[http_www.eclipse.org_mat_downloads.php]: http://www.eclipse.org/mat/downloads.php
[view plain]: http://blog.csdn.net/songjinbin/article/details/41528489?utm_source=tuicool&utm_medium=referral#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/534224
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/534224/fork
[JMap]: http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html
[Link 1]: http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html
[09321484.png]: http://www.myexception.cn/img/2012/07/04/09321484.png
[09321485.png]: http://www.myexception.cn/img/2012/07/04/09321485.png
[09321486.png]: http://www.myexception.cn/img/2012/07/04/09321486.png
[4.]: /images/20220531/6c621fc2c0b745a8983cd21102b43005.png
[5.]: /images/20220531/5b6b1081bf9b4601ab11b6bf5a422508.png
[6.]: /images/20220531/4b94d1ba8ec1462bbb19592caade3989.png
[Link 2]: http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html#ibm-pcon
[7.]: /images/20220531/b39536892c7c48baa09db12f5ebf1dcb.png
[8. _ 1]: /images/20220531/3c45010f524146fca77655d90f41cc87.png
[9.]: /images/20220531/67702ee914e240a38b0a82b0e81700fd.png
[10.]: /images/20220531/9aa924409ffd429db3b6318cc0eb04d2.png