深入了解 JavaScript 内存泄漏

Posted 2023-03-21

作者：京东零售 谢天

在任何语言开发的过程中，对于内存的管理都非常重要，javascript 也不例外。

然而在前端浏览器中，用户一般不会在一个页面停留很久，即使有一点内存泄漏，重新加载页面内存也会跟着释放。而且浏览器也有自己的自动回收内存的机制，所以前端并没有特别关注内存泄漏的问题。

但是如果我们对内存泄漏没有什么概念，有时候还是有可能因为内存泄漏，导致页面卡顿。了解内存泄漏，如何避免内存泄漏，都是不可缺少的。

什么是内存

在硬件级别上，计算机内存由大量触发器组成。每个触发器包含几个晶体管，能够存储一个位。单个触发器可以通过唯一标识符寻址，因此我们可以读取和覆盖它们。因此，从概念上讲，我们可以把我们的整个计算机内存看作是一个巨大的位数组，我们可以读和写。

这是内存的底层概念，JavaScript 作为一个高级语言，不需要通过二进制进行内存的读写，而是相关的 JavaScript 引擎做了这部分的工作。

内存的生命周期

内存也会有生命周期，不管什么程序语言，一般可以按照顺序分为三个周期：

• 分配期：分配所需要的内存
• 使用期：使用分配的内存进行读写
• 释放期：不需要时将其释放和归还

内存分配 -> 内存使用 -\\> 内存释放

什么是内存泄漏

在计算机科学中，内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费。

如果内存不需要时，没有经过生命周期的的释放期，那么就存在内存泄漏。

内存泄漏的简单理解：无用的内存还在占用，得不到释放和归还。比较严重时，无用的内存会持续递增，从而导致整个系统的卡顿，甚至崩溃。

JavaScript 内存管理机制

像 C 语言这样的底层语言一般都有底层的内存管理接口，但是 JavaScript 是在创建变量时自动进行了内存分配，并且在不使用时自动释放，释放的过程称为“垃圾回收”。然而就是因为自动回收的机制，让我们错误的感觉开发者不必关心内存的管理。

JavaScript 内存管理机制和内存的生命周期是一致的，首先需要分配内存，然后使用内存，最后释放内存。绝大多数情况下不需要手动释放内存，只需要关注对内存的使用（变量、函数、对象等）。

内存分配

JavaScript 定义变量就会自动分配内存，我们只需要了解 JavaScript 的内存是自动分配的就可以了。

let num = 1;
const str = "名字";
const obj = 
  a: 1,
  b: 2

const arr = [1, 2, 3];
function func (arg)  ... 

内存使用

使用值的过程实际上是对分配的内存进行读写的操作，读取和写入的操作可能是写入一个变量或者一个对象的属性值，甚至传递函数的参数。

// 继续上部分
// 写入内存
num = 2;
// 读取内存，写入内存
func(num);

内存回收

垃圾回收被称为​​GC(Garbage Collection)​​

内存泄漏一般都是发生在这一步，JavaScript 的内存回收机制虽然可以回收绝大部分的垃圾内存，但是还是存在回收不了的情况，如果存在这些情况，需要我们自己手动清理内存。

以前一些老版本的浏览器的 JavaScript 回收机制没有那么完善，经常出现一些 bug 的内存泄漏，不过现在的浏览器一般都没有这个问题了。

这里了解下现在 JavaScript 的垃圾内存的两种回收方式，熟悉一下这两种算法可以帮助我们理解一些内存泄漏的场景。

引用计数

这是最初级的垃圾收集算法。此算法把“对象是否不再需要”简化定义为“对象有没有其他对象引用到它”。如果没有引用指向该对象（零引用），对象将被垃圾回收机制回收。

// “对象”分配给 obj1
var obj1 = 
  a: 1,
  b: 2

// obj2 引用“对象”
var obj2 = obj1;
// “对象”的原始引用 obj1 被 obj2 替换
obj1 = 1;

当前执行环境中，“对象”内存还没有被回收，需要手动释放“对象”的内存（在没有离开当前执行环境的前提下）

obj2 = null;
// 或者 obj2 = 1;
// 只要替换“对象”就可以了

这样引用的“对象”内存就被回收了。

ES6 中把引用分为​​强引用​​和​​弱引用​​，这个目前只有在 Set 和 Map 中才存在。

