2017-02-28

内存泄漏

内存泄漏是一个被谈论了很久的问题，也是在平常开发中经常遇到的问题。很多人都提到过这个问题了，并且被这个问题长期困扰着，对于 C++ 来说，内存泄漏就是new出来的对象没有 delete，俗称野指针；而对于 java 来说，就是 new 出来的 Object 放在 Heap 上无法被GC回收。

一些有助于理解的知识

java的内存分配

静态存储区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量；

栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存；

堆区：通常用来存放new出来的对象。由java垃圾回收期回收。

四种引用类型的介绍

强引用(StrongReference)：JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象；

软引用(SoftReference)：只有在内存空间不足时，才会被回的对象；

弱引用(WeakReference)：在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存；

虚引用(PhantomReference)：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。

内存泄漏至于内存溢出

很明显两者是不同的

内存溢出 Out of Memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

内存泄露 Memory Leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

Memory Leak最终会导致Out of Memory

内存泄漏解析工具

MAT(Memory Analyzer Tool)

下载地址：
http://www.eclipse.org/mat/downloads.php

强大的开源内存检测工具 LeakCanary

leakcanary 是一个开源项目，一个内存泄露自动检测工具，是著名的 GitHub 开源组织 Square 贡献的，它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心，缺点在于还存在一些bug，不过正常使用百分之九十情况是OK的，其核心原理与MAT工具类似。

因为配置十分简单，只需要几句话就好！！！这里就不多说了，大家可以看官方文档：
https://github.com/square/leakcanary

内存泄漏解析

永远的Singleton

单例的使用在我们的程序中随处可见，因为使用它可以完美的解决我们在程序中重复创建对象的问题，不过可别小瞧它。由于单例的静态特性，使得它的生命周期和应用的生命周期会一样长，所以一旦使用有误，小心无限制的持有Activity的引用而导致内存泄漏。比如，下面的例子。

public class SingletonBad {
    private static SingletonBad mSingletonBad;
    private Context context;
    private SingletonBad(Context context) {
        this.context = context;
    }
    
    public static SingletonBad getInstance(Context context) {
        if(mSingletonBad == null) {
            mSingletonBad = new SingletonBad(context);
        }
        return mSingletonBad;
    }
}

这个错误在生活中再普遍不过，很正常的一个单例模式，可就由于传入的是一个 Context，而这个 Context 的生命周期的长短就尤为重要了。如果我们传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出的时候，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。

正确的方式应该是把传入的 Context 换为和应用的生命周期一样长的 Application 的 Context：

public class SingletonBad {
    private static SingletonBad mSingletonBad;
    private Context context;
    private SingletonBad(Context context) {
        this.context = context.getApplicationContext();
    }
    
    public static SingletonBad getInstance(Context context) {
        if(mSingletonBad == null) {
            mSingletonBad = new SingletonBad(context);
        }
        return mSingletonBad;
    }
}

当然，你也可以直接连 Context 都不用传入了。重写 application，提供静态的 getContext 方法：

public class DemoApplication extends Application {
    private static DemoApplication demoApplication;
    
    public static getInstance() {
        return demoApplication;
    }
    
    public static Context getContext() {
        return demoApplication.getApplicationContext();
    }
    
    @Override
    public void onCreate() {
        super.onCreate();
        demoApplication = this;
    }
}

自然就可以直接不用传入Context:

public class SingletonNew {
    private static SingletonNew mSingletonNew;
    private Context context;
    private SingletonBad() {
        this.context = DemoApplication.getContext();
    }
    
    public static SingletonNew getInstance() {
        if(mSingletonBad == null) {
            mSingletonNew = new SingletonNew();
        }
        return mSingletonNew;
    }
}

令人心塞的Handler

这个东西在我最近遇到的最多了，而它也是我们在内存泄漏中最为常见的，也许你的一个小忽略就会导致内存泄漏。在Android的新版本中，我们被要求必须把网络任务等耗时操作置于新线程来处理，我们通常会采用 Handler。

但 Handler 不是万能的，若是我们的编写不规范就有可能会造成内存泄漏。另外，我们知道，Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将会被线程 MessageQueue 一直持有。

由于 Handler 属于 TLS（Thread Local Storage）变量，生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期一致，故很容易导致无法正确释放。比如：

public class HandlerBadActivity extends AppCompatActivity {
    private final Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_bad);
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                //TODO 做点什么
            }
        }, 1000 * 60 * 5);
        this.finish();
    }
}

在例子中，我们申明了一个延迟5分钟执行的消息 Message。当该 Activity 被 finish 的时候，延迟任务的 Message 还存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish 掉的 Activity 就不会回收了，所以造成了内存泄漏（因 handler 为非静态内部类，它会持有外部类的引用，在这里就是当前的 Activity）。

修复：这个解决也是可以通过把其声明为 static 的，则其存活期就跟 activity 的生命周期无关了。不过倘若用到 Context 等外部类的非static 对象，还是应该通过弱引用传入。比如：

