Javascript内存泄漏

最近在面试的过程中，面试官问到关于javascript中的内存泄漏问题。我当时只能想到“垃圾回收机制”和ES6中新增的weakSet等，至于内存泄漏一些的原理性问题没能很好的回答，原因当然是我自己本人对这块的知识也不是很清楚。回去的路上一直在百度和查文档，发现阮一峰大牛对javascript内存泄漏这块讲的很详细。所以站在巨人的肩膀上，在这里转载了阮大牛的技术文章，以供大家和自己学习。
原文地址：http://www.ruanyifeng.com/blog/2017/04/memory-leak.html

一、什么是内存泄漏？

程序的运行需要内存。只要程序提出要求，操作系统或者运行时（runtime）就必须供给内存。
对于持续运行的服务进程（daemon），必须及时释放不再用到的内存。否则，内存占用越来越高，轻则影响系统性能，重则导致进程崩溃。

不再用到的内存，没有及时释放，就叫做内存泄漏（memory leak）。
有些语言（比如 C 语言）必须手动释放内存，程序员负责内存管理。

char * buffer;
buffer = (char*) malloc(42);

// Do something with buffer

free(buffer);
上面是 C 语言代码，malloc方法用来申请内存，使用完毕之后，必须自己用free方法释放内存。
这很麻烦，所以大多数语言提供自动内存管理，减轻程序员的负担，这被称为”垃圾回收机制”（garbage collector）。

二、垃圾回收机制

垃圾回收机制怎么知道，哪些内存不再需要呢？
最常使用的方法叫做”引用计数”（reference counting）：语言引擎有一张”引用表”，保存了内存里面所有的资源（通常是各种值）的引用次数。如果一个值的引用次数是0，就表示这个值不再用到了，因此可以将这块内存释放。

上图中，左下角的两个值，没有任何引用，所以可以释放。
如果一个值不再需要了，引用数却不为0，垃圾回收机制无法释放这块内存，从而导致内存泄漏。

const arr = [1, 2, 3, 4];
console.log(‘hello world’);
上面代码中，数组[1, 2, 3, 4]是一个值，会占用内存。变量arr是仅有的对这个值的引用，因此引用次数为1。尽管后面的代码没有用到arr，它还是会持续占用内存。
如果增加一行代码，解除arr对[1, 2, 3, 4]引用，这块内存就可以被垃圾回收机制释放了。

let arr = [1, 2, 3, 4];
console.log(‘hello world’);
arr = null;
上面代码中，arr重置为null，就解除了对[1, 2, 3, 4]的引用，引用次数变成了0，内存就可以释放出来了。
因此，并不是说有了垃圾回收机制，程序员就轻松了。你还是需要关注内存占用：那些很占空间的值，一旦不再用到，你必须检查是否还存在对它们的引用。如果是的话，就必须手动解除引用。

三、内存泄漏的识别方法

怎样可以观察到内存泄漏呢？
经验法则是，如果连续五次垃圾回收之后，内存占用一次比一次大，就有内存泄漏。这就要求实时查看内存占用。
3.1 浏览器
Chrome 浏览器查看内存占用，按照以下步骤操作。

打开开发者工具，选择 Timeline 面板
在顶部的Capture字段里面勾选 Memory
点击左上角的录制按钮。
在页面上进行各种操作，模拟用户的使用情况。
一段时间后，点击对话框的 stop 按钮，面板上就会显示这段时间的内存占用情况。
如果内存占用基本平稳，接近水平，就说明不存在内存泄漏。

反之，就是内存泄漏了。

3.2 命令行
命令行可以使用 Node 提供的process.memoryUsage方法。

console.log(process.memoryUsage());
// { rss: 27709440,
// heapTotal: 5685248,
// heapUsed: 3449392,
// external: 8772 }
process.memoryUsage返回一个对象，包含了 Node 进程的内存占用信息。该对象包含四个字段，单位是字节，含义如下。

rss（resident set size）：所有内存占用，包括指令区和堆栈。
heapTotal：”堆”占用的内存，包括用到的和没用到的。
heapUsed：用到的堆的部分。
external： V8 引擎内部的 C++ 对象占用的内存。
判断内存泄漏，以heapUsed字段为准。

