9

在 JavaScript 中,由于垃圾回收是自动进行的,所以人们在编码时可能不太会注意这方面。但事实是,一些 webapp 在使用一段时间后,会出现卡顿的现象,特别是那些单页应用,包括 WebView 方式的手机 app 。这个现象在传统的“单击 - 刷新”类型的页面中并不明显,因为页面刷新之后,所有没有被回收的垃圾对象也会被清除,但是在单页应用中,如果没有手动去点浏览器的刷新按钮,那么就算是很小的内存泄露,随着页面停留时间的增长,累积的泄露会越来越多,在手机上的感觉就更明显了。

所以这里想讨论一下内存泄露是如何发生的,以及如何去避免。

开门见山,一般有两种方式的垃圾回收机制,一个是“引用计数”,当一个对象被引用的次数为 0 时,该对象就可以被回收;另一个是“标记清除”,当一个对象不能再被访问到时,对该对象进行标记,等下一轮 GC 事件发生时,这些对象就会被清除。从 2012 年起,所有的现代浏览器都是基于“标记清除”的回收算法,所以,如果需要兼容更早的浏览器,可能需要做更多的事。GC 的时机由 JS 引擎决定,需要知道的事,当 GC 进行时,主线程会被阻塞,这个时间可以通过 Chrome 的 Timeline 工具看到,最少也会超过 10 ms 吧。

Chrome DevTools - Timeline

在 Chrome 中可以很直观方便地看到垃圾回收事件的执行。打开 Chrome 的 Timeline,只需要勾选“Memory”就可以了,并且在左边的 View 中选中第二个。

图片描述

然后单击放大镜下面的圆点,这时候 Chrome 会开始记录内存分配、绘制等事件,等你打开一张页面,比如百度吧,再单击这个圆点(现在应该是红色的了),就会看到一条蓝色的折线。不同页面不一样,但几乎都会有一个突然下降的地方,比如下图中 1200 ms 左边的地方,单击它,就能在下方显示 GC 事件所用的时间,以及它回收了多少内存。

图片描述

如果你看到自己网站的这条蓝色折线是呈上升趋势,在不断的 GC 后,内存还是在上升,就极有可能是发生了内存泄露,需要排查一下代码。

引用计数

这里的问题在于“循环引用”,如果对象 a 的属性引用了 b,而 b 的属性引用了 a,由于引擎只有在变量的引用次数为 0 的情况下才会回收,这里 a 和 b 的引用次数至少有 1,所以就算它们所在的函数执行完了,这两个变量还是无法被回收掉。

function foo() {
  var a = {},
      b = {};
      
  a.attr = b;
  b.attr = a;
}

foo();

当 foo 函数执行很多次之后,就会有很多个无法被回收的 a 和 b 存在。

实际情况可能是这样的:

function foo() {
  var text = document.getElementById('input-text');

  text.onfocus = function() {
    text.value = '';
  }
}

foo();

意思是,当光标移到输入框时,清空原有的内容。考虑 text 变量和 foo 里面的匿名函数,text 的 onfocus 属性引用了匿名函数,而该匿名函数引用了 text 变量(循环了),所以当 foo 执行结束后,这两个对象由于引用次数大于 0 而无法被回收。

对于这种情况,只需要在 foo 的末尾对 text 变量置空就可以了。

text = null;

如果你用 Chrome 运行这个例子的话,会看到蓝线还是降到初始的高度了,因为 Chrome 是基于“标记清除”的算法来回收内存的,所以不会有“循环引用”的问题。

标记清除

对于标记清除,心中要想象一个树,每个页面都存在一个根,每当一个函数执行,就会生成一个节点。自然,嵌套的函数调用就会有子节点。一般情况下(没有闭包),当函数执行完时,内部的变量都是无法被其他代码访问的,所以它就被标记为“无法被访问”。GC 时,JS 引擎统一对所有这些状态的对象进行回收。

图片描述

介绍两个概念。Shallow Size,表示该对象本身占用的内存。Retained Size,表示释放该对象后能得到的内存大小。什么意思?比如上图绿色的 #3,这个绿色的面积就是 Shallow Size。释放 #3 后,#4 和 #5 也会被释放,所以 Retained Size 就是 #3、#4、#5 的总大小。

在“标记清除”算法中,难点是如何判断一个对象已经是“无法被访问”了。

DOM 片段

如果用树去分析垃圾回收,会发现其实我们需要做的事情很少,因为当一个函数执行完之后,它连带的对象都会被清除。就算有闭包,当引用该闭包的函数执行完时,这些闭包也同样会被标记。

那么在哪里会发生内存泄露呢?看这个例子。

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

btn.onclick = function() {
  var fragment = document.createElement('div');
}

它表示每单击一次按钮,就创建一个 <div>,它没有引用任何对象,但是回调结束之后,这个空的 <div> 是不会被回收的。

DOM 事件

var content = document.getElementById('content');
content.innerHTML = '<button id="button">click</button>';

var button = document.getElementById('button');
button.addEventListener('click', function() {});

content.innerHTML = '';

这段代码过后,虽然 <button> 从 DOM 中移除了,由于它的监听器还在,所以无法被 GC 回收。

要避免这种情况就是通过 removeEventListener 将回调函数去掉。

定时器

如果使用 setInterval,那么它引用到的变量的上下文会保留下来。

function foo() {
  var name  = 'tom',
      title = 'Hero';
      
  window.setInterval(function() {
    alert(name);
  }, 1000);
}

foo();

这里的情况时,每隔 1 秒弹框一次。第一,虽然只用到了 name,但 name 所在的上下文都无法被释放,包括 title 。第二,由于定时器一直在执行,所以这个上下文是不会被释放的。当然,有时候这是业务要求,也谈不上内存泄露了,只不过要注意的是,如果真的有没必要的定时器,请调用 clearInterval 把它去掉吧。

另一方面,你不用为了仅仅避免内存泄露对 setTimeout 调用 clearTimeout 。它是不会造成内存泄露的,除非是别的什么原因,比如说,在 setTimeout 中递归调用了当前定时器,这相当于模拟 setInterval,可以与 setInterval 做类似处理。

小结

在平时的一些开发过程中,我发现虽然在 Chrome 中发生了 GC 事件,并且内存也降得很低,如果用 Profile 工具 Take Heap Snapshot 的话,也不会觉得有内存泄露发生。但在手机上(WebView)的确会存在越用越卡的现象,这点可能要根据不同的环境来分析,但文中提到的关键两个地方就是:解除引用,以及解除监听的事件。

如果自己的代码中能做到这两点的话,可能卡顿是由别的问题引起的,而不是内存泄露。


名一
2.9k 声望522 粉丝