Android性能优化之MAT内存检测

最新推荐文章于 2026-04-07 09:19:04 发布

原创最新推荐文章于 2026-04-07 09:19:04 发布 · 827 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#内存泄露 #内存 #性能优化 #android

android开发高级专栏收录该内容

14 篇文章

订阅专栏

本文详细介绍了内存泄漏的概念及其分类，分析了内存泄漏产生的原因，并通过MAT工具深入探讨了内存泄漏的诊断方法。

前言

1.什么是内存泄漏?

这个问题说来话太长了，似乎盘古开天劈地以来就有的话题一样，这个问题一直在困扰着程序员,
内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

memory leak会最终会导致out of memory！

内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存泄漏可以分为4类：

常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到 .

2.为什么会发生内存泄漏?

众所周知java不同于c语言的一个显著的区别就是java拥有垃圾回收器机制,程序开发的时候程序员一般不需要考虑对象的释放管理，也就是不会涉及到人工干预回收对象的使用内存，既然如此？那为什么会发生内存泄漏呢?要回答这个问题又要引出另外一个话题，既什么样的对象GC才会回收？当然是GC发现通过任何reference chain(引用链)无法访问某个对象的时候，该对象即被回收。在解释这个问题之前我们需要了解一些GC回收机制中的一些概念，以便更好的对此问题刨析。

(1)GC Root

JAVA虚拟机通过可达性（Reachability)来判断对象是否存活，基本思想：以”GC Roots”的对象作为起始点向下搜索，搜索形成的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（即不可达的），则该对象被判定为可以被回收的对象，反之不能被回收。

GC Roots可以是以下任意对象

一个在current thread(当前线程)的call stack(调用栈)上的对象（例如方法参数和局部变量）
线程自身或者system class loader(系统类加载器)加载的类
native code(本地代码)保留的活动对象

从最强到最弱，不同的引用（可到达性）级别反映了对象的生命周期。强（strong）、软（soft）、弱（weak）、虚（phantom）引用。

Strong references

普通的java引用，我们通常new的对象就是：
Object obj = new Object();
如果一个对象通过一串强引用链可达，那么它就不会被垃圾回收。你肯定不希望自己正在使用的引用被垃圾回收器回收吧。但对于集合中的对象，应在不使用的时候移除掉，否则会占用更多的内存，导致内存泄漏。

Soft reference

当对象是Soft reference可达时，gc会向系统申请更多内存，而不是直接回收它，当内存不足的时候才回收它。因此Soft reference适合用于构建一些缓存系统，比如图片缓存。

WeakReference

WeakReference不会强制对象保存在内存中。它拥有比较短暂的生命周期，允许你使用垃圾回收器的能力去权衡一个对象的可达性。在垃圾回收器扫描它所管辖的内存区域过程中，一旦gc发现对象是weakReference可达，就会把它放到ReferenceQueue中，等下次gc时回收它。
WeakReference weakWidget = new WeakReference(widget);
系统为我们提供了WeakHashMap，和HashMap类似，只是其key使用了weak reference。如果WeakHashMap的某个key被垃圾回收器回收，那么entity也会自动被remove。

由于WeakReference被GC回收的可能性较大，因此，在使用它之前，你需要通过weakObj.get()去判断目的对象引用是否已经被回收.

Reference queque

一旦WeakReference.get()返回null，它指向的对象就会被垃圾回收，那么WeakReference对象就没有用了，意味着你应该进行一些清理。比如在WeakHashMap中要把回收过的key从Map中删除掉，避免无用的的weakReference不断增长。
ReferenceQueue可以让你很容易地跟踪dead references。WeakReference类的构造函数有一个ReferenceQueue参数，当指向的对象被垃圾回收时，会把WeakReference对象放到ReferenceQueue中。这样，遍历ReferenceQueue可以得到所有回收过的WeakReference。

Phantom reference

