上一节我们介绍了关于匿名内部类的内存泄漏，这一节我们来看一下单例产生内存泄漏的情况
知识点
单例的生命周期和应用（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，单例的内存泄漏情况我们就介绍这么多，下一节介绍非静态内部类作为静态变量造成的内存泄漏情况。
