javascript - 为什么在这种情况下 v8 会耗尽内存？

Question

根据 node.js 文档，一个 Node 在 32 位版本上有 512meg 的限制，在 64 位版本上有 1.4gig 的限制。 Chrome AFAICT 的限制类似。 (+/- 25%)

那么，为什么这段代码从不使用超过 ~424meg 的内存却会耗尽内存？

这是代码(代码是废话。这个问题不是关于代码在做什么，而是关于代码为什么失败)。

var lookup = 'superCaliFragilisticExpialidosiousThispartdoesnotrealllymattersd';
function encode (num) {
  return lookup[num];
}

function makeString(uint8) {
  var output = '';

  for (var i = 0, length = uint8.length; i < length; i += 3) {
    var temp = (uint8[i] << 16) + (uint8[i + 1] << 8) + (uint8[i + 2]);
    output += encode(temp >> 18 & 0x3F) + encode(temp >> 12 & 0x3F) + encode(temp >> 6 & 0x3F) + encode(temp & 0x3F);
  }

  return output;
}

function test() {
  var big = new Uint8Array(64 * 1024 * 1024 + 2); // multiple of 3
  var str = makeString(big);
  console.log("big:", big.length);
  console.log("str:", str.length);
}

test();

如您所见，makeString 通过一次附加 4 个字符来构建一个字符串。在这种情况下，它将构建一个长度为 89478988 (180meg) 的大字符串。由于 output 被追加，最后一次追加字符时，内存中将有 2 个字符串。旧的有 89478984 个字符，最后一个有 89478988 个字符。GC 应该收集任何其他使用的内存。

因此，64meg(原始数组)+ 180meg * 2 = 424meg。远低于 v8 限制。

但是，如果您运行示例，它将因内存不足而失败

<--- Last few GCs --->

    3992 ms: Scavenge 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 0.2 / 0 ms (+ 1.5 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
    4450 ms: Mark-sweep 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 458.0 / 0 ms (+ 2.9 ms in 2 steps since start of marking, biggest step 1.5 ms) [last resort gc].
    4909 ms: Mark-sweep 1397.9 (1458.1) -> 1397.9 (1458.1) MB, 458.7 / 0 ms [last resort gc].

$ node foo.js    
<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x3a8521e3ac1 <JS Object>
    2: makeString(aka makeString) [/Users/gregg/src/foo.js:~6] [pc=0x1f83baf53a3b] (this=0x3a852104189 <undefined>,uint8=0x2ce813b51709 <an Uint8Array with map 0x32f492c0a039>)
    3: test(aka test) [/Users/gregg/src/foo.js:19] [pc=0x1f83baf4df7a] (this=0x3a852104189 <undefined>)
    4: /* anonymous */ [/Users/gregg/src/foo.js:24] [pc=0x1f83baf4d9e5] (this=0x2ce813b...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6

Node 4.2.4和5.6.0都试过了

那么，问题是为什么内存不足？

一些我尝试过的东西。

1. 我尝试加入 block

   我没有无限期地附加到 output，而是尝试检查它是否 大于某个大小(如 8k)。如果是这样，我把它放在一个数组中，然后 将输出重置为空字符串。

   通过执行此操作，输出 永远不会超过 8k。该阵列持有 180meg + 簿记。所以 180meg + 8k 比 180meg + 小很多 180兆。它仍然耗尽内存。现在，在那个过程的最后，我 加入数组，此时它实际上会使用更多内存 (180meg + 180meg + 簿记)。但是，v8 在到达之前就崩溃了 行。

2. 我尝试将编码更改为

   function encode(num) {
     return 'X';
   }
   

   在这种情况下，它实际上运行到完成!所以我想，“啊哈! 该问题必须与 lookup[num] 生成相关 每次调用一个新字符串？所以我尝试了...

3. 将 lookup 更改为字符串数组

   var lookup = Array.prototype.map.call(
       'superCaliFragilisticExpialidosiousThispartdoesnotrealllymattersd', 
       function(c) {
         return c;
       });
   

   内存不足

这似乎是 v8 中的错误？由于此代码，它无法以某种奇怪的方式对未使用的字符串进行 GC，尽管 #2 与 #3 很奇怪，因为它们在内存使用方面看起来是等效的。

为什么 v8 在这些情况下会耗尽内存？ (是否有解决方法)

Answer 1

TL;DR:您的示例是 v8 内部字符串表示之一的病态案例。您可以通过偶尔索引到 output 来修复它(有关原因的信息如下)。

首先，我们可以使用heapdump查看垃圾收集器在做什么:

上面的快照是在 Node 内存不足之前不久拍摄的。如您所见，大多数事情看起来都很正常:我们看到两个字符串(非常大的 output 和要添加的小块)，三个对同一数组 big 的引用(大约 64MB，与我们的预期相似)，以及许多看起来并不异常的小项目。

但是，有一件事很突出:output 是一个惊人的 1.4+ GB。在拍摄快照时，它大约有 8000 万个字符长，因此假设每个字符 2 个字节，大约 160 MB。这怎么可能？

也许这与 v8 的内部字符串表示有关。引用 mraleph :

There are two types [of v8 strings] (actually more, but for the problem at hand only these two are important):

• flat strings are immutable arrays of characters
• cons strings are pairs of strings, result of concatenation.

If you concat a and b you get a cons-string (a, b) that represents result of concatenation. If you later concat d to that you get another cons-string ((a, b), d).

Indexing into such a "tree-like" string is not O(1) so to make it faster V8 flattens the string when you index: copies all characters into a flat string.

那么 v8 是否可以将 output 表示为一棵巨树？一种检查方法是强制 v8 压平字符串(如上面 mraleph 所建议的)，例如通过在 for 循环内定期索引到 output:

if (i % 10000000 === 0) {
  // We don't do it at each iteration since it's relatively expensive.
  output[0];
}

果然，程序成功运行了!

仍然存在一个问题:为什么上面的版本 2 可以运行？在那种情况下，v8 似乎能够优化大多数字符串连接(所有右侧的连接，它们都转换为 4 元素数组上的按位运算)。