四、WeakMap

前面说过，及时清除引用非常重要。但是，你不可能记得那么多，有时候一疏忽就忘了，所以才有那么多内存泄漏。
最好能有一种方法，在新建引用的时候就声明，哪些引用必须手动清除，哪些引用可以忽略不计，当其他引用消失以后，垃圾回收机制就可以释放内存。这样就能大大减轻程序员的负担，你只要清除主要引用就可以了。
ES6 考虑到了这一点，推出了两种新的数据结构：WeakSet 和 WeakMap。它们对于值的引用都是不计入垃圾回收机制的，所以名字里面才会有一个”Weak”，表示这是弱引用。

下面以 WeakMap 为例，看看它是怎么解决内存泄漏的。

const wm = new WeakMap();

const element = document.getElementById(‘example’);

wm.set(element, ‘some information’);
wm.get(element) // “some information”
上面代码中，先新建一个 Weakmap 实例。然后，将一个 DOM 节点作为键名存入该实例，并将一些附加信息作为键值，一起存放在 WeakMap 里面。这时，WeakMap 里面对element的引用就是弱引用，不会被计入垃圾回收机制。
也就是说，DOM 节点对象的引用计数是1，而不是2。这时，一旦消除对该节点的引用，它占用的内存就会被垃圾回收机制释放。Weakmap 保存的这个键值对，也会自动消失。
基本上，如果你要往对象上添加数据，又不想干扰垃圾回收机制，就可以使用 WeakMap。

五、WeakMap 示例

WeakMap 的例子很难演示，因为无法观察它里面的引用会自动消失。此时，其他引用都解除了，已经没有引用指向 WeakMap 的键名了，导致无法证实那个键名是不是存在。
我一直想不出办法，直到有一天贺师俊老师提示，如果引用所指向的值占用特别多的内存，就可以通过process.memoryUsage方法看出来。
根据这个思路，网友 vtxf 补充了下面的例子。
首先，打开 Node 命令行。

$ node –expose-gc
上面代码中，–expose-gc参数表示允许手动执行垃圾回收机制。
然后，执行下面的代码。

// 手动执行一次垃圾回收，保证获取的内存使用状态准确> global.gc(); undefined// 查看内存占用的初始状态，heapUsed 为 4M 左右> process.memoryUsage(); { rss: 21106688,  heapTotal: 7376896,  heapUsed: 4153936,  external: 9059 }> let wm = new WeakMap();undefined> let b = new Object();undefined> global.gc();undefined// 此时，heapUsed 仍然为 4M 左右> process.memoryUsage(); { rss: 20537344,  heapTotal: 9474048,  heapUsed: 3967272,  external: 8993 }// 在 WeakMap 中添加一个键值对，// 键名为对象 b，键值为一个 5*1024*1024 的数组  > wm.set(b, new Array(5*1024*1024));WeakMap {}// 手动执行一次垃圾回收> global.gc();undefined// 此时，heapUsed 为 45M 左右> process.memoryUsage(); { rss: 62652416,  heapTotal: 51437568,  heapUsed: 45911664,  external: 8951 }// 解除对象 b 的引用  > b = null;null// 再次执行垃圾回收> global.gc();undefined// 解除 b 的引用以后，heapUsed 变回 4M 左右// 说明 WeakMap 中的那个长度为 5*1024*1024 的数组被销毁了> process.memoryUsage(); { rss: 20639744,  heapTotal: 8425472,  heapUsed: 3979792,  external: 8956 }  

上面代码中，只要外部的引用消失，WeakMap 内部的引用，就会自动被垃圾回收清除。由此可见，有了它的帮助，解决内存泄漏就会简单很多。

六、3种常见的JavaScript泄漏

1.意外的全局变量

JavaScript的目标是开发一种看起来像Java但足够自由的被初学者使用的语言。JavaScript自由的其中一种方式是它可以处理没有声明的变量：一个未声明的变量的引用在全局对象中创建了一个新变量。在浏览器的环境中，全局对象是window。也就是说：

function foo(arg) {
bar = “this is a hidden global variable”;
}
实际上是：

