memory泄露分析方法(java篇)

#memory泄露主要分为java和native 2种，本文主要介绍java#

测试每天从monkey中筛选出内存超标的app，提单流转到我，

拿到bug不要慌！

首先，辨别内存泄露类型（java，还是native）

• 从采到的dumpsys_meminfo_pid看java heap，native heap大小分布，可判断出是java/native泄露

• 如果是java泄露，会抓到hprof文件（am dumpheap pid/pname data/local/tmp/test.hprof）

其次，分析Hprof

• 明显的activity/fragment leak（最简单）：as打开hprof告诉大家哪些activity/fragment对象泄露了，直接点击对象查看右侧引用即可 （注意：一个activity引用有对条连接到rootcause，但大概率是一个rootcause，不过请看全，每个引用链都可能存在泄露（掉了多次坑）

• 不明显的leak（一般难度）：

1. 按ShallowSize排序（从大到小），筛选出Allocation/NativeSize 数量不合理的对象去排查常泄露的对象有：ServiceConnection，ViewHolder，Bitmap，Dialog，Service，View，Hashmap，Stub（注意：一些特殊的对象本身就是GCRoot：Stub。Hprof的Native内存占用大，主要是Bitmap对象native内存占用大，再从Bitmap引用链可以反向推导出持有它的对象）

• 非常不明显的leak（高难度）：

1. 借助Mat->LeakSuspects 分析出内存大致分布，找到内存占用最大的对象
2. 对照泄露前后2份hprof，找出对象数量和JavaHeap增长最大的对象，再从对象中看下是否有重复的对象泄露了，比如（hashmap持有了大量重复的String，或者持有了大量的viewholder，但已经没有用了，只是没有销毁而已（2份hprof抓取时机通常在超过阈值，或每个半小时抓取1次）
3. 对于可复现的内存增长，如果对比2个hprof找不到明显异常，可使用andriodstudio 抓取更准确内存增长前后的2份hprof文件
4. 如找不到，不要慌！从日志分析，看这个进程在泄露这段时间内有没有报异常log，或在做哪些事情。没有发现时，尝试复现，因为据经验，如果找到必现路径，100%可找到原因，我们要胸有成竹

（Mat工具分析hprof时要转换一下才生效：

转换方法：将.hprof文件拷贝到PC上的/ANDROID_SDK/tools目录下，并输入命令hprof-conv xxx.hprof yyy.hprof，其中xxx.hprof为原始文件，yyy.hprof为转换过后的文件）

接下来下一篇文章会分析常见的泄露Case（项目中遇到过的真实案例），敬请阅读

常见的泄露Case-CSDN博客