内存分析工具MAT的使用.docx
《内存分析工具MAT的使用.docx》由会员分享，可在线阅读，更多相关《内存分析工具MAT的使用.docx（15页珍藏版）》请在冰点文库上搜索。
内存分析工具MAT的使用
内存分析工具MAT的使用
一、MAT插件安装
MAT（MemoryAnalyzerTool）是基于heapdumps来进行分析的，它的分析速度比jhat快，分析结果是图形界面显示，比java内置jhat的可读性更高,通过Eclipse市场安装方法/步骤1
打开Eclipse->help ->EclipseMarketplace
2
点击install，等待下面的进度条加载完毕后，勾选全部，点击Next
3
同意协议后，点击Finish就开始安装MAT了
直接输入URL安装方法/步骤2
1. 打开Eclipse->help ->InstallNewSoftware
2. 在workwith输入图中下载地址，勾选Memory AnalyzerforEclipseIDE选项
3. 若没有勾选Memory AnalyzerforEclipseIDE选项，点击地址栏旁边的Add，在location里输入以上地址，点击OK即可。
4. 安装完成后提示重启Eclipse，重启后打开window->openperspective，看到MemoryAnalysis证明安装成功。
二、MAT的使用
案例一
问题
线上某一台机器出现异常.接口调用的rt达到了万级别..基本可以判断这个机器已经挂了.进而分析该机器一直在fgc.然后马上dump内存,进而进行分析（中间一些异常的gc日志没有截图）.之前学习的jvm知识都是纯理论的,这次是实打实线上出现的问题.所以记录一下.
步骤
1、先dump对应的堆,然后从线上发到自己本机
dump的命令是
jmap-dump:
format=b,
2、调整eclipse的内存
具体的数值,需要看dump的文件大小.比如我的dump文件是1.3G,我就给了eclipse2G的内存..据说有些dump文件有几十个G的大小,那么分析的机器也必须比这个大才行,否则eclipse本身就OOM了.
3、分析.
调整到MemoryAnalysis窗口,然后File->OpenHeapDump
然后选择dump的文件,然后MAT就自动会进行分析..分析完了,直接查看 LeakSuspectsReport.MAT会自动帮你找内存泄露的疑凶.然后给你
点下面的Detail.可以看到最直观的类和所占用的大小
可以看到,IosPushClient的直接引用是40byte但是对应的间接引用达到了恐怖的420M那么再点击该类,listobejcts.重点看间接引用占用的大的
可以看到这个LinkedHashMap中,有47528个1776byte的对象。
其实看到这里,就基本清楚了.这个是由于在push的时候把对应的push消息给保留住,然后造成一直堆积在内存中造成的。
解决办法：
在不修改对应的push底层实现的前提下,每次push了2W条消息就清理一次.后续有时间再修改底层逻辑吧.
案例二
1 内存泄漏的排查方法
DalvikDebugMonitorServer（DDMS） 是 ADT插件的一部分，其中有两项功能可用于内存检查 :
·heap 查看堆的分配情况
·allocationtracker跟踪内存分配情况
DDMS 这两项功能有助于找到内存泄漏的操作行为。
EclipseMemoryAnalysisTools（MAT） 是一个分析 Java堆数据的专业工具，用它可以定位内存泄漏的原因。
工具地址 :
1.1 观察 Heap
·运行程序，然后进入 DDMS管理界面，如下：
PS:
点击工具栏上的
来更新统计信息
点击右侧的 CauseGC 按钮或工具栏上的
即可查看当前的堆情况，如下：
主要关注两项数据：
oHeapSize 堆的大小，当资源增加，当前堆的空余空间不够时，系统会增加堆的大小，若超过上限 （例如 64M，视平台和具体机型而定）则会被杀掉
oAllocated 堆中已分配的大小，这是应用程序实际占用的内存大小，资源回收后，此项数据会变小
·查看操作前后的堆数据，看是否有内存泄漏
对单一操作（比如添加页，删除页）进行反复操作，如果堆的大小一直增加，则有内存泄漏的隐患。
1.2利用MAT分析内存堆
DDMS 可以将当前的内存 Dump成一个 hprof格式的文件，MAT 读取这个文件后会给出方便阅读的信息，配合它的查找，对比功能，就可以定位内存泄漏的原因。
·获取 hprof文件
点击工具栏上的
按钮，将内存信息保存成文件。
如果是用 MATEclipse 插件获取的 Dump文件，则不需要经过转换，Adt会自动进行转换然后打开。
·转换 hprof文件
DDMSDump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv （位于 sdk/tools下）
./hprof-convxxx-a.hprofxxx-b.hprof
·用 MAT打开转换后的 hprof文件
1.3 Histogram查询
用的最多的功能是 Histogram,点击 Actions下的 Histogram项将得到 Histogram结果：
它按类名将所有的实例对象列出来，可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :
在某一项上右键打开菜单选择 listobjects->withincomingrefs 将列出该类的实例：
它展示了对象间的引用关系，比如展开后的第一个子项表示这个 HomePage（0x420ca5b0）被HomePageContainer（0x420c9e40）中的 mHomePage属性所引用.
快速找出某个实例没被释放的原因，可以右健 PathtoGCRoots-->exclueallphantom/weak/softetc.reference :
得到的结果是：
从表中可以看出 PreferenceManager->…->HomePage这条线路就引用着这个 HomePage实例。
用这个方法可以快速找到某个对象的 GCRoot,一个存在 GCRoot的对象是不会被 GC回收掉的.
1.4 Histogram对比
为查找内存泄漏，通常需要两个 Dump结果作对比，打开 NavigatorHistory面板，将两个表的 Histogram结果都添加到 CompareBasket中去 :
添加好后，打开 CompareBasket面板，得到结果：
点击右上角的 !
按钮，将得到比对结果：
注意，上面这个对比结果不利于查找差异，可以调整对比选项：
再把对比的结果排序，就可得到直观的对比结果：
也可以对比两个对象集合，方法与此类似，都是将两个 Dump结果中的对象集合添加到CompareBasket中去对比。
找出差异后用 Histogram查询的方法找出 GCRoot，定位到具体的某个对象上。
1.5 例子
举例一个典型的分析内存泄漏的过程：
1.使用 Heap查看当前堆大小为 23.00M
2.添加一个页后堆大小变为 23.40M
3.将添加的一个页删除，堆大小为 23.40M
4.多次操作，结果仍相似，说明添加/删除页存在内存泄漏 （也应注意排除其它因素的影响）
5.Dump 出操作前后的 hprof 文件 （1.hprof,2.hprof），用 mat打开,并得到 histgram结果
6.使用 HomePage字段过滤 histgram结果，并列出该类的对象实例列表，看到两个表中的对象集合大小不同，操作后比操作前多出一个 HomePage，说明确实存在泄漏
7.将两个列表进行对比，找出多出的一个对象，用查找 GCRoot的方法找出是谁串起了这条引用线路，定位结束
PS:
·很多时候堆增大是 Bitmap引起的，Bitmap在 Histogram中的类型是 byte[],对比两个 Histogram中的 byte[] 对象就可以找出哪些 Bitmap有差异
·多使用排序功能，对找出差异很有用
2内存泄漏的原因分析
总结出来只有一条：
存在无效的引用!
良好的模块设计以及合理使用设计模式有助于解决此问题。
3Tips
·使用 android:
largeHeap="true"标记 （APILevel>=11）
在 AndroidManifest.xml中的 Application节点中声明即可分配到更大的堆内存,android:
largeHeap标记在 Android系统应用中也有广泛的应用 ,比如 Launcher,Browser这些内存大户上均有使用.
三、MAT参考文献
·DDMS 官方教程
·MAT 下载
·MAT 使用
升级会员 