アウトライン
大規模なアプリケーションでは、JAVAは、その後、細かいテストは、我々は多くの問題がまだ本番環境にさらされることになる、テスト段階で実り多くの作業を行っている場合でも、任意の抜け穴を閉じるために困難であり、そしてそれは、テスト環境では困難です再現します。JVMは、次の問題が発生した場合に、システムの動作状態の記録部分にできており、ダンプヒープ（ヒープ・ダンプ）ファイルに格納し、これが私たちの問題を分析し、診断するための重要な基礎を提供します。
メモリー・リーク分析は、一般的に、通常は経験豊富な専門家のチームによって行われ、非常に困難な仕事であると考えられています。今日では、しかし、MATは（Eclipseのメモリアナライザは）私たちは「だます」ヒープダンプ解析ツールであると考えられて紹介したいと思います、あなただけのプロの分析を生成することができ、マウスのクリックする必要があります。そして、他のメモリリーク解析ツールに比べて、非常に簡単なキーの場所を達成することができ、使用のMATに、初心者でもすぐに使い始めることができます。
MATは、その者は、インストールMATの最初のステップを見てみましょう、あなたが個人的にそれを感じることは非常に興味を持っていないので、使いやすいです。
環境とテストデータを準備します
私たちは、EclipseのメモリアナライザV0.8、SunのJDKを使用している6
インストールMAT
そして、他のプラグインをインストールし、ユーザーが実行しているスタンドアロンのEclipse RCPアプリケーションとしてのEclipse IDE環境、MATをインストールしないことを意味MATがサポートする「スタンドアロン」のための2つのインストール方法は、非常によく似ている。他には、「統合です版」、MATは、Eclipse IDEの一部、および既存の開発プラットフォームの統合として使用できることを意味します。
インストールの統合されたバージョンは、Update Managerを必要とします。
図1、ヘルプ〜第に示すように - >ソフトウェア更新...スタートウィザードソフトウェア更新管理。
図ステップ1のプラグ
更新アドレス選択MAT「使用可能なソフトウェア」を追加して、図に示す実施形態を押してください。2 http://download.eclipse.org/technology/mat/0.8/update-site/。
図2.プラグインをインストールするための第2のステップ
メモリアナライザー（チャート）この関数は、主に、関連するレポートを生成するために使用されるオプションのインストールプロジェクト、ですが、必要に応じていることをあなたはMATポイントをインストールしたい機能を選択し、その後、図3に示すように、ノートこの機能を使用するには、追加のBIRTのチャートエンジンをインストールする必要があります。
ステップ3.プラグ図。
プラグインのインストールは、Eclipseワークベンチを再起動する必要があります。
比較すると、インストールのスタンドアロンバージョンは、ユーザーが唯一の適切なインストールパッケージをダウンロードする必要があり、その後、広くオプションを実装する際に使用されている実行に解凍し、非常に簡単です。以下の例では、我々はまた、スタンドアローンMATの使用を。：ダウンロードアドレスの特定の要件とその製品は、ダウンロードページで見つけることができhttp://www.eclipse.org/mat/downloads.php。
また、あなたが見る、生成されたダンプファイルを分析するだけでなく、IBM診断ツールFrameworkをインストールする必要があり、ダウンロードおよび特定の設定手順をインストールするには、IBM JVM MATを使用する必要がある場合します。http：//www.ibm.com/developerworks/java/ JDK /ツール/ dtfj.html
環境パラメータを設定します
インストールが完了したら、MATをより効率的に使用するために、我々はいくつかの設定作業を行う必要があります。一般的なので、ヒープダンプ解析が条件の場合には、効率性とパフォーマンス分析を確保するために、我々は多くのメモリリソースのMATとして割り当てることをお勧めします、スタック領域の多くを必要とします。あなたは、次の2つの方法でMATに多くのメモリリソースを割り当てることができます。
一つは、起動時のパラメータMemoryAnalyzer.exe -vmargs -Xmx4gを変更することです
他のファイルMemoryAnalyzer.iniを編集することで、-vmargsは、それに類似した情報を追加 - Xmx4gを。
これまでのところ、MATが正常にインストールされ、構成されている、それが戦闘に入るようになりました。
ヒープダンプファイルを取得
ヒープダンプファイルを取得するために、私たち最初の必要性、わらせずにレンガを作ります。便宜上、我々は、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 堆存储文件等都能被很好的解析（您需要安装额外的插件，请参考 相关说明，本文不作详细解释）。
万事俱备，接下来，我们就可以开始体验一键式的堆存储分析功能了。
生成分析报告
首先，启动前面安装配置好的 Memory Analyzer tool , 然后选择菜单项 File- Open Heap Dump 来加载需要分析的堆转储文件。文件加载完成后，你可以看到如图 4 所示的界面：
图 4. 概览
通过上面的概览，我们对内存占用情况有了一个总体的了解。先检查一下 MAT 生成的一系列文件。
图 5. 文件列表
可以看到 MAT 工具提供了一个很贴心的功能，将报告的内容压缩打包到一个 zip 文件，并把它存放到原始堆转储文件的存放目录下，这样如果您需要和同事一起分析这个内存问题的话，只需要把这个小小的 zip 包发给他就可以了，不需要把整个堆文件发给他。并且整个报告是一个 HTML 格式的文件，用浏览器就可以轻松打开。
接下来我们就可以来看看生成的报告都包括什么内容，能不能帮我们找到问题所在吧。您可以点击工具栏上的 Leak Suspects 菜单项来生成内存泄露分析报告，也可以直接点击饼图下方的 Reports->Leak Suspects 链接来生成报告。
图 6. 工具栏菜单
分析三步曲
通常我们都会采用下面的“三步曲”来分析内存泄露问题：
首先，对问题发生时刻的系统内存状态获取一个整体印象。
第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象
接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。
下面将用一个基本的例子来展示如何采用“三步曲”来查看生产的分析报告。
查看报告之一：内存消耗的整体状况
图 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 的详细分析报告
- 我们查看下从 GC 根元素到内存消耗聚集点的最短路径：
图 9. 从根元素到内存消耗聚集点的最短路径
我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的集合，如果你对代码比较熟悉的话，相信这些信息应该能给你提供一些找到内存泄露的思路了。
接下来，我们再继续看看，这个对象集合里到底存放了什么，为什么会消耗掉如此多的内存。
图 10. 内存消耗聚集对象信息
在这张图上，我们可以清楚的看到，这个对象集合中保存了大量 Person 对象的引用，就是它导致的内存泄露。
至此，我们已经拥有了足够的信息去寻找泄露点，回到代码，我们发现，是下面的代码导致了内存泄露 :
清单 1. 内存泄漏的代码段
| 1 2 3 4 5 6 7 |
|
总结
上記の例から、我々は、ヒープダンプ解析にMATで見ることができ、メモリリークの外観は、特に初心者のために、これは良い二次解析ツールで、非常に簡単です。しかし、MATはただ、そのようなOQL（オブジェクトクエリ言語）で、ヒープ・ダンプ内のオブジェクトのMATサポートクエリーなどの多くの高度な機能を提供し、メモリ解析ツール「だます」、スレッドと関連する他の分析をサポートしていませ間違いですこれらの機能は、MATのヘルプドキュメントを参照してくださいすることができます。
