码迷,mamicode.com
首页 > 其他好文 > 详细

单例模式的内存泄漏陷阱

时间:2015-08-28 12:28:58      阅读:216      评论:0      收藏:0      [点我收藏+]

标签:

最近项目开发中使用了一个叫做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;
    }

...
}

 

 

PS:

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

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

 

单例模式的内存泄漏陷阱

标签:

原文地址:http://www.cnblogs.com/soaringEveryday/p/4765962.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!