强引用才会有引用计数叠加，只有引用计数为 0 的对象的内存才会被回收，所以一般需要手动回收内存（手动回收的前提在于标记清除法还没执行，还处于当前的执行环境）。

而弱引用没有触发引用计数叠加，只要引用计数为 0，弱引用就会自动消失，无需手动回收内存。

标记清除

当变量进入执行时标记为“进入环境”，当变量离开执行环境时则标记为“离开环境”，被标记为“进入环境”的变量是不能被回收的，因为它们正在被使用，而标记为“离开环境”的变量则可以被回收。

环境可以理解为我们的执行上下文，全局作用域的变量只会在页面关闭时才会被销毁。

// 假设这里是全局上下文
var b = 1; // b 标记进入环境
function func() 
  var a = 1;
  return a + b; // 函数执行时，a 被标记进入环境

func();
// 函数执行结束，a 被标记离开环境，被回收
// 但是 b 没有标记离开环境

JavaScript 内存泄漏的一些场景

JavaScript 的内存回收机制虽然能回收绝大部分的垃圾内存，但是还是存在回收不了的情况。程序员要让浏览器内存泄漏，浏览器也是管不了的。

下面有些例子是在执行环境中，没离开当前执行环境，还没触发标记清除法。所以你需要读懂上面 JavaScript 的内存回收机制，才能更好的理解下面的场景。

意外的全局变量

// 在全局作用域下定义
function count(num) 
  a = 1; // a 相当于 window.a = 1;
  return a + num;

不过在 eslint 帮助下，这种场景现在基本没人会犯了，eslint 会直接报错，了解下就好。

遗忘的计时器

无用的计时器忘记清理，是最容易犯的错误之一。

拿一个 vue 组件举个例子。

<script>
export default 
  mounted() 
    setInterval(() => 
      this.fetchData();
    , 2000);
  ,
  methods: 
    fetchData()  ... 
  

</script>

上面的组件销毁的时候，​​setInterval​​还是在运行的，里面涉及到的内存都是没法回收的（浏览器会认为这是必须的内存，不是垃圾内存），需要在组件销毁的时候清除计时器。

<script>
export default 
  mounted() 
    this.timer = setInterval(() =>  ... , 2000);
  ,
  beforeDestroy() 
    clearInterval(this.timer);
  

</script>

遗忘的事件监听

无用的事件监听器忘记清理也是最容易犯的错误之一。

还是使用 vue 组件举个例子。

<script>
export default 
  mounted() 
    window.addEventListener(resize, () =>  ... );
  

</script>

上面的组件销毁的时候，resize 事件还是在监听中，里面涉及到的内存都是没法回收的，需要在组件销毁的时候移除相关的事件。

<script>
export default 
  mounted() 
    this.resizeEvent = () =>  ... ;
    window.addEventListener(resize, this.resizeEvent);
  ,
  beforeDestroy() 
    window.removeEventListener(resize, this.resizeEvent);
  

</script>

遗忘的 Set 结构

Set 是 ES6 中新增的数据结构，如果对 Set 不熟，可以看​​这里​​。

如下是有内存泄漏的（成员是引用类型，即对象）：

let testSet = new Set();
let value =  a: 1 ;
testSet.add(value);
value = null;

需要改成这样，才会没有内存泄漏：

let testSet = new Set();
let value =  a: 1 ;
testSet.add(value);

testSet.delete(value);
value = null;

有个更便捷的方式，使用 WeakSet，WeakSet 的成员是弱引用，内存回收不会考虑这个引用是否存在。

let testSet = new WeakSet();
let value =  a: 1 ;
testSet.add(value);
value = null;

遗忘的 Map 结构

Map 是 ES6 中新增的数据结构，如果对 Map 不熟，可以看​​这里​​。

如下是有内存泄漏的（成员是引用类型，即对象）：

let map = new Map();
let key = [1, 2, 3];
map.set(key, 1);
key = null;

需要改成这样，才会没有内存泄漏：

let map = new Map();
let key = [1, 2, 3];
map.set(key, 1);

map.delete(key);
key = null;

有个更便捷的方式，使用 WeakMap，WeakMap 的键名是弱引用，内存回收不会考虑到这个引用是否存在。

let map = new WeakMap();
let key = [1, 2, 3];
map.set(key, 1);
key = null

遗忘的订阅发布

和上面事件监听器的道理是一样的。

