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

Question

根据node.js文档,节点在32位版本上具有512meg限制,在64位版本上具有1.4gig限制.Chrome AFAICT的限制类似.(+/- 25%)

那么,为什么当代码永远不会使用超过424美分的内存时,这段代码会耗尽内存？

这是代码(代码是无意义的.这个问题不是代码在做什么,而是关于代码失败的原因).

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个字符来构建字符串.在这种情况下,它将构建一个长度为(180meg)的字符串89478988.由于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

尝试了节点4.2.4和5.6.0

所以,问题是为什么内存耗尽？

我试过的一些事情.

1. 我尝试加入大块

   而不是output无限追加,我试着检查它是否大于某个大小(如8k).如果是这样我把它放在一个数组中并将输出重置为空字符串.

   这样做output绝不会超过8k.该阵列保持180meg +簿记.因此180meg + 8k远低于180meg + 180meg.它仍然耗尽内存.现在,在该过程结束时,我加入了数组,此时它将实际使用更多内存(180meg + 180meg + bookeeping).但是,v8在它到达那条线之前崩溃了.

2. 我尝试将编码改为just

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

   在这种情况下,它实际上运行完成!! 所以我想,"A-ha!问题必须与lookup[num]每次通话产生一个新字符串有关吗？所以我试过......

3. 更改lookup为字符串数组

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

   仍然耗尽内存

这似乎是v8中的一个错误？由于这个代码,它无法以某种奇怪的方式GC未使用的字符串,尽管#2 vs#3很奇怪,因为它们在内存使用方面看起来相当.

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

Answer 1

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

首先，我们可以heapdump看看垃圾收集器在做什么：

上面的快照是在节点内存不足前不久拍摄的。如您所见，大多数事情看起来很正常：我们看到两个字符串（output要添加的非常大的和小的块），对同一数组的三个引用big（大约 64MB，与我们预期的相似），还有许多更小的看起来不寻常的物品。

但是，有一点很突出：output高达 1.4+ GB。在拍摄快照时，它大约有 8000 万个字符长，因此假设每个字符有 2 个字节，大约为 160 MB。这怎么可能？

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

[v8 字符串] 有两种类型（实际上更多，但对于手头的问题只有这两种很重要）：

• 扁平字符串是不可变的字符数组
• cons 字符串是成对的字符串，连接的结果。

如果你连接 a 和 b，你会得到一个代表连接结果的 cons-string (a, b)。如果你稍后将 d 连接到它，你会得到另一个 cons-string ((a, b), d)。

索引到这样的“树状”字符串不是 O(1)，因此为了使其更快，V8 在索引时将字符串扁平化：将所有字符复制到扁平字符串中。

那么，v8 会代表output一棵巨树吗？检查的一种方法是强制 v8 压平字符串（如上面的 mraleph 所建议的），例如通过output在for循环内定期索引：

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

确实，程序成功运行了！

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