一、什么是内存泄漏

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。memory leak会最终会导致out of memory！

内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出！比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出.

二、Java 内存分配策略

知道了什么是内存泄漏，我们就不得不提Java 的内存分配策略。Java程序运行时的内存分配策略有三种，分别是静态分配，栈式分配，和堆式分配。对应的三种策略使用的内存空间是要分别是静态存储区（也称方法区），栈区，和堆区。

• 静态存储区（方法区）：主要存放静态数据，全局static数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。
• 栈区：当方法执行时，方法内部的局部变量都建立在栈内存中，并在方法结束后自动释放分配的内存。因为栈内存分配是在处理器的指令集当中所以效率很高，但是分配的内存容量有限。
• 堆区：又称动态内存分配，通常就是指在程序运行时直接new出来的内存。这部分内存在不适用时将会由Java垃圾回收器来负责回收。

堆与栈的区别

在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都在方法的栈内存中分配。
堆内存用来存放所有new出来的对象(包括该对象内的所有成员变量)和数组。
在堆中分配的内存，由Java垃圾回收管理器来自动管理。

public class Sample {
    int s1 = 0;
    Sample mSample1 = new Sample();

    public void method() {
        int s2 = 0;
        Sample mSample2 = new Sample();
    }
}
    Sample mSample3 = new Sample();

如上局部变量s2和mSample2存放在栈内存中，mSample3所指向的对象存放在堆内存中，包括该对象的成员变量s1和mSample1也存放在堆中，而它自己则存放在栈中( 这句话的意思就是 Sample mSample3 是在栈中的，而 new Sample（）是在堆中的,mSample3就是个引用变量，我们可以通过引用变量访问堆内存中的对象或者数组 )。

结论
局部变量的基本类型和引用存储在栈内存中，引用的实体存储在堆中。——因它们存在于方法中，随方法的生命周期而结束。
成员变量全部存储于堆中（包括基本数据类型，引用和引用的对象实体）。——因为它们属于类，类对象终究要被new出来使用。

Java GC 原理与算法机制

由程序分配内存，GC来释放内存。内存释放的原理为该对象或者数组不再被引用，则JVM会在适当的时候回收内存。

GC机制判断对象是否存活的算法：

1. 引用计数算法
   给对象添加一个引用计数器，当有一个地方引用它时，计数器值就加1；当引用失效时，计数器就减1；任何时候计数器都为0的对象就是不可能再被使用的。引用计数器算法（Reference Counting）实现简单，判定效率也很高，在大部分情况下他都是一个不错的算法。但是，Java语言中没有选用引用计数算法来管理内存，其中最主要的原因是他很难解决对象之间的互相循环引用的问题。

2. 根搜索算法（GC Roots Tracing）
   基本思路是通过一系列名为“GC Roots”的对象作为起始点，从这个节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连（用图论术语描述就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。在主流的商用程序语言中（Java、C#）,都是使用根搜索算法判定对象是否存活的。

常见回收算法：

1. 标记-清除算法：标记阶段：先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象；清除阶段：清除所有未被标记的对象。
2. 复制算法：（新生代的GC）将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，然后清除正在使用的内存块中的所有对象。
3. 标记-整理算法：（老年代的GC）标记阶段：先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象整理阶段：将将所有的存活对象压缩到内存的一端；之后，清理边界外所有的空间
4. 分代收集算法：存活率低：少量对象存活，适合复制算法：在新生代中，每次GC时都发现有大批对象死去，只有少量存活（新生代中98%的对象都是“朝生夕死”），那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成GC。存活率高：大量对象存活，适合用标记-清理/标记-整理：在老年代中，因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“标记-清理”/“标记-整理”算法进行GC。

三、导致内存泄漏的原因

一句话:长生命周期的对象持有短生命周期的对象。短生命周期对象无法及时释放。

导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器GC验证这些对象是否不再需要。如果存在对象的引用，这个对象就被定义为"有效的活动"，同时不会被释放。要确定对象所占内存将被回收，我们就要务必确认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。但当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。

• static变量引用待释放类实例
  比如MainActivity里面有一个静态的变量sMainActivity = this,这就会照成内存泄漏，比如静态集合类没有及时setnull
• 单例

1. 如果此时传入的是 Application 的 Context，因为 Application 的生命周期就是整个应用的生命周期，所以这将没有任何问题。
2. 如果此时传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。

• 资源对象没有关闭
  广播没有反注册，EventBus没有反注册，Cursor对象没有关，流没有关 等等
• 集合类泄漏

List<Object> objectList = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            Object o = new Object();
            objectList.add(o);
            o = null;
        }

上面的实例，虽然在循环中把引用o释放了，但是它被添加到了objectList中，所以objectList也持有对象的引用，此时该对象是无法被GC的。因此对象如果添加到集合中，还必须从中删除，最简单的方法

        //释放objectList
        objectList.clear();
        objectList=null;

• webview内存泄漏
  webview是开启的一个子线程，如果子线程没有运行结束就销毁了activity的话，那么子线程还是持有activity的，这时候就产生了内存泄漏
