内存溢出 out of memory和内存泄露memory leak的区别和联系

1. 内存溢出 out of memory（就是传说中的OOM异常）
是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
2. 内存泄露 memory leak
是指程序在申请内存后，无法释放已申请的内存空间，一次 内存泄露危害可以忽略，但 内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

3.二者的联系：内存泄露最终会导致内存溢出

内存溢出（out of memory）

内存溢出是指当对象的内存占用已经超出分配内存的空间大小，这时未经处理的异常就会抛出。比如常见的内存溢出情况有：bitmap过大；引用没释放；资源对象没关闭

简单而言，内存溢出就是要求分配的内存超出了系统能给的，系统不能满足需求，于是产生溢出。

如图，这是常见的bitma对象的溢出，显示像素过高或图片尺寸远远大于显示空间的尺寸时，通常都要将其缩放，减小占用内存。

内存溢出的原因

1、内存泄露导致

由于我们程序的失误，长期保持某些资源（如Context）的引用，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成内存泄露。

Android 中常见就是Activity被引用在调用finish之后却没有释放，第二次打开activity又重新创建，这样的内存泄露不断的发生,则会导致内存的溢出。

Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程.
2、占用内存较多的对象

保存了多个耗用内存过大的对象（如Bitmap）或加载单个超大的图片，造成内存超出限制。

内存泄漏（memory leak）

有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。
比如，在Activity.onDestroy()被调用之后，view树以及相关的bitmap都应该被垃圾回收。如果一个正在运行的后台线程继续持有这个Activity的引用，那么相关的内存将不会被回收，这最终将导致OutOfMemoryError崩溃。
memory leak会最终会导致out of memory！

 
如图，这是使用MAT工具查找内存泄漏的结果，例子是 handle 延时发送 message 而在关闭 activity 后 context 被销毁所引发的泄漏，这是作为目的性的测试所以问题比较容易找到，在实际开发中内存泄漏不易察觉并难以找到，当泄漏累积到一定程度是会引发 OOM 的。

内存泄漏的原因

比如当你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。
1.资源对象没关闭

如Cursor，File等资源。他们会在finalize中关闭，但这样效率太低。容易造成内存泄漏 
SQLiteCurost,当数据量大的时候容易泄漏

2.使用Adapter时，没有使用系统缓存的converView 
3.没有即时调用recycle()释放不再使用的bitmap 
4.使用application的context来替代activity相关的context

不要让生命周期长于Activity的对象持有到Activity的引用

5.广播注册没取消造成内存泄露 
6.Handler应该申明为静态对象， 并在其内部类中保存一个对外部类的弱引用。

内存泄漏检测工具

leakcanary

上面转载的是：http://blog.csdn.net/sinat_29255093/article/details/52556760

下面转载的是：http://blog.csdn.net/jiayi_yao/article/details/51107960

先说一下：OOM 内存溢出

想要避免OOM 异常首先我们要知道什么情况下会导致OOM 异常。

1、图片过大导致OOM

Android 中用bitmap 时很容易内存溢出， 比如报如下错误：

Java.lang.OutOfMemoryError : bitmap size exceeds VM budget。
解决方法：
方法1： 等比例缩小图片

[java]  view plain  copy

 print ?

1. BitmapFactory.Options options = new BitmapFactory.Options();  
2. options.inSampleSize = 2;  
3. //Options 只保存图片尺寸大小，不保存图片到内存  
4. BitmapFactory.Options opts = new BitmapFactory.Options();  
5. opts.inSampleSize = 2;  
6. Bitmap bmp = null;  
7. bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);  
8. //回收  
9. bmp.recycle();//  

以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
方法2：对图片采用软引用，及时地进行recyle()操作

[java]  view plain  copy

 print ?

1. SoftReference<Bitmap> bitmap = new SoftReference<Bitmap>(pBitmap);  
2. if(bitmap != null){  
3.     if(bitmap.get() != null && !bitmap.get().isRecycled()){  
4.     bitmap.get().recycle();  
5.     bitmap = null;  
6.     }  
7. }  

