用MAT分析OOM 

2017/03/01 19:50
阅读数 292

用MAT分析OOM 
很多OOM看似发生在bitmap 分配得时候,但它一般不是rootcause。根本原因都在于本应该自动释放的资源,因为代码的错误,而导致某些对象一直被引用(Reference),例如 Android 内存优化,如何避免OOM 文章中提到的Activity 的mContext 引用。 

当代码量很庞大的时候,单靠读代码查找错误是很困难的,所以必须借助于工具,这里介绍一款很好用的分析工具MAT。 

1、下载MAT 

http://www.eclipse.org/mat/downloads.php 

一般我们的开发环境都选择了Eclipse,所以直接安装插件版的就可以了。 

2、使用方法,可以看这篇博文: 

http://www.cnblogs.com/Android-and-android/archive/2013/03/05/2943863.html 

3、重点理解 Retained Heap、GC Root 

http://blog.csdn.net/hhww0101/article/details/8133219 

4、如何定位 

首 先要知道复现OOM的操作步骤,如果是随机测试出的,也需要找到一个有效的复现步骤才行。然后分别取操作前的 .hprof,和操作后,内存增长后的 .hprof。如果内存不断增长,可取3,4次。然后分别打开 直方图(Histogram)视图,在对象列表中,对比每个对象的 Retained size的变化。 

排在第一位的不一定是泄露对象,有可能它本身正常情况就很消耗内存。 

泄露的对象是那个突然排名上升的。区分方法是看每个对象的内存地址,地址相同的是同一对象(前提是进程一直运行,没有重启过,重启后内存地址就都变了)。 

出 现怀疑对象后,右键 List Objects > with incoming references,可以排除WeakReference 等引用,顺着树节点向下找,如果出现程序中的 Activity,或者某个全局对象,基本就可以确定是它没释放造成的。要更深一步分析为什么没释放,如果逻辑复杂,难于捋清,可以直接做 workaround,想办法释放这个对象就可以了 (set object = null)。 

java静态代码分析工具 
写代码过程中难免会有疏漏,我们也可以借助工具分析,这里是常用的java静态代码分析工具: 

http://www.oschina.net/question/129540_23043 

个人觉得Find Bugs 和 PMD就可以了,只是辅助,不必过分依赖,他并不是万能的,不是所有错误都能找出来。 

欢迎转载:http://www.yinqisen.cn/blog-315.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部