内存泄漏的原因及案例

1.单例导致

由于单例的静态特性使得其生命周期跟应用的生命周期一样长，所以如果使用不恰当的话，很容易造成内存泄漏。比如下面一个典型的例子:

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;
     }
}

如果此时传入的是 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;
    }
}

有时候在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收

public class MainActivity extends AppCompatActivity {
     private static TestResource mResource = null;
     @Override
     protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            if(mManager == null){
                  mManager = new TestResource();
            }
            //...
     }
     class TestResource {
          //...
     }
}

正确的做法应该是

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。

2 非静态内部类导致

原因
1非静态内部类对外部类会存在一个隐式引用

class Out extends Activity{
    @Override
    protected void onCreate(Bundle savedInstanceState) {
     launch.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                outmethod();
            }
        });}
void outmethod(){
}
}
内部类能调用外部类的方法是因为持有外部类的引用

2非静态内部类中存在异步任务，可能会导致其对应的外部类内存资源无法正常释放

class Out extends Activity{
    @Override
    protected void onCreate(Bundle savedInstanceState) {
     launch.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                mPresenter.getData();
            }
        });}
void outmethod(){
}
}
这里面有网络请求的耗时任务

解决方案：

解决思路
1去除隐式引用（通过静态内部类来去除隐式引用）
2手动管理对象引用（修改静态内部类的构造方式，手动引入其外部类引用）
3当内存不可用时，不执行不可控代码（Android可以结合智能指针，WeakReference包裹外部类实例）

class Out extends Activity{
    @Override
    protected void onCreate(Bundle savedInstanceState) {
     launch.setOnClickListener(new listener(Out.this));
}
     void outmethod(){}
 static  class listener implements View.OnClickListener{
        private WeakReference weakReference;
        public listener(Out out) {
            this.weakReference=new WeakReference(out);
        }
        

        @Override
          public void onClick(View view) {
            weakReference.get().outmethod();

          }
      }
}

android中的几类引用
StrongReference强引用可以直接访问目标对象，强引用所关联的对象，在任何时候都不会被内存回收，JVM宁肯抛出OOM异常，也不会对其进行回收，所以，在通常的内存泄漏中，大多都有强引用的身影
（SoftReference）
软引用是除了硬引用之外最强的一种引用，软引用和硬引用的不同点在于，软引用是可被回收的；回收机制是：当内存充足的时候，在GC时,不会去回收当前的软引用，当内存临近阈值或不足的时候，在GC时，发现某一对象的引用只具有软引用当前软引用就会被回收。
（WeakReference）
弱引用是比软引用和硬引用更弱的一种引用，在GC时，不论内存是否充足，发现某一对象的引用只具有弱引用当前弱引用就会被回收。
(PhantomReference)
虚引用不能保证其保存对象生命周期，其保存对象若只有虚引用，则其有效期完全随机于GC的回收，在任何一个不确定的时间内，都可能会被回收；而虚引用与其他几者的引用不同在于，在使用PhantomReference，必须要和Reference联合使用。

引用使用方式

ReferenceQueue queue = new ReferenceQueue();
WeakReference weakReference = new WeakReference(this,queue);
SoftReference softReference = new SoftReference(this,queue);
PhantomReference phantomReference = new PhantomReference(this,queue);

那么这个ReferenceQueue有什么用呢？

引用对象本身，也是一个强引用，其除了具有保存一个对象本身特有的引用属性之外，引用对象本身也具有java对象的一般性，那么在其本身保存的对象被回收之后，引用对象本身也就没有了实用性质，需要一个适当的清理机制，来清理这些对象，避免大量这些引用对象而带来的内存泄漏；这时候，就可以用到ReferenceQueue。

当引用（SoftReference/WeakReference/PhantomReference）中保存的的对象，被GC回收时，引用本身的这个对象会被加入到ReferenceQueue中，那么，也就是说，ReferenceQueue中保存的对象是Reference，并且是失去了其保存的对象的Reference。这个时候我们可以通过调用ReferenceQueue中提供的poll()这个API来获取队列中的对象，当队列中不存在对象的时候，返回的会是null，当存在或存在多个的时候，都是返回最前面的一个Reference对象，这个时候我们就需要将这个对象进行清除，让相应的内存可以被释放掉。

Reference ref = null;
while ((ref = queue.poll()) != null) {
// 清除ref
}

3静态内部类中创建了一个静态实例，会导致内存泄漏（参考上面单例导致的内存泄漏）

3.资源回收

对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。

4ListView

初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。构造Adapter时，没有使用缓存的convertView。

5webview

我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。

6集合

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。