JavaScript中V8引擎内存问题

简介

V8 是谷歌开发的高性能 JavaScript 引擎，该引擎使用 C++ 开发。目前主要应用在 Google Chrome 浏览器和 node.js 当中。

V8 自带的高性能垃圾回收机制，使开发者能够专注于程序开发中，极大的提高开发者的编程效率。但是方便之余，也会出现一些对新手来说比较棘手的问题：进程内存暴涨，cpu 飙升，性能很差等。这个时候，了解 V8 的内存结构和垃圾回收机制、知道如何进行性能调优就很有必要。本文主要讲述 V8 的内存管理和垃圾回收，后面会用示例代码结合 Chrome 的开发者工具进行分析；最后介绍了阿里的 node.js 应用服务解决方案 alinode。

V8 内存构成

一个 V8 进程的内存通常由以下几个块构成：

新生代内存区（new space）大多数的对象都会被分配在这里，这个区域很小但是垃圾回收比较频繁；
老生代内存区（old space）
属于老生代，这里只保存原始数据对象，这些对象没有指向其他对象的指针；
大对象区（large object space）这里存放体积超越其他区大小的对象，每个对象有自己的内存，垃圾回收其不会移动大对象区；
代码区（code space）
代码对象，会被分配在这里。唯一拥有执行权限的内存；
map 区（map space）
存放 Cell 和 Map，每个区域都是存放相同大小的元素，结构简单。

内存构成可以用下图来表示：

其中带斜纹的是对应的内存块中未使用的内存空间。new space 通常很小（1~8M），它被分成了两部分，一部分叫做 inactive new space，一部分是激活状态，为啥会有激活和未激活之分的原因，下面会提到。old space 偏大，可能达几百兆。

V8 内存生命周期

假设代码中有一个对象 jerry ，这个对象从创建到被销毁，刚好走完了整个生命周期，通常会是这样一个过程：

这个对象被分配到了 new space；
随着程序的运行，new space 塞满了，gc 开始清理 new space 里的死对象，jerry 因为还处于活跃状态，所以没被清理出去；
gc 清理了两遍 new space，发现 jerry 依然还活跃着，就把 jerry 移动到了 old space；
随着程序的运行，old space 也塞满了，gc 开始清理 old space，这时候发现 jerry 已经没有被引用了，就把 jerry 给清理出去了。

第二步里，清理 new space 的过程叫做 Scavenge，这个过程采用了空间换时间的做法，用到了上面图中的 inactive new space，过程如下：

当活跃区满了之后，交换活跃区和非活跃区，交换后活跃区变空了；
将非活跃区的两次清理都没清理出去的对象移动到 old space；
将还没清理够两次的但是活跃状态的对象移动到活跃区。

第四步里，清理 old space 的过程叫做 Mark-sweep ，这块占用内存很大，所以没有使用 Scavenge，这个回收过程包含了若干次标记过程和清理过程：

标记从根（root）可达的对象为黑色；
遍历黑色对象的邻接对象，直到所有对象都标记为黑色；
循环标记若干次；
清理掉非黑色的对象。

简单来说，Mark-sweep 就是把从根节点无法获取到的对象清理掉了。

使用 Chrome 调优前端代码

注：本文截图里的 Chrome 版本为 Version 64.0.3282.140 (Official Build) (64-bit)

1. 查看内容构成

在控制台获取当前页面的堆内存快照（heap snapshot）：

为了便于观看，先在 console 里声明一个类并创建它的一些对象：

class Jane {
}

class Tom {
  constructor () {  this.jane = new Jane()
  }
}

Array(1000000)  .fill('')   .map(() => new Tom())

获取成功后，可以看到一个表格：

介绍一下几个关键的列：

Constructor：对象的类名；
Distance：对象到根的引用层级；
Objects Count：对象的数量；
Shallow Size：对象本身占用的内存，不包括引用的对象所占内存；
Retained Size：对象所占总内存，包含引用的其他对象所占内存；
Retainers：对象的引用层级关系。

shallow size 和 retained size 的区别可以用红框里的 Tom 和 Jane 更直观的展示：Tom 的 shallow 占了 32M，retained 占用了 56M，这是因为 retained 包括了引用的指针对应的内存大小，即 tom.jane 所占用的内存；所以 Tom 的 retained 总和比 shallow 多出来的 24M 正好跟 Jane 占用的 24M 相同。retained size 可以理解为当回收掉该对象时可以释放的内存大小，在内存调优中具有重要参考意义。

2. 查看对象的引用关系

这里使用一个稍复杂的代码来展示：

class B {}

class A {
  constructor () {
    this.b = new B()
  }
}

class BList {
  constructor () {
    this.values = []
  }
  push (b) {
    this.values.push(b)
  }
}

const aArray = Array(1000000).fill('').map(() => new A())
const bList = new BList()
aArray.forEach(a => { bList.push(a.b) })

heap snapshot 如下图所示：

红框中展示了该 B 实例被应用的三个位置，后面的 @?? 可以视为内存的地址，同样的地址意味着同一个对象。可以展开左边的箭头查看，这三个直接引用的地方分别是：

Blist.values 对应的指针；
A.b 对应的指针；
Blist.values 指向的数组的指针。

可以观察到，A 的 retained size 现在和 shallow size 一样了，因为 A 的实例在 aArray 中被引用了；B 的两个 size 也一样了，因为在 A 中和 bList 中都有引用，销毁其本身并不会释放相应的内存。

3. 调试内存泄露

如果你的网页在放久了的情况下内存越来越大甚至 tab 页崩溃，那就要考虑是否内存泄露了。通过 Chrome 的任务管理器可以看到 JavaScript 所占用的内存：

通过 Performance 里的 record 也可以直观地看到内存的增长（需要勾上 Memory 选项）：

用一个示例代码，结合 heap snapshot 来说明如何排查内存泄露：

const a = {}

setInterval(() => {
  a[Date.now()] = new ArrayBuffer(1000000)
}, 100)

这段代码粘贴在控制台后，在控制台的 Memory 页面，隔 10s 取一个 heap snapshot：

选中第二个和第三个，在选取观察类型的下拉菜单里选择「Comparison」，然后再选择右面的下拉菜单，选择上一个 snapshot：

这个时候后列表中的内容是当前的 snapshot 针对上一个的增加的部分，可以看到图中的 snapshot 14 比 snapshot 13 多出来的部分，跟 snapshot 13 比 snapshot 12 多出来的部分都有 ArrayBuffer，那么就可以确定 ArrayBuffer 导致了内存泄露。这个时候可以结合上面一节的「查看对象引用关系」来定位到类或者代码。