方法3：使用加载图片框架处理图片，如专业处理加载图片的ImageLoader 图片加载框架。或者还有我们学的XUtils 的BitMapUtils 来做处理。


2、界面切换导致OOM
一般情况下，开发中都会禁止横屏的。因为如果是来回切换话，activity 的生命周期会重新销毁然后创建。
有时候我们会发现这样的问题，横竖屏切换N 次后OOM 了。
这种问题没有固定的解决方法，但是我们可以从以下几个方面下手分析。
1、看看页面布局当中有没有大的图片，比如背景图之类的。
去除xml 中相关设置，改在程序中设置背景图（放在onCreate()方法中）：

[java]  view plain  copy

 print ?

1. Drawable drawable = getResources().getDrawable(R.drawable.id);  
2. ImageView imageView = new ImageView(this);  
3. imageView.setBackgroundDrawable(drawable);  

在Activity destory 时注意，drawable.setCallback(null); 防止Activity 得不到及时的释放。
2、跟上面方法相似，直接把xml 配置文件加载成view 再放到一个容器里，然后直接调用this.setContentView(View view);方法，避免xml 的重复加载。
3、在页面切换时尽可能少地重复使用一些代码
比如：重复调用数据库，反复使用某些对象等等......


3、查询数据库没有关闭游标
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会出现内存问题，这样就会给以后的测试和问题排查带来困难和风险。


4、构造Adapter 时，没有使用缓存的convertView
在使用ListView 的时候通常会使用Adapter ， 那么我们应该尽可能的使用ConvertView。
为什么要使用convertView?
当convertView为空时，用setTag()方法为每个View绑定一个存放控件的ViewHolder对象。当convertView不为空，重复利用已经创建的view的时候，使用getTag()方法获取绑定的ViewHolder对象，这样就避免了findViewById 对控件的层层查询，而是快速定位到控件。


5、Bitmap 对象不再使用时调用recycle()释放内存
有时我们会手工的操作Bitmap 对象，如果一个Bitmap 对象比较占内存，当它不再被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。


6、其他
Android 应用程序中最典型的需要注意释放资源的情况是在Activity 的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。使用广播没有注销也会产生OOM。

下面讲一下内存泄漏：

Android 的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory 的错误。

内存溢出的几点原因：
1. 资源释放问题
程序代码的问题，长期保持某些资源，如Context、Cursor、IO 流的引用，资源得不到释放造成内存泄露。

2. 对象内存过大问题

保存了多个耗用内存过大的对象（如Bitmap、XML 文件），造成内存超出限制。

3. static 关键字的使用问题

static 是Java 中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static 修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context 的情况最多），这时就要谨慎对待了。

[html]  view plain  copy

 print ?

1. public class ClassName {  
2.     private static Context mContext;  
3. //省略  
4. }  

以上的代码是很危险的，如果将Activity 赋值到mContext 的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity 依然不会被释放。

我们举Android 文档中的一个例子。

[java]  view plain  copy

 print ?

1. private static Drawable sBackground;  
2. @Override  
3. protected void onCreate(Bundle state) {  
4.     super.onCreate(state);  
5.     TextView label = new TextView(this); //getApplicationContext  
6.     label.setText("Leaks are bad");  
7.     if (sBackground == null) {  
8.         sBackground = getDrawable(R.drawable.large_bitmap);  
9.     }  
10.     label.setBackgroundDrawable(sBackground);  
11.     setContentView(label);  
12. }  

sBackground 是一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable 与View 连接之后，Drawable 就将View 设置为一个回调，由于View 中是包含Context 的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：
Drawable->TextView->Context
所以，最终该Context 也没有得到释放，发生了内存泄露。
虽然这个例子摘自安卓官方文档, 但这个文档是2009 年1 月的, 安卓版本还在3.0或者3.0 之前.

之所会出现内存泄露是因为在安卓3.0 之前View 的源码中是这样的:

[java]  view plain  copy

 print ?

1. public void setBackgroundDrawable(Drawable background) {  
2.     // ... ...  
3.     background.setCallback(this);  
4.     // ... ...  
5.     }  

