单例模式的内存泄漏陷阱

(本篇博客举了一个反面的例子，目的在于让新手如何去发现本身的错误)

最近项目开发中使用了一个叫作leakcanary的内存泄漏检查工具，当开发中的调试运行时发生内存泄漏，leakcanary会在notification弹出一个内存泄漏报告，最近发生了个内存泄漏而且leakcanary给出了下列报告：

分析下Leakcanary给出的信息，最后一行它说PopOrderActivity这个实例发生了泄漏，即系统gc的时候没有把这个activity给回收（本该回收的，应该是已经退出这个activity了），倒数第二行即说明了有一个叫作PendingOrderManager的类含有这个activity的引用，查看代码，这个PendingOrderManager是个单例，同时它的构造函数传入了一个Context参数：

public class PendingOrderManager {

    private static PendingOrderManager instance;

    private Context mContext;

    public PendingOrderManager(Context context) {
    
        this.mContext = context;
    }

    public static PendingOrderManager getInstance(Context context) {
        if (instance == null) {
            instance = new PendingOrderManager(context);
        }
        return instance;
    }

...

}

之因此要传入个context是由于这个Manager里面须要建立Preference。

那么如今发生内存泄漏的缘由也就很明了了，因为PendingOrderManager是一个单例模式，那么这个类的生命周期就伴随整个应用的生命周期，而它在被PopOrderActivity建立的时候引用了PopOrderActivity，因此当系统GC的时候试图去回收PopOrderActivity时，发现它却在被另外一个任然在内存里的PendingOrderManager所引用，因此GC回收它失败，从而致使了内存泄漏。

 

那么如何解决这个问题呢？答案很简单，在PendingOrderManager中对context的属性使用弱引用便可：

public class PendingOrderManager {

    private static PendingOrderManager instance;

    private WeakReference<Context> wr;

    public PendingOrderManager(Context context) {
        L.d("PendingOrderManager <constructor>");
        wr = new WeakReference<>(context);
    
    }

    public static PendingOrderManager getInstance(Context context) {
        if (instance == null) {
            instance = new PendingOrderManager(context);
        }
        return instance;
    }

...
}

 

在PendingOrderManager中原来须要使用Context的地方，用wr.get()便可：

String timesListStr = (String) SPUtils.getPendingOrder(wr.get(), KEY_TIMES_LIST, "");
//这里的wr.get()原来是mContext

 

这里须要注意的一点是，因为PendingOrderManager这个时候含有的“context”能够被回收置空了，那么后面使用context的地方要注意判断是否为空，即对wr.get的地方注意检查空状况。

还有一种方式能够解决这个问题，考虑到每一个使用到PendingOrderManager的地方当都会经过这种方式：

(PendingOrderManager.getInstance(mContext).getXXX()

即每次都能传过来一个当前的调用者的context（确定不为空），那么在PendingOrderManager的getInstance方法里面除了断定instance是否为空外，最好在断定下wr.get是否为空，这样子若上一个实例化PendingOrderManager的activity被回收后，能够考虑用新的context来从新建立PendingOrderManager的单例。改造后的getInstance方法:

public class PendingOrderManager {

    private static PendingOrderManager instance;

    private WeakReference<Context> wr;

    public PendingOrderManager(Context context) {
        L.d("PendingOrderManager <constructor>");
        wr = new WeakReference<>(context);
    
    }

    public static PendingOrderManager getInstance(Context context) {
        if (instance == null || wr.get() == null) {
            instance = new PendingOrderManager(context);
        }
        return instance;
    }

...
}

 

关于ApplicationContext

既然这个单例Manager是须要被全局访问的，同时Manager里面又须要context，那么最好的方式就是用一个生命周期是整个app的context来代替。因此这个单例Manager并不须要构造的时候传入一个context，只须要在Manager里面使用context的地方经过getApplicationContext便可。由于application context的生命周期是最长的。

 

PS：

leakcanary是个很好的工具，下列是一些参考资料:

http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/