明白原理,轻松解决内存泄漏

发表于 | 分类于 ， | 阅读次数
字数统计 4,724 | 阅读时长 18

相信「内存泄漏」 问题，是一个挺让开发者头疼的事情，笔者在回顾以为代码时，惊讶发现：初学 Android 时，许多不修边幅的代码习惯，导致了许多内存泄漏问题，借此分析其原因，把自己挖过的坑补一下，也希望奔跑在 Android 开发道路上的你能够优雅避免。

什么是内存泄漏

  • 对于 C++ 来说，内存泄漏就是 new 出来的对象没有 delete，俗称野指针；
  • 而对于 java 而言，就是存放在堆上的 Object 无法被 GC 正常回收；

分析之前我们先来看看三个基础知识点。

基础知识

java 的内存分配简述

运行时数据区域内存模型图

  • 方法区（non-heap）：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量；
  • 栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存；
  • 堆区（heap）：通常用来存放 new 出来的对象。由 GC 负责回收。

四种不同类型的引用

GC 过程与对象的引用类型有着很大的联系，下面我们就看看 Java 中（Android 中存在差异）的四种引用：

  • 强引用（Strong Reference）:JVM 宁愿抛出 OOM，也不会让 GC 回收存在强引用的对象。
  • 软引用（Soft Reference） ：只有内存不足时，才会被 GC 回收。
  • 弱引用（weak Reference）：在 GC 时，如果一个对象只存在弱引用，将会被回收
  • 虚引用（Phantom Reference）：任何时候都可以被 GC 回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为 GC 回收 Object 的标志。

与 Android 中的差异：在 2.3 以后版本中，即使内存够用，Android 系统会优先将 SoftReference 的对象提前回收掉, 其他和 Java 中是一样的。
因此谷歌官方建议用 LruCache(least recentlly use 最少最近使用算法)。会将内存控制在一定的大小内, 超出最大值时会自动回收, 这个最大值开发者自己定。

可达性分析算法

内存泄漏是因为内存无法被正常回收引起。为什么无法被回收？我们前面是这么说的——「因为它的强/软引用被长生命周期的对象持有」。可为什么引用被长生命周期的对象持有就不能进行释放呢？这就涉及到了垃圾回收机制。

进行垃圾回收的第一个问题是如何确定哪些对象是可以被回收的垃圾。通常有两种判断方法，一种是引用计数方法，另一种是可达性分析算法。主流的商用程序语言的主流实现中，都是通过可达性分析来判断对象是否存活的。

可达性分析算法的基本思路是这样的：

  • 通过一系列的称为 GC Root 的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为『引用链』（Reference Chain）
  • 当一个对象到 GC Root 没有任何引用链相连时，则证明此对象是不可用的。

问题来了，到底什么是 GC Root 呢？

R 大在知乎中这样答道：所谓“GC roots”，或者说tracing GC的“根集合”，一组必须活跃的==引用==

  • 所有Java线程当前活跃的栈帧里指向GC堆里的对象的引用；换句话说，当前所有正在被调用的方法的引用类型的参数/局部变量/临时值。
  • VM的一些静态数据结构里指向GC堆里的对象的引用，例如说HotSpot VM里的Universe里有很多这样的引用。
  • JNI handles，包括global handles和local handles
  • （看情况）所有当前被加载的Java类
  • （看情况）Java类的运行时常量池里的引用类型常量（String或Class类型）
  • （看情况）String常量池（StringTable）里的引用

关于 GC 回收机制，可以参考下这篇文章

内存泄漏的危害

  • 运行性能的问题: Android在运行的时候，如果内存泄漏将导致其他组件可用的内存变少，一方面会使得GC的频率加剧，在发生GC的时候，所有进程都必须进行等待，GC的频率越多，从而用户越容易感知到卡顿。另一方面，内存变少，将可能使得系统会额外分配给你一些内存，而影响整个系统的运行状况。
  • 运行崩溃问题: 内存泄露是内存溢出(OOM)的重要原因之一，会导致 Crash。如果应用程序在消耗光了所有的可用堆空间，那么再试图在堆上分配新对象时就会引起 OOM(Out Of Memory Error) 异常，此时应用程序就会崩溃退出。

内存泄漏的典型案例

要想避免内存泄漏，首先要知道导致内存泄漏的原因。
内存泄漏本质原因:==长生命周期的对象持有短生命周期对象的强/软引用。导致本应该被回收的短生命周期的对象无法被正常回收==。

这么讲可能比较抽象。举个常见的栗子：单例模式中，我们常常在获取单例对象时需要传一个 Context 。单例对象是一个长生命周期的对象（应用程序结束时才终结），而如果我们传递的是某一个 Activity 作为 context,那么这个 Activity 就会因为引用被持有而无法销毁，从而导致内存泄漏。

下面我们来看看导致内存泄漏的常见例子。

永远的 Singleton

单例的使用在我们的程序中随处可见，因为使用它可以解决我们在程序中重复创建对象的问题。但是由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，一不小心让单例无限制的持有 Activity 的强引用就会导致内存泄漏。

解决

  • 应该把传入的 Context 改为同应用生命周期一样长的 Application 中的 Context。
  • 也可以通过重写 Application，提供 getContext 方法,那样就不需要在获取单例时传入 context。
1
2
3
4
5
6
7
8
9
10
11
12
public class BaseApplication extends Application{
    private static ApplicationContext sContext;
    @Override
    public void onCreate(){
        super.onCreate();
        sContext = getApplicationContext();
    }
    public static Context getApplicationContext(){
        return sContext;
    }
}

Handler 引发的内存泄漏

由于 Handler 通常会被 Message 所持有，而 Message 通常会间接地被主线程持有，如果创建 Handler 的时候，直接通过 new 的方式创建匿名内部类（默认持有 外部类的强引用，new 操作通常是 Activity 或者是 Fragment 内部直接），在界面退出的时候，又没有调用 android.os.Handler#removeCallbacksAndMessages方法，可能就会导致它的生命周期和 Activity 不一致。进而容易导致内存泄漏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class HandlerBadActivity extends AppCompatActivity {
    private final Handler handler = new Handler(){//非静态内部类，持有外部类的强引用
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_bad);
        // 延迟 5min 发送一个消息
        handler.postDelayed(new Runnable() {//内部会将该 Runable 封装为一个 Message 对象，同时将 Message.target 赋值为 handler
            @Override
            public void run() {
                //do something
            }
        }, 1000 * 60 * 5);
        this.finish();
    }
}

上面的代码中发送了一个延时 5 分钟执行的 Message，当该 Activity 退出的时候，延时任务（Message）还在主线程的 MessageQueue 中等待，此时的 Message 持有 Handler 的强引用（创建时通过 Message.target 进行指定），并且由于 Handler 是 HandlerBadActivity 的非静态内部类，所以 Handler 会持有一个指向 HandlerBadActivity 的强引用，同时 Message 被 MessageQueue 所持有，MessageQueue 又被主线程 Looper 持有，主线程 Looper 被主线程的 looper 所持有（引用链为： 主Thread —> Looper—> MessageQueue —> Message —> Handler 实例 —> Activity ） 所以虽然此时 HandlerBadActivity 调用了 finish 也无法进行内存回收，造成内存泄漏。

解决

将 Handler 声明为静态内部类，但是要注意如果用到 Context 等外部类的 非static 对象，还是应该使用 ApplicationContext 或者通过弱引用来持有这些外部对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class HandlerGoodActivity extends AppCompatActivity {
    private static final class MyHandler extends Handler{//声明为静态内部类（避免持有外部类的强引用）
        private final WeakReference<HandlerGoodActivity> mActivity;
        public MyHandler(HandlerGoodActivity activity){
            this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
        }
        @Override
        public void handleMessage(Message msg) {
            HandlerGoodActivity activity = mActivity.get();
            if (activity == null || activity.isFinishing() || activity.isDestroyed()) {//判断 activity 是否为空，以及是否正在被销毁、或者已经被销毁
              removeCallbacksAndMessages(null);
              return;
            }
            // do something
        }
    }
    private final MyHandler myHandler = new MyHandler(this);
}

慎用 static 成员变量

从前面的介绍我们知道，static 修饰的变量位于内存的方法区，其生命周期与 App 的生命周期一致。
这必然会导致一系列问题，如果你的 app 进程设计上是长驻内存的，那即使 app 切到后台，这部分内存也不会被释放。

解决

不要在类初始时初始化静态成员，也就是可以考虑懒加载。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。

当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：

不同 Context 的应用场景

说明：

  • NO1 表示 Application 和 Service 可以启动一个 Activity，不过需要==创建一个新的 task 任务队列==。
  • 对于 Dialog 而言，只有在 Activity 中才能创建

下面举一个隐蔽的栗子

使用系统服务引发的内存泄漏

为了方便我们使用一些常见的系统服务，Activity 做了一些封装。比如说，可以通过 getPackageManager 在 Activtiy 中获取 PackageManagerService，但是，里面实际上调用了 Activity 对应的 ContextImpl 中的 getPackageManager 方法

ContextWrapper#getPackageManager 

1
2
3
4
@Override
public PackageManager getPackageManager() {
    return mBase.getPackageManager();
}

ContextImpl#getPackageManager

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Override
public PackageManager getPackageManager() {
    if (mPackageManager != null) {
        return mPackageManager;
    }
    IPackageManager pm = ActivityThread.getPackageManager();
    if (pm != null) {
        // Doesn't matter if we make more than one instance.
        return (mPackageManager = new ApplicationPackageManager(this, pm));//创建 ApplicationPackageManager
    }
    return null;
}

ApplicationPackageManager#ApplicationPackageManager

1
2
3
4
5
ApplicationPackageManager(ContextImpl context,
                          IPackageManager pm) {
    mContext = context;//保存 ContextImpl 的强引用
    mPM = pm;
}
1
2
3
4
5
6
private UserManagerService(Context context, PackageManagerService pm,
        Object packagesLock, File dataDir) {
    mContext = context;//持有外部 Context 引用
    mPm = pm;
 	//代码省略
}

PackageManagerService#PackageManagerService

1
2
3
4
5
6
7
public class PackageManagerService extends IPackageManager.Stub {
    static UserManagerService sUserManager;//持有 UMS 静态引用
    public PackageManagerService(Context context, Installer installer,
        boolean factoryTest, boolean onlyCore) {
          sUserManager = new UserManagerService(context, this, mPackages);//初始化 UMS
        }
}

笔者遇到的内存泄漏问题是因为在 Activity 中调用了 getPackageManger 方法获取 PMS ，该方法调用的是 ContextImpl，此时如果ContextImpl 中 PackageManager 为 null，就会创建一个 PackageManger（ContextImpl 会将自己传递进去，而 ContextImpl 的 mOuterContext 为 Activity），创建 PackageManager 实际上会创建 PackageManagerService（简称 PMS），而 PMS 的构造方法中会创建一个 UserManger（UserManger 初始化之后会持有 ContextImpl 的强引用）。

只要 PMS 的 class 未被销毁，那么就会一直引用着 UserManger ，进而导致其关联到的资源无法正常释放。

小结

本例的引用链大致如下：

方法区中（1.8 后移到了 元空间）含有已经加载的 PMS class，PMS 静态引用 –> UserManger（mContext） –> ContextImpl（mOuterContext） –> Activity (资源无法被正常回收)

通常这种内存泄漏总是比较隐蔽，不使用检测工具，根本就想不到，原来那一行代码竟然会引发内存泄漏。

解决

将getPackageManager() 改为 getApplication()#getPackageManager() 。这样引用的就是 Application Context，而非 Activity 了。

远离非静态内部类和匿名类，有需要时请使用静态内部类

为什么要怎么做呢?因为使用非静态内部类和匿名类都会默认持有外部类的引用，如果生命周期不一致，就会导致内存泄漏。

看一个例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class NestedClassLeakActivity extends AppCompatActivity {
    
    class InnerClass {//非静态内部类
        
    }
    
    private static InnerClass sInner;//指向非静态内部类的静态引用
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_nested_class);
        if (sInner == null) {
           sInner = new InnerClass();//创建非静态内部类的实例
        }
    }
}

本例中，因为非静态内部类默认会持有外部类的引用，而外部类中又有一个该非静态内部类的静态实例，该静态实例的生命周期和应用的一样长，而静态实例又持有 Activity 的引用，因此导致 Activity 的内存资源不能正常回收。

解决

  1. 将该内部类设为静态内部类
  2. 也可以将该内部类抽取出来封装成一个单例

集合引发的内存泄漏

我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时（通常会调用 remove 方法），并没有把它的引用从集合中清理掉（其中的一种情况就是 remove 方法没有将不再需要的引用赋值为 null），下面以 ArrayList 的 remove 方法为例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public E remove( int index) {
    // 数组越界检查
    RangeCheck(index);
    modCount++;
    // 取出要删除位置的元素，供返回使用
    E oldValue = (E) elementData[index];
   // 计算数组要复制的数量
    int numMoved = size - index - 1;
   // 数组复制，就是将index之后的元素往前移动一个位置
    if (numMoved > 0)
       System. arraycopy(elementData, index+1, elementData, index,
                      numMoved);
   // 将数组最后一个元素置空（因为删除了一个元素，然后index后面的元素都向前移动了，所以最后一个就没用了），好让gc尽快回收
    elementData[--size ] = null; // Let gc do its work
    return oldValue;
}

elementData[--size ] = null; // Let gc do its work 如果替换为 --size，就会导致已经「移除」的对象因为强引用被集合持有，而无法正常被 gc 回收。

WebView 引发的内存泄漏

WebView 解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。

由于占用的都是 Native 堆内存，所以实际占用的内存大小不会显示在常用的 DDMS Heap 工具中（ DMS Heap 工具看到的只是Java虚拟机分配的内存，即使Native堆内存已经占用了几百兆，这里显示的还只是几兆或十几兆）。只有使用 adb shell 中的一些命令比如 dumpsys meminfo 包名，或者在程序中使用 Debug.getNativeHeapSize() 才能看到 Native 堆内存信息。

据说由于 WebView 的一个 BUG，即使它所在的 Activity(或者Service) 结束也就是 onDestroy() 之后，或者直接调用 WebView.destroy()之后，它所占用这些内存也不会被释放。

解决

把使用了 WebView 的 Activity (或者 Service) 放在单独的进程里。

  • 系统在检测到应用占用内存过大有可能被系统干掉
  • 也可以在它所在的 Activity(或者 Service) 结束后，调用 System.exit(0)，主动Kill掉进程。由于系统的内存分配是以进程为准的，进程关闭后，系统会自动回收所有内存。

使用 WebView 的页面（Activity），在生命周期结束页面退出（onDestory）的时候，主动调用WebView.onPause()==以及==WebView.destory()以便让系统释放 WebView 相关资源。

其他常见的引起内存泄漏原因

  • Android 3.0 以下，Bitmap 在不使用的时候没有使用 recycle() 释放内存。
  • 非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
  • 警惕线程未终止造成的内存泄露；譬如在 Activity 中关联了一个生命周期超过 Activity 的 Thread，在退出 Activity 时切记结束线程。
    • 一个典型的例子就是 HandlerThread 的 run 方法。该方法在这里是一个死循环，它不会自己结束，线程的生命周期超过了 Activity 生命周期，我们必须手动在 Activity 的销毁方法中中调用 thread.getLooper().quit() 才不会泄露。
  • 对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
  • 创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
  • 避免代码设计模式的错误造成内存泄露；譬如循环引用，A 持有 B，B 持有 C，C 持有 A，这样的设计谁都得不到释放。

内存泄漏的检测工具

  • LeakCanary 是 Apache 开源的一个自动检测内存泄漏的框架。具体用法可以参考 LeakCanary——如何检测 Activity 是否泄漏
  • 使用 AS Monitor + MAT 自己分析内存泄漏原因。虽然MAT不会准确告诉你你的代码哪泄漏了，但是它会给你发现哪泄露的数据和线索。
  • AS 3.0 中提供了 Profiler 工具，这里简述一下使用流程：手动点击 GC 按钮（图标是一个垃圾桶）—> 选择 Dump 内存（等待20秒左右）—> 下方会弹出分析结果窗口—> 下拉选择 app heap ，下拉选择 Arrange by package—>到包下寻找自己认为可能发生内存泄漏的类，单击选中类 —> 右边弹出 Instance View 窗口，显示该类的所有实例 —> 选中某一个实例 –> 下方会弹出 Reference 窗口（显示该实例的所有引用），然后分析一下到底是谁强引用了该实例，导致内存无法释放。

参考资料与学习资源推荐

如果本文中有不正确的结论、说法，请大家提出和我讨论，共同进步，谢谢！

Show Comments
0%