Drawable 中源码是这样的:

[java]  view plain  copy

 print ?

1. public final void setCallback(Callback cb) {  
2.     mCallback = cb;  
3. }  

这个background 对象持有View 的引用, View 中又持有Activity 的引用,background 是static, 那么background 只有在虚拟机退出时才会被回收, 它持有的引用才会被释放, 也就是这个View 才有可能被回收,这个Activity 才会被回收.当然,上面就是这么说的, 但是安卓3.0 之后这个问题被解决了

安卓3.0 之后源码中的Drawable 的setCallback 方法是这样:

[java]  view plain  copy

 print ?

1. public final void setCallback(Callback cb) {  
2.     mCallback = new WeakReference<Callback>(cb);  
3. }  

Drawable 中保存的是View 的弱引用, 解决了内存泄露的问题.
针对static 的解决方案
1) 应该尽量避免static 成员变量引用资源耗费过多的实例，比如Context。
2) Context 尽量使用ApplicationContext，因为Application 的Context 的生命周期比较长， 引用它不会出现内存泄露的问题。( 实际上是因为ApplicationContext 对象程序运行就会创建, 程序退出才销毁, 它有且仅有一个, 所以就算不用他也在那里, 不存在回收的问题.)
3) 使用WeakReference 代替强引用。比如可以使用WeakReference<Context> mContextRef;
(补充一点, getSystemService 方法请尽量使用ApplicationContext 去调用, 某些厂商修改了底层代码导致系统服务引用的Context 不能释放.)

4. 线程导致内存溢出

[java]  view plain  copy

 print ?

1. public class MyActivity extends Activity {  
2.     @Override  
3.     public void onCreate(Bundle savedInstanceState) {  
4.         super.onCreate(savedInstanceState);  
5.         setContentView(R.layout.main);  
6.         new MyThread().start();  
7.     }  
8.     private class MyThread extends Thread{  
9.         @Override  
10.         public void run() {  
11.             super.run();  
12.             //do somthing while(true)  
13.         }  
14.     }  
15. }  

这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run 函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity 应该会被销毁才对，然而事实上并非如此。由于我们的线程是Activity 的内部类，所以MyThread 中保存了Activity 的一个引用，当MyThread 的run 函数没有结束时，MyThread 是不会被销毁的，因此它所引用的老的Activity 也不会被销毁，因此就出现了内存泄露的问题。
怎么解决? 篇幅太长, 贴一个orcale 的官方文档地址:
http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
有些人喜欢用Android 提供的AsyncTask，但事实上AsyncTask 的问题更加严重，Thread 只有在run 函数不结束时才出现这种内存泄露问题，然而AsyncTask 内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread 对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask 作为Activity 的内部类，就更容易出现内存泄露的问题。
针对这种线程导致的内存泄露问题的解决方案：
（一） 将线程的内部类，改为静态内部类（因为非静态内部类拥有外部类对象的强引用，而静态类则不拥有）。
（二） 在线程内部采用弱引用保存Context 引用。

(针对AsyncTask 怎么解决?

AsyncTask 有cancle()方法, 终止任务. 但是, 这个方法是不一定成功的!
如果是由循环组成的耗时操作, 循环中判断isCancle(), 如果为true, break 掉循环. 在Activity 的onDestory 调用AsyncTask 的cancle()方法.
AsyncTask 适合短耗时的操作, 几秒钟, 如果长耗时, 请使用其它API, 比如Executor,ThreadPoolExecutor 和FutureTask 等)

补充一点: registerReciever 一定要调用unregisterReciever， 但是如果注册广播接收者不成功, 取消注册时将会抛出异常. 解决方法: 取消注册try...catch.

补充:

使用cursor 要关闭,
使用database 要关闭,
使用流要关闭,
使用Timer 必须calcel,
使用TimerTask 必须cancel,
注册内容观察者必须取消注册
内容观察者被添加到ContentQueryMap 后不用时delete 这个内容观察者
Handler 在activity 的onDestory 中removeMessageAndCallback(null)