和soft，weak Reference区别较大，它的get()方法总是返回null。这意味着你只能用PhantomReference本身，而得不到它指向的对象。当WeakReference指向的对象变得弱可达(weakly reachable）时会立即被放到ReferenceQueue中，这在finalization、garbage collection之前发生。理论上，你可以在finalize()方法中使对象“复活”（使一个强引用指向它就行了，gc不会回收它）。但没法复活PhantomReference指向的对象。而PhantomReference是在garbage collection之后被放到ReferenceQueue中的，没法复活。

对象无用了，但仍然可达（未释放），垃圾回收器无法回收。这就是内存泄漏发生的原因。

3.MAT视图分析

tips:MAT需要的是HPROF格式的heap dump二进制文件

这里写图片描述

Shallow Heap

Shallow size就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。在32位系统上，对象头占用8字节，int占用4字节，不管成员变量（对象或数组）是否引用了其他对象（实例）或者赋值为null它始终占用4字节。故此，对于String对象实例来说，它有三个int成员（3*4=12字节）、一个char[]成员（1*4=4字节）以及一个对象头（8字节），总共3*4 +1*4+8=24字节。

class String{
    public final class String {8 Bytes header
    private char value[]; 4 Bytes
    private int offset; 4 Bytes
    private int count; 4 Bytes
    private int hash = 0; 4 Bytes
…}
"Shallow size“ of a String ==24 Bytes

对象头:JVM虚拟机的对象头包括两部分信息：Mark Word（标记字段）和 Klass Pointer（类型指针）
Mark Word 用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。JVM 对象头一般占用两个机器码，在 32-bit JVM 上占用 64bit，在 64-bit JVM 上占用 128bit 即 16 bytes（暂不考虑开启压缩指针的场景）。另外，如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。

Retained Heap

Retained size是该对象自己的shallow size，加上从该对象能直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。为了更好的理解retained size，可看下图。
这里写图片描述
相对于shallow heap，RetainedHeap可以更精确的反映一个对象实际占用的大小（因为如果该对象释放，retained heap都可以被释放）

Retained Set
当X被回收时那些将被GC回收的对象集合。

比如: 一个ArrayList持有100,000个对象，每一个占用16 bytes，移除这些ArrayList可以释放16 x 100,000 + X，X代表ArrayList的shallow大小。相对于shallow heap，RetainedHeap可以更精确的反映一个对象实际占用的大小。
Heap Dump
heap dump是特定时间点，java进程的内存快照。有不同的格式来存储这些数据，总的来说包含了快照被触发时java对象和类在heap中的情况。由于快照只是一瞬间的事情，所以heap dump中无法包含一个对象在何时、何地（哪个方法中）被分配这样的信息。

Dominator Tree视图

Dominator Tree：对象之间dominator关系树。如果从GC Root到达Y的的所有path都经过X，那么我们称X dominates Y，或者X是Y的Dominator Dominator Tree由系统中复杂的对象图计算而来。从MAT的dominator tree中可以看到占用内存最大的对象以及每个对象的dominator。
我们也可以右键选择 Immediate Dominator” 来查看某个对象的dominator。

(个人感觉没有多大的软用)

这里写图片描述

Path to GC Roots视图

查看一个对象到GC Roots的引用链
通常在排查内存泄漏的时候，我们会选择exclude all phantom/weak/soft etc.references,
意思是查看排除虚引用/弱引用/软引用等的引用链，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收，我们要看的就是某个对象否还存在Strong 引用链（在导出HeapDump之前要手动出发GC来保证），如果有，则说明存在内存泄漏，然后再去排查具体引用。
这里写图片描述

查看当前Object所有引用,被引用的对象：

List objects with （以Dominator Tree的方式查看）

incoming references 引用到该对象的对象
outcoming references 被该对象引用的对象

Show objects by class （以class的方式查看）

incoming references 引用到该对象的对象
outcoming references 被该对象引用的对象

如何分析内存泄漏?

tips:切记在导出prof文件前，先手动出发一次GC，这样可以确保只保存那些无法回收的对象内存快照，另外Android Studio提供自动转换。
步骤
(1).查找目标类
如果在开发过程中，你的目标很明确，比如就是查找自己负责的Activity，那么通过包名或者Class筛选，OQL搜索都可以快速定位到
OQL：
点击OQL图标,在窗口输入 select * from instanceof android.app.Activity 并按Ctrl + F5或者!按钮执行
(2).Paths to GC Roots：exclude all phantom/weak/soft etc.references
查看一个对象到RC Roots是否存在引用链。要将虚引用/弱引用/软引用等排除，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收.

(3).分析具体的引用为何没有被释放，并进行修复

help:
通过OQL快速定位未使用的集合
(1). 通过OQL查询empty并且未修改过的集合：

select * from java.util.ArrayList where size=0 and modCount=0 
类似的 
select * from java.util.HashMap where size=0 and modCount=0 
select * from java.util.Hashtable where count=0 and modCount=0

(2)查看使用activity实例

select * from instanceof android.app.Activity
select * from "packageName.main.activity.*"

参考资料:

MAT性能分析

MemoryAnalyzer Wiki