function foo(arg) {
window.bar = “this is an explicit global variable”;
}
如果bar是仅在foo函数作用域内承载引用，并且你忘记用var来声明的变量，一个意外的全局变量就被创建了。在这个例子中，泄漏一个单一字符串不会有太大害处，但这的确是不好的。
另一种意外全局变量被创建的方式是通过this：

function foo() {
this.variable = “potential accidental global”;
}
// Foo called on its own, this points to the global object (window)
// rather than being undefined.
foo();
为了阻止这种错误发生，在你的Javascript文件最前面添加’use strict;’。这开启了解析JavaScript的阻止意外全局的更严格的模式。

全局变量的一个注意事项：

即使我们谈了不明的全局变量，仍然存在很多代码被显式的全局变量填充的情况。这是通过定义不可收集的情况（除非清零或重新赋值）。特别的，用来临时存储和处理大量信息的全局变量会引起关注。如果必须用全局变量来存储很多数据，在处理完之后，确保对其清零或重新赋值。 一个在与全局连接上增加内存消耗常见的原因是缓存)。 缓存存储重复被使用的数据。为此，为了有效，缓存必须有其大小的上限。飙出限制的缓存可能会因为内容不可被回收，导致高内存消耗。

2.被遗忘的计时器或回调

在JavaScript中setInterval的使用相当常见。其他库提供观察者和其他工具以回调。这些库中大多数，在引用的实例变成不可访问之后，负责让回调的任何引用也不可访问。在setInterval的情况下，这样的代码很常见：

var someResource = getData();
setInterval(function() {
var node = document.getElementById(‘Node’);
if(node) {
// Do stuff with node and someResource.
node.innerHTML = JSON.stringify(someResource));
}
}, 1000);
这个例子表明了跳动的计时器可能发生什么：计时器使得节点或数据的引用不再被需要了。代表node的对象将来可能被移除，使得整个块在间隔中的处理不必要。然而，处理函数，由于间隔仍然是活跃的，不能被回收（间隔需要被停掉才能回收）。如果间隔处理不能被回收，它的依赖也不能被回收。那意味着可能存储着大量数据的someResource，也不能被回收。
观察者情况下，一旦不被需要（或相关的对象快要访问不到）就创建明确移除他们的函数很重要。在过去，这由于特定浏览器（IE6）不能很好的管理循环引用（下面有更多相关信息），曾经尤为重要。现如今，一旦观察对象变成不可访问的，即使收听者没有明确的被移除，多数浏览器可以并会回收观察者处理函数。然而，它保持了在对象被处理前明确的移除这些观察者的好实践。例如：

var element = document.getElementById(‘button’);
function onClick(event) {
element.innerHtml = ‘text’;
}
element.addEventListener(‘click’, onClick);
// Do stuff
element.removeEventListener(‘click’, onClick);
element.parentNode.removeChild(element);
// Now when element goes out of scope,
// both element and onClick will be collected even in old browsers that don’t
// handle cycles well.
一条关于对象观察者及循环引用的笔记

观察者和循环引用曾经是JavaScript开发者的祸患。这是由于IE垃圾回收的一个bug(或者设计决议)出现的情况。IE的老版本不能检测到DOM节点和JavaScript代码间的循环引用。 这是一个通常为观察到的保留引用（如同上面的例子）的观察者的典型。 也就是说，每次在IE中对一个节点添加观察者的时候，会导致泄漏。这是开发者在节点或空引用之前开始明确的移除处理函数的原因。 现在，现代浏览器（包括IE和MS Edge）使用可以剪裁这些循环和正确处理的现代垃圾回收算法。换言之，在使一个节点不可访问前，调用removeEventLister不是严格意义上必须的。

像Jquery一样的框架和库做了在处置一个节点前（当为其使用特定的API的时候）移除监听者的工作。这被在库内部处理，即使在像老版本IE一样有问题的浏览器里面跑，也会确保没有泄漏产生。

3. 超出DOM引用

有时存储DOM节点到数据结构中可能有用。假设你想要迅速的更新一个表格几行内容。存储每个DOM行节点的引用到一个字典或数组会起作用。当这发生是，两个对于同个DOM元素的引用被留存：一个在DOM树中，另外一个在字典中。如果在将来的某些点你决定要移除这些行，需要让两个引用都不可用。