建设订阅发布事件有三个方法，​​emit​​、​​on​​、​​off​​三个方法。

还是继续使用 vue 组件举例子：

<template>
  <div @click="onClick"></div>
</template>
<script>
import EventEmitter from event;

export default 
  mounted() 
    EventEmitter.on(test, () =>  ... );
  ,
  methods: 
    onClick() 
      EventEmitter.emit(test);
    
  

</script>

上面组件销毁的时候，自定义 test 事件还是在监听中，里面涉及到的内存都是没办法回收的，需要在组件销毁的时候移除相关的事件。

<template>
  <div @click="onClick"></div>
</template>
<script>
import EventEmitter from event;

export default 
  mounted() 
    EventEmitter.on(test, () =>  ... );
  ,
  methods: 
    onClick() 
      EventEmitter.emit(test);
    
  ,
  beforeDestroy() 
    EventEmitter.off(test);
  

</script>

遗忘的闭包

闭包是经常使用的，闭包能提供很多的便利，

首先看下下面的代码：

function closure() 
  const name = 名字;
  return () => 
    return name.split().reverse().join();
  

const reverseName = closure();
reverseName(); // 这里调用了 reverseName

上面有没有内存泄漏？是没有的，因为 name 变量是要用到的（非垃圾），这也是从侧面反映了闭包的缺点，内存占用相对高，数量多了会影响性能。

但是如果​​reverseName​​没有被调用，在当前执行环境未结束的情况下，严格来说，这样是有内存泄漏的，​​name​​变量是被​​closure​​返回的函数调用了，但是返回的函数没被使用，在这个场景下​​name​​就属于垃圾内存。​​name​​不是必须的，但是还是占用了内存，也不可被回收。

当然这种也是极端情况，很少人会犯这种低级错误。这个例子可以让我们更清楚的认识内存泄漏。

DOM 的引用

每个页面上的 DOM 都是占用内存的，建设有一个页面 A 元素，我们获取到了 A 元素 DOM 对象，然后赋值到了一个变量（内存指向是一样的），然后移除了页面上的 A 元素，如果这个变量由于其他原因没有被回收，那么就存在内存泄漏，如下面的例子：