public class HandlerGoodActivity extends AppCompatActivity {
    private static final class MyHandler extends Handler {
        private final WeakReference<HandlerGoodActivity> weakActivity;
        private MyHandler(WeakReference<HandlerGoodActivity> weakActivity) {
            this.weakActivity = weakActivity;//使用弱引用
        }
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            HandlerGoodActivity activity = weakActivity.get();
            if (activity != null) {
                //TODO 做些什么
            }
        }
    }
    private final MyHandler handler = new MyHandler(this);
    // 匿名内部类在static的时候绝对不会持有外部类的引用
    private static final Runnable RUNNABLE = new Runnable() {
        @Override
        public void run() {
        }
    };
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_bad);
        handler.postDelayed(RUNNABLE, 1000 * 60 * 5);
    }
}

综述：推荐使用静态内部类+弱引用 WeakReference 这种方式，但要注意每次使用前判空。

说到若引用，这里再提下java的几种引用类型：StrongReference,SoftReference,WeakReference 和 PhatomReference:

种类	级别	回收时机	用途
StrongReference	强引用	不会被回收	JVM停止运行时终止
SoftReference	软引用	联合ReferenceQueue构造有效期短/占内存大/生命周期长的对象的二级告诉缓存器（内存不足时会被清空）	内存不足时终止
WeakReference	弱引用	联合ReferenceQueue构造有效期短/占内存大/生命周期长的对象的一级告诉缓存器（系统发生GC时才清空）	GC运行后终止
PhatomReference	虚引用	联合ReferenceQueue来跟踪对象被垃圾回收器回收的活动	GC运行后终止

在android开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用软引用和弱引用技术。
比如，保存Bitmap的软引用到HashMap。

public class CacheBySoftRef {
    // 首先定义一个HashMap,保存软应用对象
    private HashMap<String, SoftReference<Bitmap>> imageCache =  new HashMap<>();
    // 再来定义一个方法，保存Bitmap的软引用到HashMap
    public void addBitmapToCache(String path){
        // 强引用的Bitmap对象
        Bitmap bitmap = BitmapFactory.decodeFile(path);
        // 软引用的Bitmap对象
        SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
        // 添加该对象到Map使其缓存
        imageCache.put(path,softBitmap);
    }
    // 获取的时候，可以通过SoftReference的get()的方法得到Bitmap对象
    public Bitmap getBitmapByPath(String path){
        // 从缓存中取软引用的Bitmap对象
        SoftReference<Bitmap> softBitmap = imageCache.get(path);
        // 判断是否存在软引用
        if (softBitmap == null){
            return null;
        }
        // 通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，则取得空；
        // 如果未被回收，则可重复使用，提高速度
        Bitmap bitmap = softBitmap.get();
        return bitmap;
    }
}

使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。

如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。

另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。

前面所说的，创建一个静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

匿名内部类/非静态内部类，它们方便却暗藏杀机

Android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的

public class MainActivity extends AppCompatActivity {
    private static TestInnerBad testInnerBad = null;
    class TestInnerBad{
    }
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_inner_bad);
        if (testInnerBad == null){
            testInnerBad = new TestInnerBad();
        }
        Runnable runnable1 = new MyRunnable();
        Runnable runnable2 = new Runnable() {
            @Override
            public void run() {
            }
        };
    }
    private static class MyRunnable implements Runnable{
        @Override
        public void run() {
        }
    }
}

runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。

前辈箴言——善用static成员变量

前面就很明显，当我们的成员变量是static的时候，那么它的生命周期将和整个app的生命周期一致。

这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。

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

远离非静态内部类和匿名类，多用private static class

public class TestActivity extends AppCompatActivity {
    private static TestInnerBad testInnerBad = null;
    
    class TestInnerBad {
        
    }
    
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_bad);
        if(testInnerBad == null) {
            testInnerBad = new TestInnerBad();
        }
    }
}

这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：

功能	Application	Service	Activity
StartActivity	NO1	NO1	YES
Show a Dialog	NO	NO	YES
Layout Inflation	YES	YES	YES
Start a Service	YES	YES	YES
Bind to a Service	YES	YES	YES
Send a Broadcast	YES	YES	YES
Register BroadcastReceiver	YES	YES	YES
Load Resourse Values	YES	YES	YES

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

集合对象善清除，以免内存泄漏触不及防

我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
所以在退出程序之前，将集合里面的东西clear，然后置为null，再退出程序，如下：

private List<String> nameList;
private List<Fragment> list;
@Override
public void onDestroy() {
    super.onDestroy();
    if (nameList != null){
        nameList.clear();
        nameList = null;
    }
    if (list != null){
        list.clear();
        list = null;
    }
}

webView容易导致内存泄漏

当我们不再需要使用webView的时候，应该调用它的destory()方法来销毁它，并释放其占用的内存，否则其占用的内存长期也不能回收，从而造成内存泄漏。

为webView开启另外一个进程，通过AIDL与主线程进行通信，webView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

而另外一些诸如listView的Adapter没有缓存之类的这里就不再多提了。

做一个小的总结

构造Adapter时，没有使用缓存的 convertView
Bitmap对象不在使用时调用recycle()释放内存
Context使用不当造成内存泄露：不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
不要在执行频率很高的方法或者循环中创建对象（比如onmeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。

本文标题:内存泄漏

文章作者:Poplar Hu

发布时间:2017-02-28, 09:48:12

最后更新:2017-03-12, 19:58:31

原始链接:https://atwinner.github.io/2017/02/28/memory-leak/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。