[老实李] Android 内存泄漏全解析
一、什么是内存泄漏
内存泄露 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；任何时候计数器都为0的对象就是不可能再被使用的。引用计数器算法（Reference Counting）实现简单，判定效率也很高，在大部分情况下他都是一个不错的算法。但是，Java语言中没有选用引用计数算法来管理内存，其中最主要的原因是他很难解决对象之间的互相循环引用的问题。 -
根搜索算法（GC Roots Tracing）
基本思路是通过一系列名为“GC Roots”的对象作为起始点，从这个节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连（用图论术语描述就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。在主流的商用程序语言中（Java、C#）,都是使用根搜索算法判定对象是否存活的。
常见回收算法：
-
标记-清除算法：标记阶段：先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象；清除阶段：清除所有未被标记的对象。 -
复制算法：（新生代的GC）将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，然后清除正在使用的内存块中的所有对象。 -
标记-整理算法：（老年代的GC）标记阶段：先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象整理阶段：将将所有的存活对象压缩到内存的一端；之后，清理边界外所有的空间 -
分代收集算法：存活率低：少量对象存活，适合复制算法：在新生代中，每次GC时都发现有大批对象死去，只有少量存活（新生代中98%的对象都是“朝生夕死”），那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成GC。存活率高：大量对象存活，适合用标记-清理/标记-整理：在老年代中，因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“标记-清理”/“标记-整理”算法进行GC。
三、导致内存泄漏的原因
一句话:长生命周期的对象持有短生命周期的对象。短生命周期对象无法及时释放。
导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器GC验证这些对象是否不再需要。如果存在对象的引用，这个对象就被定义为"有效的活动"，同时不会被释放。要确定对象所占内存将被回收，我们就要务必确认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。但当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。
-
static变量引用待释放类实例
比如MainActivity里面有一个静态的变量sMainActivity = this,这就会照成内存泄漏，比如静态集合类没有及时setnull - 单例
- 如果此时传入的是 Application 的 Context，因为 Application 的生命周期就是整个应用的生命周期，所以这将没有任何问题。
- 如果此时传入的是 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对象，如果不包含就是内存泄漏。