class Test 
  constructor() 
    this.elements = 
      button: document.querySelector(#button),
      div: document.querySelector(#div)
    
  
  removeButton() 
    document.body.removeChild(this.elements.button);
    // this.elements.button = null
  


const test = new Test();
test.removeButton();

上面的例子 button 元素虽然在页面上移除了，但是内存指向换成了​​this.elements.button​​，内存占用还是存在的。所以上面的代码还需要这么写：​​this.elements.button = null​​，手动释放内存。

如何发现内存泄漏

内存泄漏时，内存一般都是周期性的增长，我们可以借助谷歌浏览器的开发者工具进行判断。

这里针对下面的例子进行一步步的的排查和找到问题点：

<html>
  <body>
    <div id="app">
      <button id="run">运行</button>
      <button id="stop">停止</button>
    </div>
    <script>
      const arr = []
      for (let i = 0; i < 200000; i++) 
        arr.push(i)
      
      let newArr = []

      function run() 
        newArr = newArr.concat(arr)
      

      let clearRun

      document.querySelector(#run).onclick = function() 
        clearRun = setInterval(() => 
          run()
        , 1000)
      

      document.querySelector(#stop).onclick = function() 
        clearInterval(clearRun)
      
    </script>
  </body>
</html>

确实是否是内存泄漏问题

访问上面的代码页面，打开开发者工具，切换至 Performance 选项，勾选 Memory 选项。

在页面上点击运行按钮，然后在开发者工具上面点击左上角的录制按钮，10 秒后在页面上点击停止按钮，5 秒停止内存录制。得到内存走势如下：

由上图可知，10 秒之前内存周期性增长，10 秒后点击了停止按钮，内存平稳，不再递增。我们可以使用内存走势图判断是否存在内存泄漏。

查找内存泄漏的位置

上一步确认内存泄漏问题后，我们继续利用开发者工具进行问题查找。

访问上面的代码页面，打开开发者工具，切换至 Memory 选项。页面上点击运行按钮，然后点击开发者工具左上角的录制按钮，录制完成后继续点击录制，直到录制完成三个为止。然后点击页面上的停止按钮，在连续录制三次内存（不要清理之前的录制）。

从这里也可以看出，点击运行按钮之后，内存在不断的递增。点击停止按钮之后，内存就平稳了。虽然我们也可以用这种方式来判断是否存在内存泄漏，但是没有第一步的方法便捷，走势图也更加直观。

然后第二步的主要目的是为了记录 JavaScript 堆内存，我们可以看到哪个堆占用的内存更高。

从内存记录中，发现 array 对象占用最大，展开后发现，第一个​​object elements​​占用最大，选择这个 object elements 后可以在下面看到​​newArr​​变量，然后点击后面的高亮链接，就可以跳转到​​newArr​​附近。

深入了解OOM

对于Java来说，内存泄漏就是new出来的对象放在Heap上无法被垃圾收集器回收，占据内存，导致内存越来越小进而程序崩溃。说到内存泄漏，不得不提另外一个易混淆的概念：内存溢出（OOM）。什么是内存溢出呢？内存溢出是指程序向系统请求分配的空间超出了系统能给的。比如一辆车只能坐10个人，但是硬塞了15个人上去，就会挤爆了。大量的内存泄漏会导致内存溢出。

一、Java内存

说到内存，我们就来稍微了解下JVM内存。JVM内存分为method、stack、heap。

1）method：方法区，也叫静态区，主要是存放一些静态数据和常量，在编译时就分配好，在程序整个运行期间都存在，被所有线程共享；

2）stack：栈区，主要存放基本数据类型和对象的引用（不是对象本身），遵循先进后出的原则，当方法执行时，会在栈区内存中创建方法体中的局部变量，方法执行完毕自动释放内存；

3）heap：堆区，主要存放new出来的对象和数组，存储的是对象本身。JVM中只有一个堆区被所有线程共享，由JVM的垃圾回收器自动管理。

二、内存泄漏分析

了解了Java的内存分配，那么到底是哪里的内存会导致内存泄漏呢？

在JAVA中JVM的栈记录了方法的调用，每个线程拥有一个栈。在线程的运行过程当中，执行到一个新的方法调用，就在栈中增加一个内存单元，即帧(frame)。在frame中，保存有该方法调用的参数、局部变量和返回地址。然而JAVA中的局部变量只能是基本类型变量(int)，或者对象的引用。所以在栈中只存放基本类型变量和对象的引用。引用的对象保存在堆中。

当某方法运行结束时，该方法对应的frame将会从栈中删除，frame中所有局部变量和参数所占有的空间也随之释放。线程回到原方法继续执行，当所有的栈都清空的时候，程序也就随之运行结束。

而对于堆内存，堆存放着普通变量。在JAVA中堆内存不会随着方法的结束而清空，所以在方法中定义了局部变量，在方法结束后变量依然存活在堆中。

综上所述，栈(stack)可以自行清除不用的内存空间，Java的垃圾回收（简称GC)可以自动清空堆中不再使用的对象。在JAVA中对象是通过引用使用的。如果再没有引用指向该对象，那么该对象就无从处理或调用该对象，这样的对象称为不可到达，GC会将其回收，释放其所占的内存空间。实现的思想如下：

 1、栈中存放对象的引用，遍历栈，根据引用找到堆中对应的对象；

 2、因为栈中的对象的引用执行完毕就删除了，所以根据栈中的引用，在堆中找不到的这些对象就是不可到达的，对其进行垃圾回收。

如果持有对象的强引用，那么GC是没有办法在内存中将该对象释放的，从而导致内存泄漏。那么问题来了，其他的引用类型是否会被GC回收呢?

三、引用类型

1. 强引用(Strong reference)
实际编码中最常见的一种引用类型。常见形式如：A a = new A();等。强引用本身存储在栈内存中，其存储指向堆内存中对象的地址。一般情况下，当对内存中的对象不再有任何强引用指向它时，垃圾回收机器开始考虑可能要对此内存进行的垃圾回收。如当进行编码：a = null，此时，刚刚在堆中分配地址并新建的a对象没有其他的任何引用，当系统进行垃圾回收时，堆内存将被垃圾回收。

2. 软引用(Soft Reference)
软引用的一般使用形式如下：

A a = new A();
SoftReference<A> srA = new SoftReference<A>(a);

软引用所指示的对象进行垃圾回收需要满足如下两个条件：
1.当其指示的对象没有任何强引用对象指向它；
2.当虚拟机内存不足时。
因此，SoftReference变相的延长了其指示对象占据堆内存的时间，直到虚拟机内存不足时垃圾回收器才回收此堆内存空间。

3. 弱引用(Weak Reference)
同样的，软引用的一般使用形式如下：

A a = new A();
WeakReference<A> wrA = new WeakReference<A>(a);

WeakReference不改变原有强引用对象的垃圾回收时机，一旦其指示对象没有任何强引用对象时，此对象即进入正常的垃圾回收流程。

4. 虚引用(Phantom Reference)
与SoftReference或WeakReference相比，PhantomReference主要差别体现在如下几点：
1.PhantomReference只有一个构造函数

PhantomReference(T referent, ReferenceQueue<? super T> q)

2.不管有无强引用指向PhantomReference的指示对象，PhantomReference的get()方法返回结果都是null。

因此，PhantomReference使用必须结合ReferenceQueue；
与WeakReference相同，PhantomReference并不会改变其指示对象的垃圾回收时机。

四、内存泄漏的场景

1）永远的Singleton

       单例的使用在我们的程序中随处可见，因为使用它可以完美的解决我们在程序中重复创建对象的问题，不过可别小瞧它。由于单例的静态特性，使得它的生命周期和应用的生命周期会一样长，所以一旦使用有误，小心无限制的持有Activity的引用而导致内存泄漏。比如，下面的例子。

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2 
 3 import android.content.Context;
 4 
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:27
10  */
11 public class SingletonBad {
12     private static SingletonBad singletonBad;
13     private Context context;
14 
15     private SingletonBad(Context context){
16         this.context = context;
17     }
18 
19     public static SingletonBad getInstance(Context context){
20         if (singletonBad == null){
21             singletonBad = new SingletonBad(context);
22         }
23         return singletonBad;
24     }
25 }

这个错误在生活中再普遍不过，很正常的一个单例模式，可就由于传入的是一个Context，而这个Context的生命周期的长短就尤为重要了。如果我们传入的是Activity的Context，当这个Context所对应的Activity退出的时候，由于该Context的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前Activity退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。

正确的方式应该是把传入的Context换为和应用的生命周期一样长的Application的Context;

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2 
 3 import android.content.Context;
 4 
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:29
10  */
11 public class SingletonGood {
12     private static SingletonGood singletonGood;
13     private Context context;
14 
15     private SingletonGood(Context context){
16         this.context = context.getApplicationContext();//获取Application的context避免内存泄漏
17     }
18 
19     public static SingletonGood getInstance(Context context){
20         if (singletonGood == null){
21             singletonGood = new SingletonGood(context);
22         }
23         return singletonGood;
24     }
25 }

当然，你也可以直接连Context都不用传入了。重写application，提供静态的getContext方法

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2 
 3 import android.app.Application;
 4 import android.content.Context;
 5 
 6 /**
 7  * @author nanchen
 8  * @fileName ANRSolutionDemo
 9  * @packageName com.example.nanchen.anrsolutiondemo.singleton
10  * @date 2016/09/23  11:32
11  */
12 public class DemoApplication extends Application {
13     private static DemoApplication demoApplication;
14 
15     public static DemoApplication getInstance(){
16         return demoApplication;
17     }
18 
19     public static Context getContext(){
20         return demoApplication.getApplicationContext();
21     }
22 
23     @Override
24     public void onCreate() {
25         super.onCreate();
26         demoApplication = this;
27     }
28 }

自然就可以直接不用传入Context

 1 package com.example.nanchen.anrsolutiondemo.singleton;
 2 
 3 import android.content.Context;
 4 
 5 /**
 6  * @author nanchen
 7  * @fileName ANRSolutionDemo
 8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
 9  * @date 2016/09/23  11:32
10  */
11 public class SingletonGoodNew {
12     private static SingletonGoodNew singletonGoodNew;
13 
14     private Context context;
15     
16     private SingletonGoodNew(){
17         this.context = DemoApplication.getContext();
18     }
19 
20     public static SingletonGoodNew getInstance(){
21         if (singletonGoodNew == null){
22             singletonGoodNew = new SingletonGoodNew();
23         }
24         return singletonGoodNew;
25     }
26 }

 

 

2）令人心塞的Handler

       这个东西在我最近遇到的最多了，而它也是我们在内存泄漏中最为常见的，也许你的一个小忽略就会导致内存泄漏。在android的新版本中，我们被要求必须把网络任务等耗时操作置于新线程来处理，我们通常会采用Handler。但Handler不是万能的，若是我们的编写不规范就有可能会造成内存泄漏。另外，我们知道，Handler、Message和MessageQueue都是相互关联在一起的，万一Handler发送的Message尚未被处理，则该Message及发送它的Handler对象将会被线程MessageQueue一直持有。

       由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟View或者Activity的生命周期一致，故很容易导致无法正确释放。比如：

 1 package com.example.nanchen.anrsolutiondemo.handler;
 2 
 3 import android.os.Bundle;
 4 import android.os.Handler;
 5 import android.os.Message;
 6 import android.support.v7.app.AppCompatActivity;
 7 
 8 import com.example.nanchen.anrsolutiondemo.R;
 9 
10 public class HandlerBadActivity extends AppCompatActivity {
11 
12     private final Handler handler = new Handler(){
13         @Override
14         public void handleMessage(Message msg) {
15             super.handleMessage(msg);
16         }
17     };
18 
19     @Override
20     protected void onCreate(Bundle savedInstanceState) {
21         super.onCreate(savedInstanceState);
22         setContentView(R.layout.activity_handler_bad);
23 
24         // 延迟10s发送一个消息
25         handler.postDelayed(new Runnable() {
26             @Override
27             public void run() {
28                 // write something
29             }
30         },1000*60*5);
31 
32         this.finish();
33     }
34 }

在例子中，我们申明了一个延迟5分钟执行的消息Message。当该Activity被finish的时候，延迟任务的Message还存在于主线程中，它持有该Activity的Handler引用，所以此时Finish掉的Activity就不会回收了，所以造成了内存泄漏（因handler为非静态内部类，它会持有外部类的引用，在这里就是当前的Activity）。

修复：这个解决也是可以通过把其声明为static的，则其存活期就跟activity的生命周期无关了。不过倘若用到Context等外部类的非static对象，还是应该通过弱引用传入。比如：

 1 package com.example.nanchen.anrsolutiondemo.handler;
 2 
 3 import android.os.Bundle;
 4 import android.os.Handler;
 5 import android.os.Message;
 6 import android.support.v7.app.AppCompatActivity;
 7 
 8 import com.example.nanchen.anrsolutiondemo.R;
 9 
10 import java.lang.ref.WeakReference;
11 
12 public class HandlerGoodActivity extends AppCompatActivity {
13 
14     private static final class MyHandler extends Handler{
15         private final WeakReference<HandlerGoodActivity> mActivity;
16 
17         public MyHandler(HandlerGoodActivity activity){
18             this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
19         }
20 
21         @Override
22         public void handleMessage(Message msg) {
23             super.handleMessage(msg);
24             HandlerGoodActivity activity = mActivity.get();
25             if (activity != null){
26                 // write something
27             }
28         }
29     }
30 
31     private final MyHandler myHandler = new MyHandler(this);
32 
33     // 匿名内部类在static的时候绝对不会持有外部类的引用
34     private static final Runnable RUNNABLE = new Runnable() {
35         @Override
36         public void run() {
37 
38         }
39     };
40 
41     @Override
42     protected void onCreate(Bundle savedInstanceState) {
43         super.onCreate(savedInstanceState);
44         setContentView(R.layout.activity_handler_good);
45 
46         myHandler.postDelayed(RUNNABLE,1000*60*5);
47     }
48 }

综述：推荐使用静态内部类+弱引用WeakReference这种方式，但要注意每次使用前判空。

说到若引用，这里再提下java的几种引用类型：Strong reference,SoftReference,WeakReference和PhatomReference

在android开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用软引用和弱引用技术。

比如，保存Bitmap的软引用到HashMap。

 1 package com.example.nanchen.anrsolutiondemo.photo;
 2 
 3 import android.graphics.Bitmap;
 4 import android.graphics.BitmapFactory;
 5 
 6 import java.lang.ref.SoftReference;
 7 import java.util.HashMap;
 8 
 9 /**
10  * @author nanchen
11  * @fileName ANRSolutionDemo
12  * @packageName com.example.nanchen.anrsolutiondemo.photo
13  * @date 2016/09/23  11:58
14  */
15 public class CacheBySoftRef {
16 
17     // 首先定义一个HashMap,保存软应用对象
18     private HashMap<String,SoftReference<Bitmap>> imageCache =  new HashMap<>();
19     // 再来定义一个方法，保存Bitmap的软引用到HashMap
20     public void addBitmapToCache(String path){
21         // 强引用的Bitmap对象
22         Bitmap bitmap = BitmapFactory.decodeFile(path);
23         // 软引用的Bitmap对象
24         SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
25         // 添加该对象到Map使其缓存
26         imageCache.put(path,softBitmap);
27     }
28 
29     // 获取的时候，可以通过SoftReference的get()的方法得到Bitmap对象
30     public Bitmap getBitmapByPath(String path){
31         // 从缓存中取软引用的Bitmap对象
32         SoftReference<Bitmap> softBitmap = imageCache.get(path);
33         // 判断是否存在软引用
34         if (softBitmap == null){
35             return null;
36         }
37         // 通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，则取得空；
38         // 如果未被回收，则可重复使用，提高速度
39         Bitmap bitmap = softBitmap.get();
40         return bitmap;
41     }
42 }

使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。

如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。

另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。

ok，继续回到主题。前面所说的，创建一个静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

下面几个方法都可以移除 Message：

 

 

3）匿名内部类/非静态内部类，它们方便却暗藏杀机

       android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的

 1 package com.example.nanchen.anrsolutiondemo.innerClass;
 2 
 3 import android.os.Bundle;
 4 import android.support.v7.app.AppCompatActivity;
 5 
 6 import com.example.nanchen.anrsolutiondemo.R;
 7 
 8 public class MainActivity extends AppCompatActivity {
 9 
10     private static TestInnerBad testInnerBad = null;
11 
12     class TestInnerBad{
13 
14     }
15 
16     @Override
17     protected void onCreate(Bundle savedInstanceState) {
18         super.onCreate(savedInstanceState);
19         setContentView(R.layout.activity_inner_bad);
20 
21         if (testInnerBad == null){
22             testInnerBad = new TestInnerBad();
23         }
24 
25         Runnable runnable1 = new MyRunnable();
26         Runnable runnable2 = new Runnable() {
27             @Override
28             public void run() {
29 
30             }
31         };
32     }
33 
34     private static class MyRunnable implements Runnable{
35 
36         @Override
37         public void run() {
38 
39         }
40     }
41 
42 }

runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存

可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。

 

4）前辈箴言——善用static成员变量

      前面就很明显，当我们的成员变量是static的时候，那么它的生命周期将和整个app的生命周期一致。

      这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。

这里修复的方法是：

不要在类初始时初始化静态成员。可以考虑lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。

 

5）远离非静态内部类和匿名类，多用private static class。

      在我们的日常代码中，这样的情况似乎很常见，及直接写一个class就这么光秃秃的情况。

      

　　　

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

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，请按照上面推荐的使用Application 的 Context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的Context的应用场景如下：

其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建

 

6） 集合对象善清除，以免内存泄漏触不及防

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

　　所以在退出程序之前，将集合里面的东西clear，然后置为null，再退出程序，如下：

 1 private List<String> nameList;
 2     private List<Fragment> list;
 3 
 4     @Override
 5     public void onDestroy() {
 6         super.onDestroy();
 7         if (nameList != null){
 8             nameList.clear();
 9             nameList = null;
10         }
11         if (list != null){
12             list.clear();
13             list = null;
14         }
15     }

 

 7）webView虽火，内存泄漏却也火的其所

　　当我们不再需要使用webView的时候，应该调用它的destory()方法来销毁它，并释放其占用的内存，否则其占用的内存长期也不能回收，从而造成内存泄漏。

　　解决方案：

　　　　为webView开启另外一个进程，通过AIDL与主线程进行通信，webView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

　　而另外一些诸如listView的Adapter没有缓存之类的这里就不再多提了。

8）做一个小的总结

• 构造Adapter时，没有使用缓存的 convertView
• Bitmap对象不在使用时调用recycle()释放内存
• Context使用不当造成内存泄露：不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
• 非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
• 警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
• 对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
• 创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
• 不要在执行频率很高的方法或者循环中创建对象（比如onmeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
• 避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。

五、内存泄漏检测工具

MAT(Memory Analyzer Tool)：点我下载~

强大的开源内存检测工具LeakCanary：官方文档

 

参考链接：

Android内存泄漏的八种可能（上）

[译]Android防止内存泄漏的八种方法（下）