上一节我们介绍了关于匿名内部类的内存泄漏,这一节我们来看一下单例产生内存泄漏的情况
知识点
单例的生命周期和应用(Application)的生命周期一样长
案例
我们先来看一段代码
public class GlobalManager {
private volatile static GlobalManager instance;
private Context mContext;
private GlobalManager(Context context) {
this.mContext = context;
}
public static GlobalManager getInstance(Context context) {
if (instance == null) {
synchronized (GlobalManager.class) {
if (instance == null) {
instance = new GlobalManager(context);
}
}
}
return instance;
}
}
这段代码中,单例的生命周期和Application是一样的。
我们看看activity的使用:
public class TestAct extends AppCompatActivity {
private static GlobalManager globalManager = null;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.act_test);
if (globalManager == null) {
globalManager = GlobalManager.getInstance(this);
}
}
}
我们来分析一下这段代码:
globalManager = GlobalManager.getInstance(this),这里传入的是Activity的Context,当此Activity退出时,Activity应该被回收,可是这个单例持有这个activity的强引用,导致回收失败,所以造成内存泄漏。
解决方法
我们不管传入的是Context还是ApplicationContext,我们都将它转换为ApplicationContext,这样这个单例就不会持有Activity或其他Context的强引用了。单例代码修改如下
public class GlobalManager {
private volatile static GlobalManager instance;
private Context mContext;
private GlobalManager(Context context) {
this.mContext = context.getApplicationContext();
}
public static GlobalManager getInstance(Context context) {
if (instance == null) {
synchronized (GlobalManager.class) {
if (instance == null) {
instance = new GlobalManager(context);
}
}
}
return instance;
}
}
只是修改了构造方法:讲this.mContext = context;
改成了this.mContext = context.getApplicationContext();
,不管传入什么Context最终将使用Application的Context
ok,单例的内存泄漏情况我们就介绍这么多,下一节介绍非静态内部类作为静态变量造成的内存泄漏情况。
网友评论