内存泄露和内存溢出,并不是那么简单 1.内存溢出oom 程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vm heapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。 java程序发生OMM并不是表示RAM不足，如果RAM真的不足，会发生什么呢？这时Android的memory killer会起作用，当RAM所剩不多时，memory killer会杀死一些优先级比较低的进程来释放物理内存，让高优先级程序得到更多的内存

59 阅读 0 评论 39 点赞

我是靠谱客的博主结实御姐，最近开发中收集的这篇文章主要介绍内存泄露和内存溢出,并不是那么简单 1.内存溢出oom 程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vm heapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。 java程序发生OMM并不是表示RAM不足，如果RAM真的不足，会发生什么呢？这时Android的memory killer会起作用，当RAM所剩不多时，memory killer会杀死一些优先级比较低的进程来释放物理内存，让高优先级程序得到更多的内存，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1.内存溢出oom

程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vm heapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。

java程序发生OMM并不是表示RAM不足，如果RAM真的不足，会发生什么呢？这时Android的memory killer会起作用，当RAM所剩不多时，memory killer会杀死一些优先级比较低的进程来释放物理内存，让高优先级程序得到更多的内存

这个是因为Android系统对dalvik的vm heapsize作了硬性限制，当java进程申请的java空间超过阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。

也就是说，程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vm heapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM.

即发生内存泄露,是oom的主要源头。

2.内存泄露

Java内存泄漏指的是进程中某些对象（垃圾对象）已经没有使用价值了，但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。无用的对象占据着内存空间，使得实际可使用内存变小，形象地说法就是内存泄漏了.内存泄露的原因以及解决方法有:

2.1非静态内部类的静态实例容易造成内存泄漏

对于lauchMode不是singleInstance的Activity，应该避免在activity里面实例化其非静态内部类的静态实例。

2.2activity使用静态成员

·不要对activity的context长期引用(一个activity的引用的生存周期应该和activity的生命周期相同)

·如果可以的话，尽量使用关于application的context来替代和activity相关的context

·如果一个acitivity的非静态内部类的生命周期不受控制，那么避免使用它；正确的方法是使用一个静态的内部类，并且对它的外部类有一WeakReference，就像在ViewRootImpl中内部类W所做的那样。

2.3使用handler时的内存问题

This Handler class should be static or leaks might occur (com.example.ta.HandlerActivity.1)

可以将handler变为static ,或者添加弱引用

public class SampleActivity extends Activity {
/**
* 使用静态的内部类，不会持有当前对象的引用
*/
private static class MyHandler extends Handler {
private final WeakReference<SampleActivity> mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference<SampleActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
SampleActivity activity = mActivity.get();
if (activity != null) {
// ...
}
}
}
private final MyHandler mHandler = new MyHandler(this);
/**
* 使用静态的内部类，不会持有当前对象的引用
*/
private static final Runnable sRunnable = new Runnable() {
@Override
public void run() { }
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//
发送一个10分钟后执行的一个消息
mHandler.postDelayed(sRunnable, 600000);
// 结束
finish();
}
}

因为HandlerThread实现的run方法是一个无限循环，它不会自己结束，线程的生命周期超过了activity生命周期，当横竖屏切换，HandlerThread线程的数量会随着activity重建次数的增加而增加。

应该在onDestroy时将线程停止掉：mThread.getLooper().quit();

另外，对于不是HandlerThread的线程，也应该确保activity消耗后，线程已经终止，可以这样做：在onDestroy时调用mThread.join();

2.4注册某个对象后未取消注册

注册广播接收器、注册观察者等等,当它不用时,及时unregister

2.5集合中对象没清理造成的内存泄露

2.6资源对象没关闭造成的内存泄露

对文件,资源进行调用,cursor等,当资源对象加载完成,应该及时colse();

参考文档:http://blog.csdn.net/gemmem/article/details/13017999