内存分析工具MAT的使用Word文档下载推荐.docx
- 文档编号:20045183
- 上传时间:2023-01-16
- 格式:DOCX
- 页数:14
- 大小:1.14MB
内存分析工具MAT的使用Word文档下载推荐.docx
《内存分析工具MAT的使用Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《内存分析工具MAT的使用Word文档下载推荐.docx(14页珍藏版)》请在冰豆网上搜索。
4.
安装完成后提示重启Eclipse,重启后打开window->
openperspective,看到MemoryAnalysis证明安装成功。
二、MAT的使用
案例一
问题
线上某一台机器出现异常.接口调用的rt达到了万级别..基本可以判断这个机器已经挂了.进而分析该机器一直在fgc.然后马上dump内存,进而进行分析(中间一些异常的gc日志没有截图).之前学习的jvm知识都是纯理论的,这次是实打实线上出现的问题.所以记录一下.
步骤
1、先dump对应的堆,然后从线上发到自己本机
dump的命令是
jmap-dump:
format=b,<
pid>
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分析内存堆
可以将当前的内存
Dump成一个
hprof格式的文件,MAT
读取这个文件后会给出方便阅读的信息,配合它的查找,对比功能,就可以定位内存泄漏的原因。
获取
hprof文件
按钮,将内存信息保存成文件。
如果是用
MATEclipse
插件获取的
Dump文件,则不需要经过转换,Adt会自动进行转换然后打开。
转换
DDMSDump
出的文件要经过转换才能被
MAT识别,Android
SDK提供了这个工具
hprof-conv
(位于
sdk/tools下)
./hprof-convxxx-a.hprofxxx-b.hprof
用
MAT打开转换后的
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.将添加的一个页删除,堆大小为
4.多次操作,结果仍相似,说明添加/删除页存在内存泄漏
(也应注意排除其它因素的影响)
5.Dump
出操作前后的
hprof
文件
(1.hprof,2.hprof),用
mat打开,并得到
histgram结果
6.使用
HomePage字段过滤
histgram结果,并列出该类的对象实例列表,看到两个表中的对象集合大小不同,操作后比操作前多出一个
HomePage,说明确实存在泄漏
7.将两个列表进行对比,找出多出的一个对象,用查找
GCRoot的方法找出是谁串起了这条引用线路,定位结束
很多时候堆增大是
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
下载
使用
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 内存 分析 工具 MAT 使用
![提示](https://static.bdocx.com/images/bang_tan.gif)