精读《JS中的内存管理》

JS中的内存管理，感觉就像JS中的一门副科，我们平时不太会忠实，但是一旦出现问题又很棘手，所以可以通过平时的多了解一些JS中的内存管理问题，在写代码中通过一些平时养成的习惯，避免内存泄露的问题。

不管什么语言，内存生命周期基本一致：

1、分配内存；

2、使用分配的内存（读、写）；

3、不需要的时候再释放内存。

C语言中，有专门的内存管理接口，像malloc（）和free（）。JS中没有专门的内存管理接口，所有的内存管理都是自动的。JS创建变量是，自动分配内存，并在不使用的时候，自动释放该内存。这种自动的内存回收，造成了很多JS开发者并不关心内存回收问题，实际上，这会造成许多错误。

关于JS内存回收：

1、引用：

垃圾回收算法主要依赖于引用的概念，在内存管理环境中，一个对象如果有访问另一个对象的权限（隐式或显示），叫做一个对象引用另一个对象。例如：一个JavaScript对象具有对它模型的引用（隐式引用）和对它属性的引用（显示引用）

2、引用计数垃圾收集：

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

示例：

let arr = [1,2,3];

arr = null;//[1,2,3]这时候没有被引用，会被自动回收

3：限制：循环使用：

在接下来的例子中，两个对象被创建并相互引用，就造成了循环引用。它们被调用之后不会离开函数作用域，所以它们已经没有用了，可以被回收了，然而，引用计数算法考虑到它们互相都有至少一次引用，所以不会被回收。

示例：

function f(){

var x = {};

var y = {};

x.p = y;//x引用y

y.p = x;//y引用x

//这里就形成了一个循环引用

}

f();

实际的例子：

var div;

window.onload = function(){

div = document.getElementById("myId");

div.circularReference = div;

div.lotsOfData = new Array(10000).join("*");

};

这个例子中，myId这个DOM元素里的circularReference属性引用了myId，造成了循环引用，IE6,7使用引用计数方式对DOM对象进行垃圾回收，该方式常常造成对象引用时内存发生泄漏。主流浏览器通过使用标记-清除 内存回收算法，来解决这一问题。

4：标记-清除算法

这个算法把“对象是否不再需要”简化定义为“对象是否可以获得”。

这个算法鉴定设置一个叫根root的对象（JS中，根是全局对象）。定期的，垃圾回收器将从根开始。找所有从根开始饮用的对象，然后找到这些对象引用的对面，从根开始，垃圾回收器将找到所有可以获得的对象和所有不能获得的对象。

从2012年起，所有的主流浏览器都使用了标记-清除内存回收算法。所有对JS垃圾回收算法的改进都基于该算法。

5：什么事内存泄露？

本质上讲，内存泄露就是不在被需要的内存，由于某种原因，无法被释放。

6：常见的内存泄露案例：

1：全局变量：

function foo(arg){

bar = "xx";

}

在JS中处理未被声明的变量，上述示例中的bar时，会把bar定义到全局对象中，在浏览器上也就是window上。在页面中的全局变量，只有当页面被关闭后才会被销毁。所以这种写法就会造成内存泄露，但让这个例子中泄露的只是一个简单的字符串，但是实际代码中，往往情况会更糟糕。

另外一种意外创建全局变量的情况：

function foo(){

this.varl = "xx";

}

foo();

foo被调用时，this指向全局变量window。意外的创建了全局变量，造成内存泄露。

我们谈到了一些意外情况下定义的全局变量，代码中也有一些我们明确定义的全局变量。如果使用这些全局变量来暂存大量的数据，记得在使用后，对其重新赋值为null。

2：未销毁的定时器和回调函数：

很多库中，如果使用了观察者模式，都会提供回调方法，来调用一些做后续处理的回调函数。要记得回收这些回调函数。

举一个setInterval的例子：

var serverData = loadData();

setInterval(function(){

var renderer = document.getElementById('renderer');

if(renderer){

renderer.innerHTML(JSON.stringify(serverData));

}

},5000);//5秒调用一次