• Handler使用非静态的时候
  我们知道非static的内部类会持有外部类的引用，如果此时Handler从消息队列有未处理的Message，在Activity finish之后Message还是存在，那么Handler也存在，handler里面又有Context的引用，也就是Activity也存在，那就发生了内存泄漏。
  解决办法：静态内部类，即使用static修饰Handler，通过 WeakReference 来保持外部的Activity对象。

private Handler mHandler = new MyHandler(this);
private static class MyHandler extends Handler{
    private final WeakReference<Activity> mActivity;
    public MyHandler(Activity activity) {
        mActivity = new WeakReference<Activity>(activity);
    }
    @Override
    public void handleMessage(Message msg) {
        System.out.println(msg);
        if(mActivity.get() == null) {
            return;
        }
    }
}

四、解决内存泄漏的途径

下面演示几个使用LeakCanary解决内存泄漏的例子
1、消灭Context泄漏
泄漏原因：将Activity当做Context对象使用

消灭Context泄漏.jpg

这就是一条内存泄漏过程的引用链，这条引用链最后一行的位置是泄漏发生的地方，第一行是泄漏的源头，我们主要观察的地方就是内存泄漏的源头部分。比如，上面的内存泄漏的源头就是MainActivity中使用了MainActivity这个Activity作为Context所引起的内存泄漏。

Image.png

解决方式就是使用ApplicationContext代替Activity Context

2、消灭static引用

消灭static引用.jpg

可以看到在代码中使用了static修饰的变量dialog，static关键字修饰的dialog属于类所有，而不属于任何特定的实例，所以即使UploadDataDialog销毁了，dialog还是存在的。所以在Dialog销毁的时候这个static变量不能被GC回收，所以我们要重写dismiss方法，当UploadDataDialog dismiss的时候我们就让其将成员变量dialog置为空即可。

public class UploadDataDialog  extends Dialog{
    private Context context;
    private static UploadDataDialog dialog;
    private ImageView ivProgress;

    public UploadDataDialog(Context context) {
        super(context);
        this.context = context;
    }

    public UploadDataDialog(Context context, int themeResId) {
        super(context, themeResId);
        this.context = context;

    }

    public static UploadDataDialog showDialog(Context context){
        dialog = new UploadDataDialog(context, R.style.UploadDataDialog);
        dialog.setContentView(R.layout.dialog_uploaddata);
        dialog.setCanceledOnTouchOutside(false);
        return dialog;
    }

    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
        if(hasFocus && dialog != null){
            ivProgress = (ImageView) dialog.findViewById(R.id.ivProgress);
            Animation animation = AnimationUtils.loadAnimation(context, R.anim.dialog_progress_anim);
            ivProgress.startAnimation(animation);
        }
    }

    @Override
    public void dismiss() {
        super.dismiss();
        if (dialog != null) {
            dialog = null;
        }
    }
}

3、使用暴力反射解决内存泄漏问题

暴力反射解决内存泄漏问题.png

这个问题还是比较奇怪的，我使用LocalBroadcastManager管理各种监听的注册反注册，但是现在提示我LocalBroadcastManager中的mInstance出现了泄漏，而LocalBroadcastManager是Android SDK中的，所以只能通过暴力反射来拿到这个成员变量然后置空。

@Override
protected void onDestroy() {
    super.onDestroy();
   
    try {
        Class clazz = Class.forName("android.support.v4.content.LocalBroadcastManager");
        //获取成员属性mInstance(单例对象)
        Field field = clazz.getDeclaredField("mInstance");
        //设置private属性可访问
        if (field.isAccessible() == false) {
            field.setAccessible(true);
        }
        //置空属性
        field.set(null, null);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

4、一个java内存泄漏的例子

class MyList{  
      
    /* 
     * 此处只为掩饰效果，并没有进行封装之类的操作 
     *  
     * 将List集合用关键字 static 声明，这时这个集合将不属于任何  MyList 对象，而是一个类成员变量 
     *  
     */  
    public static List<String> list = new ArrayList<String>();  
      
}  
  
 class Demmo{  
     public static void main(String[] args) {  
         MyList list = new MyList();  
         list.list.add("123456");  
         // 此时即便我们将 list指向null，仍然存在内存泄漏，因为MyList中的list是静态的，它属于类所有而不属于任何特定的实例  
         list = null;  
    }  
 }  

Image.png

五、LeakCanary解决内存泄露的原理

LeakCanary 在 Application 中安装完成后，会注册对应用内所有 Activity 生命周期的监听，也就是在Activity的onDestroy的时候将Activity传到watch方法中，然后在watch方法中的时候会把activity包装成一个弱引用。并且为这个弱引用指定了一个队列，这个队列的作用就是当发生GC后，弱引用就会被放到这个队列里面。（Activity如果被强引用的话，就不会放到这个队列里面了，也就是内存泄漏了。）所以我们就可以通过手动执行一下GC操作，来看队列里面是不是包含这个activity对象，如果不包含就是内存泄漏。