var elements = {
button: document.getElementById(‘button’),
image: document.getElementById(‘image’),
text: document.getElementById(‘text’)
};
function doStuff() {
image.src = ‘http://some.url/image‘;
button.click();
console.log(text.innerHTML);
// Much more logic
}
function removeButton() {
// The button is a direct child of body.
document.body.removeChild(document.getElementById(‘button’));
// At this point, we still have a reference to #button in the global
// elements dictionary. In other words, the button element is still in
// memory and cannot be collected by the GC.
}
对此的额外考虑，必须处理DOM树内的内部节点或叶子节点。假设你在JavaScript代码中保留了一个对于特定的表格内节点（一个td标签）的引用。在将来的某个点决定从DOM中移除这个表格，但是保留对于那个节点的引用。直观的，会假设GC会回收除那个节点之外的每个节点。在实践中，这不会发生的：这个单节点是那个表格的子节点，子节点保留对父节点引用。换句话说，来自JavaScript代码的表格元素的引用会引起在内存里存整个表格。当保留DOM元素的引用的时候，仔细考虑下。

4.闭包

一个JavaScript开发的关键点是闭包：从父级作用域捕获变量的匿名函数。很多开发者发现，由于JavaScript runtime的实现细节，有以一种微妙的方式泄漏的可能，这种特殊的情况：

var theThing = null;
var replaceThing = function () {
var originalThing = theThing;
var unused = function () {
if (originalThing)
console.log(“hi”);
};
theThing = {
longStr: new Array(1000000).join(‘*’),
someMethod: function () {
console.log(someMessage);
}
};
};
setInterval(replaceThing, 1000);
这个代码片段做了一件事：每次replaceThing被调用的时候，theThing获取到一个包括一个大数组和新闭包(somMethod)的新对象。同时，变量unused保留了一个有originalThing（theThing从之前的对replaceThing的调用）引用的闭包。已经有点疑惑了，哈？重要的是一旦一个作用域被在同个父作用域下的闭包创建，那个作用域是共享的。这种情况下，为闭包somMethod创建的作用域被unused共享了。unused有一个对originalThing的引用。即使unused从来没被用过，someMethod可以通过theTing被使用。由于someMethod和unused共享了闭包作用域，即使unused从来没被用过，它对originalThing的引用迫使它停留在活跃状态（不能回收）。当这个代码片段重复运行的时候，可以看到内存使用稳步的增长。GC运行的时候，这并不会减轻。本质上，一组关联的闭包被创建（同unused变量在表单中的根节点一起），这些闭包作用域中每个带了大数组一个非直接的引用，导致了大型的泄漏。

这是一个实现构件。一个可以处理这关系的闭包的不同实现是可以想象的，就如在这篇博客中解释的一样。

垃圾回收的直观行为
即使垃圾回收很方便，他们有自己的一套权衡方法。其中一个权衡是nondeterminism。也就是说，GC是不可预期的。通常不能确定什么时候回收器被执行。这意味着在一些情况下，需要比程序正在使用的更多的内存。其他情况下，短的暂停在特别敏感的应用中很明显。即使不确定性意味着不能确定回收什么时候执行，大多数GC实现共享在分配期间，普通的回收通行证模式。如果没有执行分配，大多数CG停留在休息状态。考虑下面的方案：

1.执行一组大型的分配。

2.多数元素（或所有）被标记为不可访问（假设我们置空了一个指向不再需要的缓存的引用）。

3.没有进一步的分配执行了。

在这个方案中，大多GC不会运行任何进一步的回收通行了。换言之，即使有可用于回收的，不可访问的引用，回收器不会要求他了。这不是严格的泄漏，但是也会导致比平常更高的内存使用率。
Google在 JavaScript Memory Profiling docs, example #2.文章中，提供了一个优秀的例子。
原文地址：http://blog.csdn.net/web_lc/article/details/72920029

七、参考链接

• Simple Guide to Finding a JavaScript Memory Leak in Node.js
• Understanding Garbage Collection and hunting Memory Leaks in Node.js
• Debugging Memory Leaks in Node.js Applications