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

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

我试过的一些事情。

我尝试加入块

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

这样做output永远不会超过8k。数组成立 180meg +簿记。所以180meg + 8k远低于180meg + 180meg。它仍然耗尽内存。现在，在那个过程结束时我加入数组，此时它将实际使用更多内存（180meg + 180meg + bookeeping）。但是，v8在它到达之前崩溃了线。
我尝试将编码改为
```
function encode(num) {
  return 'X';
}
```
在这种情况下，它实际上运行完成!!所以我想，＆＃34; A-ha！问题必须与lookup[num]生成相关每个电话都有一个新字符串所以我试过......

将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万个字符长，所以~160 MB假设每个字符有2个字节。这怎么可能？

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

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


扁平字符串是不可变的字符数组

cons字符串是字符串对，连接结果。


如果你连接a和b，你得到一个代表串联结果的cons字符串（a，b）。如果你后来连接到那个你得到另一个cons-string（（a，b），d）。

索引到这样的＆＃34;树状＆＃34; string不是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元素数组上转换为按位操作）。

为什么在这种情况下v8内存不足？

1 个答案: