Android内存泄露

最新推荐文章于 2024-06-04 17:46:05 发布

ZhangJianIsAStark

最新推荐文章于 2024-06-04 17:46:05 发布

阅读量1k

点赞数 3

分类专栏： Android开发

本文链接：https://blog.csdn.net/Gaugamela/article/details/54571482

版权

Android开发专栏收录该内容

98 篇文章 3 订阅

订阅专栏

本篇博客主要是记录一下Android内存泄露相关的问题。
网上有很多介绍内存泄露的文章，自己摘取了一些比较有价值的内容，
同时增加了一些自己的理解。

在分析内存泄露前，我们必须先对内存泄露的定义有所了解。
简单来讲，Android对内存泄露的定义，与Java中的定义基本一致，即：
正常情况下，当一个对象已经不需要再被使用时，它占用的内存就能够被系统回收。
如果一个本该被回收的无用对象，由于被其它有效对象引用，使得对应的内存不能被系统回收，就称之为内存泄漏。

我们知道Android系统为每个应用分配的内存有限，当一个应用中产生的内存泄漏比较多时，
就难免会导致应用所需要的内存超过系统分配的极限，于是就造成应用出现了OOM错误。
因此，每个开发人员有必要对内存泄露的原理、出问题的场景及分析工具有一定的了解。

一、Java内存分配策略
Java 程序运行时的内存分配策略有三种，分别是静态分配、栈式分配和堆式分配。
对应的，三种分配策略使用的内存空间分别是静态存储区、栈区和堆区。
其中：
1、静态存储区：主要存放静态数据和常量。
这部分内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。

2、栈区：当方法被执行时，方法体内的局部变量都在栈上创建，并在方法执行结束时，自动释放其持有的内存。
由于栈内存分配相关的运算，内置于处理器的指令集中，因此执行效率很高，不过其分配的内存容量有限。

3、堆区：主要用于存储动态分配的对象。
这部分内存在不使用时，将会由 Java 的垃圾回收器来负责回收。

举例来说：

public class Example {
    //静态存储区
    static int e1 = 0;

    //堆区
    int e2 = 1;
    Example e3 = new Example();

    void method() {
        //栈区
        int e4 = 2;
        Example e5 = new Example();
    }
}

如上面代码所示，e1作为静态变量，是与Example这个类关联的，将被分配到静态存储区。

e2和e3均是一个具体对象的成员变量，由于对象必须被动态创建出来，因此e2和e3均将被分配到堆区。
即类中定义的非静态成员变量全部存储于堆中，包括基本数据类型、引用和引用指向的对象实体。

对于一个具体的方法来说，如代码中的method，当方法执行时，其内部的临时变量e4、e5均分配在栈区；
当方法执行完毕后，e4和e5的内存均会被自动释放。
这里需要注意的是，e5分配在栈区，但其指向的对象是分配在堆区的。
由此可以看出，局部变量的基本数据类型和引用存储于栈区，引用指向的对象实体存储于堆区。

二、Java内存释放策略
1、原理
Java的内存释放策略是由GC(Garbage Collection)机制决定和执行的，主要针对的是堆区内存。
GC为了能够准确及时地释放对象，必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等。

关于GC释放内存的原理，参考了一些资料，个人觉得一种比较好的理解方式是：
将堆区对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用者指向被引对象。
将每个线程对象作为一个图的起始顶点，从起始顶点可达的对象都是有效对象，不会被GC回收；
如果某个对象从起始顶点出发不可达，那么这个对象就可以被认为是无效的，可以被 GC 回收。

对于程序运行的每一个时刻，都可以用一个有向图表示JVM的内存分配情况。
举例来说，对于下面的代码：

public class Solution {
    public static void main(String[] args) {
        Object o1 = new Object();
        Object o2 = new Test();
        o2 = o1;
        //运行到此处，看一下对应的GC有向图
        .................
    }
}

public class Test {
    private Object o3;
    Test() {
        o3 = new Object();
    }
}

程序运行到注释行时，对应的GC有向图大致如下：

main函数所在进程为有向图的根节点。
当函数运行到注释行时，没有从根节点到Test对象和Obj 3的路径，
因此Test和Obj 3对象均可以被GC回收。
注意对象能否被回收的依据是，是否存在从根节点到该对象的路径，
因此虽然Obj 3被引用了，但依然会被回收。

由上述例子可以看出，Java的GC机制使用有向图的方式进行内存管理，可以消除引用循环的问题。
例如有三个对象相互引用，只要它们对根进程而言是不可达的，那么GC也可以对它们进行回收。
GC的这种内存管理方式的优点是精度很高，但是效率较低。
另外一种常用的内存管理技术是使用计数器，它与有向图相比精度较低(很难处理循环引用的问题)，但执行效率较高。

最后需要提一点的是，对于程序员来说，GC对应的操作基本是透明的。
虽然可以主动调用几个GC相关的函数，例如System.gc()等，但是根据Java语言规范定义，
这些函数并不保证GC线程一定会进行实际的工作。
这是因为不同的JVM可能使用不同的算法管理GC，例如：
有的JVM检测到内存使用量到达门限时，才调度GC线程进行工作；
有的JVM是定时调度GC线程进行工作等。

2、Java内存泄露的例子
结合Java的GC机制，我们知道了，对于Java中分配在堆内存的对象而言：
如果某个对象是可达的，即在有向图中，存在从根节点到这些对象的路径；
同时这个对象是无用的，即程序以后不会再使用这个对象；
那么该对象就被判定为Java中的内存泄漏。

关于Java内存泄露的例子，可以参考下面的代码：

public class Example {
    private static ArrayList<Object> testArray = new ArrayList<>();

    public void test() {
        Object o = new Object();
        testArray.add(o);

        //本意是想主动释放掉内存，但Obj被testArray持有引用
        //因此，对应的堆内存无法释放掉
        o = null;
    }
}

类似上面的例子，如果集合类是全局性的变量，同时没有相应的删除机制，则很可能导致集合所占用的内存只增不减。

三、Android中的内存泄露举例
接下来我们看看Android中一些内存泄露的例子。

1、静态单例对象引入的泄露
静态对象生命周期的长度与整个应用一致，
如果静态对象持有了一个生命周期较短的对象，
例如Activity等，那么就会导致内存泄露。

这种错误经常出现在使用单例对象的场景中，例如：

public class SingleInstance {
    private final static Object LOCK = new Object();

    //单例模式需要静态对象
    private static SingleInstance singleInstance;

    //静态对象持有Context就可能导致内存泄露
    private Context mContext;

    public static SingleInstance getInstance(Context context) {
        synchronized (LOCK) {
            if (singleInstance == null) {
                return new SingleInstance(context);
            }
            return singleInstance;
        }
    }

    private SingleInstance(Context context) {
        mContext = context;
    }
}

如上面的代码所示：
如果获取单例模式时传的是Application的Context，
由于Application的生命周期就是整个应用的生命周期，
即Context与静态对象的生命周期一致，没有任何问题；

如果传入的是 Activity 等的 Context，那么当这个 Context 所对应的 Activity 退出时，
由于该 Context 的引用被静态单例对象所持有，而单例对象将持续到应用结束，
于是即使当前 Activity 退出，它的内存也不会被回收，就造成了内存泄漏。

由此可以看出，在Android中尽量不要让静态对象持有Context。
如果静态对象一定要持有Context，就让它持有Application Context，
即上面代码需要更改为：

public class SingleInstance {
    private final static Object LOCK = new Object();

    //Android Studio的静态代码检查，会提示不要将Context类置于静态引用中，可能会导致内存泄露
    private static SingleInstance singleInstance;

    private Context mContext;

    public static SingleInstance getInstance(Context context) {
        synchronized (LOCK) {
            if (singleInstance == null) {
                return new SingleInstance(context);
            }
            return singleInstance;
        }
    }

    private SingleInstance(Context context) {
        //若实在需要用，就获取Application Context
        mContext = context.getApplicationContext();
    }
}

不过Application Context也不是万能的，有些场景下Application Context是无法使用的，例如创建一个Dialog。
关于Application、Activity和Service三者的Context应用场景，自己也没有总结过，
就截一下参考资料中的图吧，有机会再深入研究一下：

图中，NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。

2、非静态内部类引入的泄露
如下代码所示，在MainActivity的onCreate函数中，创建了一个非静态内部类对象，
该对象被Activity中的一个静态对像引用。

public class MainActivity extends AppCompatActivity {
    private static Resource mResource = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        if (mResource == null) {
            mResource = new Resource();
        }
    }

    private class Resource {
        //........
    }
}

在上述代码对应的场景中，由于非静态内部类默认会持有外部类的引用，
而内部类的一个实例又被一个静态对象持有，于是最终导致外部类Activity被一个静态对象持有。、
正如前文提及的，由于静态对象一直存在，于是Activity退出时，对应的内存也没法被GC机制回收。

这种问题的解决方案就是，将非静态内部类变为静态内部类，或抽取成一个单独的类。

3、自定义Handler引入的泄露
非静态内部类引入内存泄漏的场景中，比较典型的就是自定义Handler引入的内存泄露：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        //这种方式获取Handler，实际上绑定的是sThreadLocal中的Looper
        Handler handler = new MayLeakHandler();

        //延迟处理一个消息
        //这里匿名内部类其实也会持有外部类的引用
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                //.......
            }
        }, 6000);

        //Activity界面关闭，但其内存还是将被Handler对应的静态线程持有
        finish();
    }

    //定义一个非静态内部类
    private class MayLeakHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            //.............
        }
    }
}

上面代码产生内存泄露的原因是：
MayLeakHandler是一个非静态内部类，持有对Activity的引用。
当Activity退出时，MayLeakHandler仍被有效对象引用，
于是Activity对应的内存也无法被释放。

为了比较好的理解这个问题，我们看看Handler涉及到的一些源码。

当创建Handler时，最终调用的源码片段如下：

public Handler(Callback callback, boolean async) {
    ............
    //调用sThreadLocal.get()，即从应用主线程获取Looper
    mLooper = Looper.myLooper();
    ............
    //获取主线程的MessageQueue
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

当Handler发送消息或Runnable对象时，最终将调用到如下源码：

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
    //this指handle，即Msg将持有handler
    msg.target = this;
    ..........
    //Msg被加入到MessageQueue中，被MessageQueue持有
    return queue.enqueueMessage(msg, uptimeMillis);
}

根据上面的源码可以看出，当定义一个非静态内部类Handler时，
该Handler将被应用主线程的MessageQueue持有；
而Handler又持有了Activity的引用，于是即使Activity界面结束，
若Msg被有被处理掉，MessageQueue将一直持有Activity导致内存泄露。

对于上面那种使用Handler的方式，通常的修改方式是：

public class MainActivity extends AppCompatActivity {
    private MayLeakHandler mHandler = new MayLeakHandler(this);

    //Runnable也必须变成静态的，否则也会内存泄漏
    private static Runnable mRunnable = new Runnable() {
        @Override
        public void run() {
            //.......
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mHandler.postDelayed(mRunnable, 6000);

        finish();
    }

    private static class MayLeakHandler extends Handler {
        //如果MayLeakHandler需要访问Activity中的变量，就持有Activity的弱引用
        //这样垃圾回收时，就可以清除Activity的内存
        private WeakReference<Activity> mActivity;

        MayLeakHandler(Activity activity) {
            super();
            mActivity = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            if (mActivity.get() != null) {
                //.............
            }
        }
    }

    @Override
    protected void onDestroy() {
        //最后根据需要需要，在Activity的onDestroy中清除mHandler处理的Message和Runnable
        //也可以调用其它接口单独清理msg或runnable
        //对于这个例子，Runnable是静态的，所以不需要
        //但其它情况msg和runnable可能会持有Activity，所以需要清理
        mHandler.removeCallbacksAndMessages(null);
        super.onDestroy();
    }
}

4、匿名内部类引入的泄露
匿名内部类也会持有外部类的引用，
因此与非静态内部类一样，也有可能导致内存泄露，
上面例子中初始定义的匿名Runnable，就会导致这个问题。

比较一般的场景是，如果匿名内部类被异步线程持有，
当异步线程与外部类的生命周期不一致时，就会导致内存泄露。

举例如下：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                //.........
            }
        };

        //假设workThread是一个长期运行的HandlerThread
        WorkThread workThread = WorkThread.getWorkThread();
        Handler handler = new Handler(workThread.getLooper());
        handler.post(runnable);
    }
}

上面的代码中，定义了一个匿名内部类runnable，该runable对象持有对Activity的引用。
将该runnable对象递交给WorkThread处理时，workThread就会持有该runable对象的引用，进而持有Activity对象。
如果workThread之前在进行某个耗时操作，那么可能Activity结束时，runable对象还未执行完毕，
于是Activity对应的内存没有及时释放，导致内存泄露。

这种类型的问题的解决方法，可能只有将runable写成静态类或单独抽取成一个独立的类。

5、线程相关的内存泄漏
在界面中使用线程对象，稍不注意也会造成内存泄露：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        leakOne();
    }

    private void leakOne() {
        new Thread() {
            @Override
            public void run() {
                while (true) {
                    SystemClock.sleep(1000);
                }
            }
        }.start();
    }
}

很明显，这个问题与匿名内部类引起的内存泄露一样，由于Thread持有对Activity的引用，
同时Thread一直在运行，因此当Activity结束时，对应内存也不会被释放，导致内存泄露的放生。

现在，我们修改一下代码：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        leakTwo();
    }

    private void leakTwo() {
        new LeakThread().start();
    }

    private static class LeakThread extends Thread{
        @Override
        public void run() {
            while (true) {
                SystemClock.sleep(1000);
            }
        }
    }
}

可以看到，现在Thread变成了一个静态内部类，不再持有对Activity的引用，
因此Activity退出后，对应的内存可以被释放掉。

然而，这段代码还是有问题。
Activity每次创建时，均会创建一个新的永不结束的Thread。
JVM会持有每个运行Thread的引用，因此Activity创建出的Thread将不会被释放掉。
于是，不断的关闭打开Activity，将导致JVM持有的Thread越来越多。

因此上述代码需要修改为：

public class MainActivity extends AppCompatActivity {
    private LeakThread mLeakThread;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        leakThree();
    }

    private void leakThree() {
        mLeakThread = new LeakThread();
        mLeakThread.start();
    }

    private static class LeakThread extends Thread{
        private boolean mRunning = false;

        @Override
        public void run() {
            mRunning = true;
            while (mRunning) {
                SystemClock.sleep(1000);
            }
        }

        void close() {
            mRunning = false;
        }
    }

    @Override
    protected void onDestroy() {
        mLeakThread.close();
        super.onDestroy();
    }
}

修改比较简单，就是在Activity结束时，主动停止Thread。

6、资源未关闭造成的内存泄漏
解决最后这一类的内存泄露，主要就是要注意编程细节了。

使用BroadcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源时，
应该在不再使用时，及时关闭或者注销。

四、总结
对Android中的内存泄露就先总结到这里了。
如何避免内存泄露，在上述例子中已经有对应的解决方案了，此处就不做赘述。
总之，代码看到多写的多，自然会养成良好的编程习惯，死记硬背一些规则，效率肯定比较低。

最后提一下检测内存泄露的工具，MAT有很多的资料，此处不做说明了。
有兴趣的话，推荐大家看看LeakCanary，这个开源工具可以极大地节省分析内存泄露的时间。
LeakCanary: 让内存泄露无所遁形
 LeakCanary 中文使用说明
看看中文使用说明和对应demo，基本上就能了解如何使用了。