本文原地址,非常不错的文章
- 集合类泄漏
集合类如果仅仅有添加元素的方法,而没有相应的删除机制,导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性,全局性的 map 等即有静态引用或 final 一直指向它),那么没有相应的删除机制,很可能导致集合所占用的内存只增不减。比如上面的典型例子就是其中一种情况,当然实际上我们在项目中肯定不会写这么 2B 的代码,但稍不注意还是很容易出现这种情况,比如我们都喜欢通过 HashMap 做一些缓存之类的事,这种情况就要多留一些心眼。
单例造成的内存泄漏
由于单例的静态特性使得其生命周期跟应用的生命周期一样长,所以如果使用不恰当的话,很容易造成内存泄漏。比如下面一个典型的例子,public class AppManager { private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context; } public static AppManager getInstance(Context context) { if (instance == null) { instance = new AppManager(context); } return instance; } }
这是一个普通的单例模式,当创建这个单例的时候,由于需要传入一个Context,所以这个Context的生命周期的长短至关重要:
1.如果此时传入的是 Application 的 Context,因为 Application 的生命周期就是整个应用的生命周期,所以这将没有任何问题。
2.如果此时传入的是 Activity 的 Context,当这个 Context 所对应的 Activity 退出时,由于该 Context 的引用被单例对象所持有,其生命周期等于整个应用程序的生命周期,所以当前 Activity 退出时它的内存并不会被回收,这就造成泄漏了。
正确的方式应该改为下面这种方式:public class AppManager { private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context.getApplicationContext(); // 使用Application 的context } public static AppManager getInstance(Context context){ if (instance == null) { instance = new AppManager(context); } return instance; } }
或者这样写,连 Context 都不用传进来了。在你的 Application 中添加一个静态方法,getContext() 返回 Application 的 context,
public class AppManager {
private static AppManager instance;
private Context context = getApplicationContext();
this.context = MyApplication.getContext();
private AppManager() {
}
// 使用Application 的context
public static AppManager getInstance() {
if (instance == null) {
instance = new AppManager();
}
return instance;
}
/**
* 获取全局的context
* @return 返回全局context对象
*/
public static Context getContext(){
return context;
}
}
- 匿名内部类/非静态内部类和异步线程
- 匿名内部类
- Handler 造成的内存泄漏
- 尽量避免使用 static 成员变量
- 避免 override finalize()
- 资源未关闭造成的内存泄漏
- 一些不良代码造成的内存压力
- 总结