如果后续renderer元素被溢出，整个定时器实际上没有任何作用，但是如果你不对其进行回收，整个定时器依然存在内存中，不但定时器无法被内存回收，定时器函数中的依赖也无法回收。在这个案例中的serverData也无法被回收。

3、闭包：

在JS开发中，我们会经常使用的闭包，一个内部函数，有权访问包含其的外部函数中的变量。

下面的这种情况，闭包也会造成内存泄露：

var theThing = null;

var replaceThing = function(){

var originalThing = theThing;

var unused = function(){

if(originalThing)//引用包含此函数的外部函数中的变量

console.log("x");

};

theThing = {

longStr:new Array(10000000).join('*'),

someMethod:function(){

console.log("y");

}

};

};

setInterval(replaceThing,1000);

这段代码，每次调用replaceThing时，theThing获得了包含一个巨大的数组和一个对于新闭包someMethod的对象。同时unused是一个引用了originalThing的闭包。

这个范例的关键在于，闭包之间是共享作用域的，尽管unused可能一直没有被调用，但是someMethod可能会被调用，就会导致内存无法对其进行回收，这段代码被反复执行时，内存会持续的增长！

该问题的更多描述课件Meteor团队的文章！

4、DOM引用：

很多时候我们对DOM进行操作，会把DON的引用保存到一个数组或Map中

var elments = {

image:document.getElementById("image");

};

function doStuff(){

elements.image.src = 'http://example.com/image_name.png';

}

function removeImage() {
    document.body.removeChild(document.getElementById('image'));
    // 这个时候我们对于 #image 仍然有一个引用, Image 元素, 仍然无法被内存回收. 
}
上述案例中, 即使我们对于 image 元素进行了移除, 但是仍然有对 image 元素的引用, 依然无法对齐进行内存回收.
另外需要注意的一个点是, 对于一个 Dom 树的叶子节点的引用. 举个例子: 如果我们引用了一个表格中的 td 元素, 一旦在 Dom 中删除了整个表格, 我们直观的觉得内存回收应该回收除了被引用的 td 外的其他元素. 但是事实上, 这个 td 元素是整个表格的一个子元素, 并保留对于其父元素的引用. 这就会导致对于整个表格, 都无法进行内存回收. 所以我们要小心处理对于 Dom 元素的引用.
精读：
ES6中引入 WeakSet 和 WeakMap 两个新的概念, 来解决引用造成的内存回收问题. WeakSet 和 WeakMap 对于值的引用可以忽略不计, 他们对于值的引用是弱引用,内存回收机制, 不会考虑这种引用. 当其他引用被消除后, 引用就会从内存中被释放.
JS 这类高级语言，隐藏了内存管理功能。但无论开发人员是否注意，内存管理都在那，所有编程语言最终要与操作系统打交道，在内存大小固定的硬件上工作。不幸的是，即使不考虑垃圾回收对性能的影响，2017 年最新的垃圾回收算法，也无法智能回收所有极端的情况。
唯有程序员自己才知道何时进行垃圾回收，而 JS 由于没有暴露显示内存管理接口，导致触发垃圾回收的代码看起来像“垃圾”，或者优化垃圾回收的代码段看起来不优雅、甚至不可读。
所以在 JS 这类高级语言中，有必要掌握基础内存分配原理，在对内存敏感的场景，比如 nodejs 代码做严格检查与优化。谨慎使用 dom 操作、主动删除没有业务意义的变量、避免提前优化、过度优化，在保证代码可读性的前提下，利用性能监控工具，通过调用栈定位问题代码。
同时对于如何利用 chrome调试工具, 分析内存泄露的方法和技巧. 可以参考WEB前端教程-精读《2017前端性能优化备忘录》
总结：
即便在 JS 中, 我们很少去直接去做内存管理. 但是我们在写代码的时候, 也要有内存管理的意识, 谨慎的处理可能会造成内存泄露的场景.


原文链接：https://juejin.im/entry/59f9331551882546b15bd2bd?utm_source=gold_browser_extension