连接字符串的节点内存使用情况

2024-01-26

我有以下代码来测试节点虚拟机的内存使用情况：

setInterval(()=>console.log(process.memoryUsage()),1000);

( ()=> {

    const MAXTIMES = 10000000;

    let a = ( ()=> {
        let res = "";
        for(let i=0; i<MAXTIMES; i++){
            res = res + "X";
        }
        return res;
    })();


})();

//Uncomment this to give enough time for GC and check top command. 
//Not needed with setInterval in the beginning
//setTimeout(()=>{}, 10000);

top命令显示 vm 使用 ~420M 内存。

当我将 i 的最大值更改为 100000000(100M) 时，我预计内存使用量约为 620M（420M +2 字节 * 100M），但它达到了惊人的 3300~4000M。这里发生了什么？ GC 是否没有拾取循环中的临时字符串？

我尝试使用var确保 i 被提升，但结果是一样的。

EDIT1：将代码更新为带注释的完整代码

EDIT2

我也在 Firefox、Safari 和 Chrome JS 控制台的随机选项卡上运行了代码，也有类似的问题。 Firefox 选项卡占用约 2.5G，Safari 选项卡占用约 6G 内存，Chrome 选项卡占用约 3G。在所有情况下，直到我关闭选项卡之前，GC 都不会声明内存。

不同的 JavaScript 引擎使用的垃圾收集策略略有不同。 Node.js 使用v8 https://developers.google.com/v8/这是最初为 Chrome 构建的引擎，并且 Chrome 仍在使用。

为了更多地了解 V8 中垃圾收集的工作原理，我推荐这篇文章，虽然很旧，但今天仍然相关：https://strongloop.com/strongblog/node-js-performance-garbage-collection/ https://strongloop.com/strongblog/node-js-performance-garbage-collection/

您可以使用以下命令查看运行节点的垃圾收集器正在做什么--trace-gc --log-gc选项。

在您的代码中，内存增加比您预期的要多得多，因为：

每次你这样做res += "X"它创建一个全新的字符串并分配它到res然后前一个就有资格进行垃圾收集

正如@jfriend00 在评论中所写。真正可能发生的事情比这更复杂一些，但我认为我们不需要讨论细节。

我更愿意向您展示，我们在运行您的代码时可以观察到什么。

我稍微改变了一下：

const humanize = require('humanize')
setInterval(() => console.log(humanize.filesize(process.memoryUsage().heapUsed)),1000);

setInterval(() => {
    const MAXTIMES = 10000000;

    let a = ( ()=> {
        let res = "";
        console.log('starting');
        for(let i=0; i<MAXTIMES; i++){
            // Add this for last run
            // if (i % (MAXTIMES / 10) === 0) {
            //   console.log(i);
            // }
            res = res + "X";
        }
        console.log('done');
        return res;
    })();
}, 5000);

差异是： 1）humanize有助于格式化内存值。 2）我只是打印heapUsed。 3）我调用每 5 秒连接字符串的函数setInterval.

当我运行它时，我得到：

$ node index.js
4.36 MB
4.39 MB
4.40 MB
4.40 MB
starting
done
385.80 MB
385.80 MB
385.80 MB
385.80 MB
385.80 MB
starting
done
385.52 MB
4.00 MB
4.00 MB
4.00 MB
4.01 MB
starting
done
385.63 MB
385.63 MB
385.64 MB
385.64 MB
385.64 MB
starting
done
385.77 MB
385.77 MB
385.77 MB
385.78 MB
385.78 MB
starting
done
385.54 MB
...

因此，在调用该函数之前，内存只有 4Mb。 “starting”和“done”总是一个接一个地打印，因为它们是同步的。第一次通话后heapUsed到达385.80Mb.

5 秒后，再次调用该函数时，内存将变为385.52 MB。请注意，内存不会加倍。相反，您可以看到在第二次运行中内存达到4.00 MB2秒后。之后，当再次调用该函数时，内存会再次循环385Mb.

--max-old-space-size限制节点可以使用的最大内存。如果我再次运行该程序，将内存限制为 400MB，则输出会有所不同：

$ node --max-old-space-size=400 index.js
4.36 MB
4.39 MB
4.40 MB
4.40 MB
starting
done
385.52 MB
384.04 MB
4.00 MB
4.00 MB
4.00 MB
starting
done
385.48 MB
4.00 MB
4.00 MB
4.00 MB
4.01 MB
starting
done
386.11 MB
384.21 MB
4.00 MB
4.00 MB
4.00 MB
starting
done
385.56 MB
4.00 MB

可以看到，函数调用后，内存立即就到了385Mb但它很快就会4.00 MB.

这是因为对内存的限制使得垃圾收集算法在回收内存时更加“激进”，以防止内存不足错误。

要了解 V8 到底在做什么，我们可以使用--trace-gc --log-gc参数。我还添加了if (i % (MAXTIMES / 10) === 0) console.log(i);循环中以确保事情发生时清晰可见。

$ node --trace-gc --log-gc --max-old-space-size=400  index.js
[10826:0x103000000]       51 ms: Scavenge 3.4 (6.4) -> 3.2 (7.4) MB, 1.3 / 0.0 ms  allocation failure
[10826:0x103000000]       61 ms: Scavenge 3.5 (7.4) -> 3.5 (8.4) MB, 1.1 / 0.0 ms  allocation failure
4.64 MB
4.67 MB
4.68 MB
4.68 MB
starting
0
[10826:0x103000000]     5094 ms: Scavenge 4.8 (8.9) -> 4.6 (8.9) MB, 1.1 / 0.0 ms  allocation failure
[10826:0x103000000]     5106 ms: Scavenge 5.5 (8.9) -> 5.5 (9.4) MB, 2.8 / 0.0 ms  allocation failure
[10826:0x103000000]     5109 ms: Scavenge 6.1 (9.4) -> 6.1 (10.4) MB, 2.7 / 0.0 ms  allocation failure
[10826:0x103000000]     5112 ms: Scavenge 7.0 (10.4) -> 7.0 (12.4) MB, 2.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5115 ms: Scavenge 7.5 (12.4) -> 7.5 (16.4) MB, 2.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5122 ms: Scavenge 9.9 (16.4) -> 10.0 (16.9) MB, 4.8 / 0.0 ms  allocation failure
[10826:0x103000000]     5127 ms: Scavenge 10.4 (16.9) -> 10.3 (25.4) MB, 5.5 / 0.0 ms  allocation failure
[10826:0x103000000]     5141 ms: Scavenge 15.8 (25.4) -> 16.0 (25.9) MB, 10.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5154 ms: Scavenge 16.2 (25.9) -> 16.0 (43.4) MB, 12.9 / 0.0 ms  allocation failure
[10826:0x103000000]     5182 ms: Scavenge 27.6 (43.4) -> 28.1 (43.9) MB, 21.2 / 0.0 ms  allocation failure
[10826:0x103000000]     5202 ms: Scavenge 28.1 (43.9) -> 27.6 (63.4) MB, 20.2 / 0.0 ms  allocation failure
1000000
[10826:0x103000000]     5234 ms: Scavenge 43.3 (63.4) -> 44.0 (63.9) MB, 24.7 / 0.0 ms  allocation failure
[10826:0x103000000]     5266 ms: Scavenge 44.1 (63.9) -> 43.3 (79.4) MB, 32.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5293 ms: Scavenge 59.1 (79.4) -> 59.8 (79.9) MB, 22.3 / 0.0 ms  allocation failure
[10826:0x103000000]     5323 ms: Scavenge 59.8 (79.9) -> 59.1 (95.4) MB, 30.0 / 0.0 ms  allocation failure
[10826:0x103000000]     5375 ms: Scavenge 74.8 (95.4) -> 75.5 (95.9) MB, 19.9 / 0.0 ms  allocation failure
[10826:0x103000000]     5407 ms: Scavenge 75.5 (95.9) -> 74.8 (111.4) MB, 30.5 / 0.0 ms  allocation failure
2000000
[10826:0x103000000]     5444 ms: Mark-sweep 82.2 (111.4) -> 82.0 (111.4) MB, 8.6 / 0.0 ms  (+ 54.6 ms in 371 steps since start of marking, biggest step 4.0 ms, walltime since start of marking 177 ms) finalize incremental marking via stack guard GC in old space requested
[10826:0x103000000]     5478 ms: Scavenge 90.3 (111.4) -> 90.7 (118.9) MB, 31.9 / 0.0 ms  allocation failure
[10826:0x103000000]     5505 ms: Scavenge 97.7 (118.9) -> 97.7 (127.4) MB, 25.2 / 0.0 ms  allocation failure
[10826:0x103000000]     5534 ms: Scavenge 106.0 (127.4) -> 106.1 (134.9) MB, 26.6 / 0.0 ms  allocation failure
[10826:0x103000000]     5562 ms: Scavenge 113.1 (134.9) -> 113.0 (143.4) MB, 25.7 / 0.0 ms  allocation failure
3000000
[10826:0x103000000]     5589 ms: Scavenge 121.4 (143.4) -> 121.5 (149.4) MB, 23.8 / 0.0 ms  allocation failure
[10826:0x103000000]     5626 ms: Scavenge 128.4 (149.4) -> 128.4 (158.4) MB, 35.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5656 ms: Scavenge 136.8 (158.4) -> 136.9 (165.4) MB, 27.3 / 0.0 ms  allocation failure
[10826:0x103000000]     5699 ms: Scavenge 143.8 (165.4) -> 143.7 (173.9) MB, 26.4 / 0.0 ms  allocation failure
[10826:0x103000000]     5762 ms: Scavenge 152.3 (173.9) -> 152.3 (180.9) MB, 25.3 / 0.0 ms  allocation failure
4000000
[10826:0x103000000]     5829 ms: Scavenge 159.1 (180.9) -> 159.0 (189.4) MB, 26.8 / 0.0 ms  allocation failure
[10826:0x103000000]     5854 ms: Mark-sweep 161.0 (189.4) -> 160.7 (196.9) MB, 3.6 / 0.0 ms  (+ 108.5 ms in 387 steps since start of marking, biggest step 4.4 ms, walltime since start of marking 228 ms) finalize incremental marking via stack guard GC in old space requested
[10826:0x103000000]     5891 ms: Scavenge 174.4 (196.9) -> 175.1 (198.9) MB, 32.0 / 0.0 ms  allocation failure
[10826:0x103000000]     5923 ms: Scavenge 176.4 (198.9) -> 175.8 (212.9) MB, 31.6 / 0.0 ms  allocation failure
[10826:0x103000000]     5946 ms: Scavenge 190.1 (212.9) -> 190.8 (214.4) MB, 18.6 / 0.0 ms  allocation failure
[10826:0x103000000]     5976 ms: Scavenge 191.5 (214.4) -> 190.8 (229.4) MB, 29.8 / 0.0 ms  allocation failure
5000000
[10826:0x103000000]     6002 ms: Scavenge 205.8 (229.4) -> 206.5 (229.4) MB, 19.4 / 0.0 ms  allocation failure
[10826:0x103000000]     6034 ms: Scavenge 206.5 (229.4) -> 205.8 (244.4) MB, 31.7 / 0.0 ms  allocation failure
[10826:0x103000000]     6059 ms: Scavenge 221.5 (244.4) -> 222.2 (244.9) MB, 20.9 / 0.0 ms  allocation failure
[10826:0x103000000]     6088 ms: Scavenge 222.3 (244.9) -> 221.5 (260.4) MB, 28.4 / 0.0 ms  allocation failure
6000000
[10826:0x103000000]     6114 ms: Scavenge 237.3 (260.4) -> 238.0 (260.9) MB, 22.3 / 0.0 ms  allocation failure
[10826:0x103000000]     6142 ms: Scavenge 238.0 (260.9) -> 237.3 (276.4) MB, 27.5 / 0.0 ms  allocation failure
[10826:0x103000000]     6169 ms: Scavenge 253.0 (276.4) -> 253.7 (276.9) MB, 22.4 / 0.0 ms  allocation failure
[10826:0x103000000]     6203 ms: Scavenge 253.7 (276.9) -> 253.0 (292.4) MB, 33.6 / 0.0 ms  allocation failure
[10826:0x103000000]     6380 ms: Scavenge 268.7 (292.4) -> 269.4 (292.9) MB, 20.6 / 0.0 ms  allocation failure
[10826:0x103000000]     6414 ms: Scavenge 269.5 (292.9) -> 268.7 (308.4) MB, 32.1 / 0.0 ms  allocation failure
[10826:0x103000000]     6446 ms: Mark-sweep 269.9 (308.4) -> 269.9 (308.4) MB, 2.1 / 0.0 ms  (+ 183.4 ms in 270 steps since start of marking, biggest step 5.5 ms, walltime since start of marking 304 ms) finalize incremental marking via stack guard GC in old space requested
7000000
[10826:0x103000000]     6478 ms: Scavenge 284.5 (308.4) -> 285.2 (309.9) MB, 25.2 / 0.0 ms  allocation failure
[10826:0x103000000]     6510 ms: Scavenge 285.6 (309.9) -> 284.9 (324.9) MB, 32.4 / 0.0 ms  allocation failure
[10826:0x103000000]     6538 ms: Scavenge 300.2 (324.9) -> 300.9 (325.9) MB, 22.8 / 0.0 ms  allocation failure
[10826:0x103000000]     6570 ms: Scavenge 300.9 (325.9) -> 300.2 (341.4) MB, 31.8 / 0.0 ms  allocation failure
8000000
[10826:0x103000000]     6595 ms: Scavenge 315.9 (341.4) -> 316.7 (342.4) MB, 20.6 / 0.0 ms  allocation failure
[10826:0x103000000]     6643 ms: Scavenge 316.7 (342.4) -> 316.0 (357.9) MB, 48.2 / 0.0 ms  allocation failure
[10826:0x103000000]     6670 ms: Scavenge 331.7 (357.9) -> 332.4 (358.9) MB, 21.9 / 0.0 ms  allocation failure
[10826:0x103000000]     6703 ms: Scavenge 332.4 (358.9) -> 331.7 (374.4) MB, 32.4 / 0.0 ms  allocation failure
[10826:0x103000000]     6728 ms: Scavenge 347.4 (374.4) -> 348.1 (375.4) MB, 20.7 / 0.0 ms  allocation failure
[10826:0x103000000]     6756 ms: Scavenge 348.1 (375.4) -> 347.4 (390.9) MB, 27.9 / 0.0 ms  allocation failure
9000000
[10826:0x103000000]     6986 ms: Mark-sweep 350.9 (390.9) -> 350.8 (390.9) MB, 2.3 / 0.0 ms  (+ 225.8 ms in 55 steps since start of marking, biggest step 6.0 ms, walltime since start of marking 230 ms) finalize incremental marking via stack guard GC in old space requested
[10826:0x103000000]     7020 ms: Scavenge 363.1 (390.9) -> 363.7 (392.4) MB, 30.2 / 0.0 ms  allocation failure
[10826:0x103000000]     7055 ms: Scavenge 366.6 (392.4) -> 366.1 (404.9) MB, 33.7 / 0.0 ms  allocation failure
[10826:0x103000000]     7080 ms: Scavenge 378.9 (404.9) -> 379.3 (407.9) MB, 21.7 / 0.0 ms  allocation failure
[10826:0x103000000]     7106 ms: Scavenge 381.7 (407.9) -> 381.2 (420.9) MB, 25.2 / 0.0 ms  allocation failure
[10826:0x103000000]     7342 ms: Mark-sweep 384.8 (420.9) -> 384.7 (422.9) MB, 3.3 / 0.0 ms  (+ 231.9 ms in 58 steps since start of marking, biggest step 5.5 ms, walltime since start of marking 237 ms) finalize incremental marking via stack guard GC in old space requested
done
385.70 MB
[10826:0x103000000]     7384 ms: Mark-sweep 385.7 (422.9) -> 4.2 (40.9) MB, 39.4 / 0.0 ms  (+ 0.0 ms in 1 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 39 ms) finalize incremental marking via task GC in old space requested
4.22 MB
4.23 MB
4.23 MB
4.23 MB
starting
0
[10826:0x103000000]    12380 ms: Scavenge 20.0 (40.9) -> 20.7 (40.9) MB, 19.4 / 0.0 ms  allocation failure
[10826:0x103000000]    12406 ms: Scavenge 20.7 (40.9) -> 20.0 (55.4) MB, 26.7 / 0.0 ms  allocation failure
[10826:0x103000000]    12430 ms: Scavenge 35.7 (55.4) -> 36.4 (55.9) MB, 19.5 / 0.0 ms  allocation failure
[10826:0x103000000]    12457 ms: Scavenge 36.4 (55.9) -> 35.7 (71.4) MB, 27.3 / 0.0 ms  allocation failure
1000000
[10826:0x103000000]    12484 ms: Scavenge 51.4 (71.4) -> 52.1 (71.9) MB, 22.6 / 0.0 ms  allocation failure
[10826:0x103000000]    12513 ms: Scavenge 52.2 (71.9) -> 51.4 (87.4) MB, 28.2 / 0.0 ms  allocation failure
[10826:0x103000000]    12551 ms: Scavenge 67.2 (87.4) -> 67.9 (87.9) MB, 21.9 / 0.0 ms  allocation failure
[10826:0x103000000]    12578 ms: Scavenge 67.9 (87.9) -> 67.2 (103.4) MB, 26.9 / 0.0 ms  allocation failure
2000000
[10826:0x103000000]    12646 ms: Mark-sweep 81.7 (103.4) -> 81.7 (103.4) MB, 30.1 / 0.0 ms  (+ 46.7 ms in 311 steps since start of marking, biggest step 5.2 ms, walltime since start of marking 189 ms) finalize incremental marking via stack guard GC in old space requested
[10826:0x103000000]    12680 ms: Scavenge 82.9 (103.4) -> 82.9 (118.4) MB, 31.8 / 0.0 ms  allocation failure
[10826:0x103000000]    12712 ms: Scavenge 97.5 (118.4) -> 98.1 (119.9) MB, 20.8 / 0.0 ms  allocation failure
[10826:0x103000000]    12738 ms: Scavenge 98.6 (119.9) -> 98.0 (134.9) MB, 26.8 / 0.0 ms  allocation failure
[10826:0x103000000]    12762 ms: Scavenge 113.1 (134.9) -> 113.8 (135.9) MB, 20.1 / 0.0 ms  allocation failure
[10826:0x103000000]    12789 ms: Scavenge 113.9 (135.9) -> 113.1 (151.4) MB, 26.8 / 0.0 ms  allocation failure
3000000
[10826:0x103000000]    12813 ms: Scavenge 128.9 (151.4) -> 129.6 (151.9) MB, 20.6 / 0.0 ms  allocation failure
[10826:0x103000000]    12839 ms: Scavenge 129.6 (151.9) -> 128.9 (166.4) MB, 25.4 / 0.0 ms  allocation failure
[10826:0x103000000]    12913 ms: Scavenge 144.6 (166.4) -> 145.3 (166.9) MB, 20.9 / 0.0 ms  allocation failure
[10826:0x103000000]    12944 ms: Scavenge 145.3 (166.9) -> 144.6 (182.4) MB, 29.2 / 0.0 ms  allocation failure
[10826:0x103000000]    12997 ms: Mark-sweep 151.5 (182.4) -> 151.5 (182.4) MB, 3.9 / 0.0 ms  (+ 98.2 ms in 363 steps since start of marking, biggest step 5.0 ms, walltime since start of marking 208 ms) finalize incremental marking via stack guard GC in old space requested
4000000
[10826:0x103000000]    13028 ms: Scavenge 160.3 (182.4) -> 160.8 (189.4) MB, 28.7 / 0.0 ms  allocation failure
[10826:0x103000000]    13054 ms: Scavenge 167.3 (189.4) -> 167.2 (198.4) MB, 24.2 / 0.0 ms  allocation failure
[10826:0x103000000]    13079 ms: Scavenge 176.1 (198.4) -> 176.2 (205.4) MB, 22.3 / 0.0 ms  allocation failure
[10826:0x103000000]    13104 ms: Scavenge 182.6 (205.4) -> 182.4 (214.9) MB, 23.8 / 0.0 ms  allocation failure
[10826:0x103000000]    13129 ms: Scavenge 191.5 (214.9) -> 191.6 (221.4) MB, 23.1 / 0.0 ms  allocation failure
5000000
[10826:0x103000000]    13155 ms: Scavenge 197.9 (221.4) -> 197.7 (230.9) MB, 24.9 / 0.0 ms  allocation failure
[10826:0x103000000]    13181 ms: Scavenge 206.9 (230.9) -> 207.1 (237.4) MB, 24.0 / 0.0 ms  allocation failure
[10826:0x103000000]    13206 ms: Scavenge 213.2 (237.4) -> 213.0 (246.9) MB, 23.2 / 0.0 ms  allocation failure
[10826:0x103000000]    13232 ms: Scavenge 222.4 (246.9) -> 222.5 (253.4) MB, 23.0 / 0.0 ms  allocation failure
[10826:0x103000000]    13258 ms: Scavenge 228.5 (253.4) -> 228.3 (262.9) MB, 24.9 / 0.0 ms  allocation failure
6000000
[10826:0x103000000]    13316 ms: Scavenge 237.8 (262.9) -> 238.0 (267.9) MB, 24.6 / 0.0 ms  allocation failure
[10826:0x103000000]    13381 ms: Scavenge 243.8 (267.9) -> 243.6 (277.9) MB, 25.9 / 0.0 ms  allocation failure
[10826:0x103000000]    13480 ms: Mark-sweep 251.5 (277.9) -> 251.2 (282.9) MB, 5.3 / 0.0 ms  (+ 159.5 ms in 371 steps since start of marking, biggest step 4.1 ms, walltime since start of marking 248 ms) finalize incremental marking via stack guard GC in old space requested
[10826:0x103000000]    13517 ms: Scavenge 259.1 (282.9) -> 259.4 (290.4) MB, 34.7 / 0.0 ms  allocation failure
[10826:0x103000000]    13545 ms: Scavenge 266.9 (290.4) -> 266.9 (298.4) MB, 23.6 / 0.0 ms  allocation failure
7000000
[10826:0x103000000]    13571 ms: Scavenge 274.8 (298.4) -> 274.8 (306.4) MB, 24.2 / 0.0 ms  allocation failure
[10826:0x103000000]    13597 ms: Scavenge 282.3 (306.4) -> 282.3 (313.9) MB, 24.2 / 0.0 ms  allocation failure
[10826:0x103000000]    13636 ms: Scavenge 290.1 (313.9) -> 290.1 (321.9) MB, 36.8 / 0.0 ms  allocation failure
[10826:0x103000000]    13662 ms: Scavenge 297.7 (321.9) -> 297.7 (329.9) MB, 24.3 / 0.0 ms  allocation failure
[10826:0x103000000]    13687 ms: Scavenge 305.5 (329.9) -> 305.5 (337.4) MB, 23.7 / 0.0 ms  allocation failure
8000000
[10826:0x103000000]    13717 ms: Scavenge 313.0 (337.4) -> 313.0 (345.4) MB, 27.6 / 0.0 ms  allocation failure
[10826:0x103000000]    13746 ms: Scavenge 320.9 (345.4) -> 320.9 (352.9) MB, 25.9 / 0.0 ms  allocation failure
[10826:0x103000000]    13773 ms: Scavenge 328.4 (352.9) -> 328.4 (360.9) MB, 24.9 / 0.0 ms  allocation failure
[10826:0x103000000]    13798 ms: Scavenge 336.2 (360.9) -> 336.2 (368.9) MB, 23.5 / 0.0 ms  allocation failure
[10826:0x103000000]    14033 ms: Mark-sweep 339.4 (368.9) -> 339.0 (376.9) MB, 4.0 / 0.0 ms  (+ 229.2 ms in 50 steps since start of marking, biggest step 5.7 ms, walltime since start of marking 234 ms) finalize incremental marking via stack guard GC in old space requested
9000000
[10826:0x103000000]    14072 ms: Scavenge 351.6 (376.9) -> 352.2 (379.9) MB, 35.7 / 0.0 ms  allocation failure
[10826:0x103000000]    14101 ms: Scavenge 354.7 (379.9) -> 354.3 (392.9) MB, 28.0 / 0.0 ms  allocation failure
[10826:0x103000000]    14125 ms: Scavenge 367.3 (392.9) -> 367.8 (395.9) MB, 21.4 / 0.0 ms  allocation failure
[10826:0x103000000]    14154 ms: Scavenge 369.9 (395.9) -> 369.3 (409.4) MB, 28.1 / 0.0 ms  allocation failure
[10826:0x103000000]    14178 ms: Scavenge 383.0 (409.4) -> 383.5 (411.9) MB, 20.5 / 0.0 ms  allocation failure
[10826:0x103000000]    14311 ms: Scavenge 385.0 (411.9) -> 384.4 (425.4) MB, 30.4 / 0.0 ms  allocation failure
done
385.77 MB
[10826:0x103000000]    14455 ms: Mark-sweep 385.8 (425.4) -> 382.9 (425.4) MB, 1.2 / 0.0 ms  (+ 244.2 ms in 103 steps since start of marking, biggest step 6.2 ms, walltime since start of marking 278 ms) finalize incremental marking via task GC in old space requested
382.93 MB
[10826:0x103000000]    15413 ms: Mark-sweep 382.9 (425.4) -> 4.2 (41.9) MB, 0.8 / 0.0 ms  (+ 2.8 ms in 4 steps since start of marking, biggest step 1.1 ms, walltime since start of marking 4 ms) finalize incremental marking via task GC in old space requested
4.22 MB
4.23 MB

在这种情况下，清除周期并不会真正回收任何内存，我们必须等待完整的标记清除完成才能释放所有内存。

有道理吗？

最后，我想补充一点：

真实代码通常不会在一次时间内进行 1000 万次字符串连接。
V8 的垃圾收集算法通常会做正确的事情，以便在防止进程耗尽内存和防止自身不必要地减慢进程之间取得适当的平衡。
如果您遇到垃圾收集问题，您需要进行一些分析，解决方案通常意味着重构代码以一次性完成更少的工作。它可能要复杂得多，但深入探讨可能与这个问题无关。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

连接字符串的节点内存使用情况的相关文章

如何重置使用 JavaScript 更改的 CSS 属性？

我的导航按钮的宽度从 100px 增加到 150px 当鼠标悬停在 nav li hover width 150px 但是使用 javascript 我已经做到了无论选择哪个选项宽度都将继续为 150px 当选择每个选项时它会使其他选
Socket.io - “套接字 ID”是否被视为敏感信息？

我正在使用 Node js 和 socket io 实现一个简单的聊天应用程序想知道在整个对象中共享所有客户端的套接字 ID 是否被认为是一个好的做法为了解释一下我的每个用户都是这样表示的 nick John Doe dateJoin
Meteor：应用程序无法在 0.9.1.1 版本上运行

出现类似错误 Error TypeError undefined is not a function evaluating Template create anonymous function iron dynamic template j
使用 Angular 下载具有动态 src 的脚本

Angular 提供了通过动态名称动态加载模板的方法ng include 该部分中的内联 JS 和 CSS 可以正常加载但没有一个好的方法来下载带有动态 url 的脚本我们需要下载脚本相对于调用它们的 html 部分的路径即我们有一
在 Wordpress 站点中进行 AJAX 调用时出现问题

我在使用 Wordpress 站点功能的 AJAX 部分时遇到了一些问题该功能接受在表单上输入的邮政编码使用 PHP 函数来查找邮政编码是否引用特定位置并返回到该位置的永久链接我的第一个问题是关于我构建的表单现在我的表单操作是空白的
Google App Engine：修改云运行环境

我正在尝试部署一个使用自定义 Node js 服务器的 Next js 应用程序我想将自定义构建变量注入应用程序 next config js const NODE ENV process env NODE ENV const envTy
可以使用 jQuery 或 Javascript 将图片的特定部分用作链接吗？

我有这个想法将图片而不是文本的各个部分链接到不同的页面或网站并且我想在不实际创建不同的照片并将它们彼此靠近的情况下完成这样看起来就像是一张完整的图片这里有人知道如何使用 JavaScript 的变体例如 jQuery 或纯 J
Javascript正则表达式用于字母字符和空格？ [关闭]

这个问题不太可能对任何未来的访客有帮助它只与一个较小的地理区域一个特定的时间点或一个非常狭窄的情况相关通常不适用于全世界的互联网受众为了帮助使这个问题更广泛地适用访问帮助中心 help reopen questions 我需要一个
使用node.js安装xml2json时出错

我尝试为 node js 安装 xml2json 包但它给了我错误 Error are as below 我的系统配置如下 Node js 版本 v5 4 1 npm 版本 3 3 12 操作系统 Windows 10 64 位 pyth
为什么是 javascript:history.go(-1);无法在移动设备上工作？

首先一些背景我有一个向用户呈现搜索页面 html 表单的应用程序填写标准并单击搜索按钮后结果将显示在标准部分下方在结果列表中您可以通过单击将您带到新页面的链接来查看单个结果的详细信息在详细信息页面中我添加了一个返回结
JavaScript 重定向到新窗口

我有以下代码它根据下拉列表的值重定向到页面我如何使其在新窗口中打开 function goto form var index form select selectedIndex if form select options index
使用 KnockoutJs 映射插件进行递归模板化

我正在尝试使用以下方法在树上进行递归模板化ko映射插入 http knockoutjs com documentation plugins mapping html 但我无法渲染它除非我定义separate每个级别的模板在以下情况下
将div设置为隐藏，延时后可见

我试图在 X 时间后也许甚至在随机时间之后但现在我们只做固定时间在黑色背景上出现一个黄色方块 function initialSetup if document getElementById yellow null document
通过 CDN 使用 Dojo 时如何加载自定义 AMD 模块？

我正在使用 google 的 CDN 并尝试使用他们的加载程序加载我自己的 AMD 模块我知道我做错了什么但我被困住了有任何想法吗
提交表单并重定向页面

我在 SO 上看到了很多与此相关的其他问题但没有一个对我有用我正在尝试提交POST表单然后将用户重定向到另一个页面但我无法同时实现这两种情况我可以获取重定向或帖子但不能同时获取两者这是我现在所拥有的
Grails 在 javascript 内的 GSP 站点中使用 grails var

我有一个在 GSP 文件中的 javascript 代码中使用 grails 变量值的问题例如我有一个会话值session getAttribute selectedValue 我想在 javascript 代码部分使用这个值我现在的
为什么在 Internet Explorer 中访问 localStorage 对象会引发错误？

我正在解决一个客户端问题 Modernizr 意外地没有检测到对localStorageInternet Explorer 9 中的对象我的页面正确使用 HTML 5 文档类型并且开发人员工具报告该页面具有 IE9 的浏览器模式和 IE
为什么我不能在 AngularJS 中使用 data-* 作为指令的属性名称？

On the t他的笨蛋 http plnkr co edit l3KoY3 p preview您可以注意到属性名称模式的奇怪行为data 在指令中电话 Test of data named attribute br
为什么 jquery 没有检测到单选按钮未被选中的情况？ [复制]

这个问题在这里已经有答案了可能的重复 JQuery radioButton change 在取消选择期间不会触发 https stackoverflow com questions 5176803 jquery radiobutton c
fullCalendar 未显示正确的结束日期

我正在看调试页面 http jsbin com wukofacaxu edit js outputFullCalendar 官方网站的我想安排一个活动时间为 22 09 2015 至 30 09 2015 dd mm yyyy 但它只显示

随机推荐

在 WinForms MDI 中使用实体框架和存储库模式

我们即将启动一个与之前的项目类似的新项目我可以复制旧的设计但我对旧的设计不太满意它是一个标准业务系统销售盘点仓储等构建在 Net 3 5 Winforms MDI 之上后端带有实体框架所有窗体都继承自基本窗体它继承
使用分隔符向 Sql 查询添加 where 子句

我有以下存储过程它接受使用两个分隔符的字符串该过程提取数据并插入到数据库中就像我有一个键值对一样示例输入字符串说 10 1 11 2 12 3 我也需要在其中查找值 10 Id 列并在其中插入值 1 value 专栏等程序代码如
如何对计算字段上的 ClientDataSet 进行排序？

我试图在计算的布尔字段上对 ClientDataSet 进行排序但由于某种原因数据未排序我有一个名为的布尔字段Highlight with FieldKind set to fkInternalCalc 以及定义如下的索引 Index
Laravel 迁移将列类型从 varchar 更改为 longText

我需要更改迁移列类型 table gt string text 对于文本类型我尝试过几种方法但都不起作用是否可以在一次迁移中完成我可以猜测删除该列然后使用新类型再次创建它但我想知道是否可以在一次迁移中完成此操作您可以创建一个新
c - 错误：“不允许不完整的类型”，IAR 编译器

请指教有什么问题吗 in h struct uint8 t time uint8 t type uint8 t phase uint8 t status Raw data struct typedef struct Raw data st
pdo防止sql注入

我正在尝试将访问者的输入插入数据库这可行但是这足以防止 sql 注入吗
从 JSON 字符串获取值 - Objective C

我有这个 JSON 响应字符串 d ID usuario 000130 Nombre null Vipxlo 0 Provmun null Descuentos null Listaviplocal null 有了这个代码 void con
C++ 标准向量 resize() 函数

resize 根据给定的大小添加删除元素 Reserve 保留内存空间并且不会重新分配内存我的问题是调整大小是否也与矢量的容量一样只是不会增加要添加可以组合 std vector
升级到 Xcode 7.3 swift 2.2 后，从 swift 调用 obj-c 枚举不起作用

在从 Xcode 7 1 和 swift 2 2 升级到 Xcode 7 3 之前代码运行良好我还看到了使用 typedef NS ENUM NSUInteger MyStatus 的答案但如果可能的话我不想更改现有的 obj c
Polybase 创建外部数据源给出语法错误

我尝试在 Azure 数据仓库中执行以下命令 CREATE EXTERNAL DATA SOURCE Brand WITH TYPE HADOOP LOCATION wasbs bran email protected cdn cgi l
按 \n 字符分割似乎不起作用

我从服务器获得结果其中项目用新行分隔所以我执行以下操作 split n split n 这不起作用这在 Chrome 上调试时消失我看到 split n 如何让它发挥作用示例数据从chrome调试器复制六月六日 10 六月六
jstree create_node 的参数

您能给我这个函数的参数列表和使用示例吗 treepanel jstree create node 恕我直言 jsTree 很强大但文档还有待改进 create node 函数已记录here https www jstree com api
使用 awk 切换 csv 文件的列

我想在 csv 文件中将第 2 列与第 3 列交换 cat test csv 1 1 1 2 1 3 2 1 2 2 2 3 3 1 3 2 3 3 我尝试过 awk FS OFS col1 1 col2 2 col3 3 print co
如何在 Amazon Linux 上升级/安装 Upstart deamon 版本 1.5

我通过 EC2 服务实例化一台 Amazon Linux 计算机并且该虚拟机已经安装了版本 0 6 5 的 Upstart 守护程序如何将此软件包升级到最新版本本例为 1 5 版 sudo initctl version return
如何在两个不同的docker容器中的两个django应用程序之间建立连接？

我创建了两个应用程序 myapi 和 minombre 其中 minombre 将向 myapi 发出一个简单的 GET 请求并将它们放入两个单独的 docker 容器中在运行 docker compose up 后容器运行但api
无法使用 DBeaver 连接到 MariaDB

我刚刚在 Ubuntu 18 04 上安装了 MariaDB 10 1 29 从命令行我可以使用 sudo 连接 sudo mysql u root p 但并非没有 sudo 另外如果我尝试通过连接到数据库DBeaver https db
需要更好的方法使用 jquery 验证插件来验证 ASP.NET 复选框吗？

Problem 我想使用 jquery 验证插件来验证一些 ASP NET 复选框位于 http bassistance de jquery plugins jquery plugin validation http bassistanc
Windows 上 JDK 8 的默认 -Xss 值

Oracle 说在 Windows 上 http docs oracle com javase 8 docs technotes tools windows java html Xsssize 默认值取决于虚拟内存我如何找出给定 Orac
Windows 上的“docker-compose up”失败，Mysql 容器步骤出现错误

我正在尝试使用 docker 和 docker compose yml 在 phpstorm 中设置在 Windows 10 上进行 php 开发的环境但在 Mysql 设置步骤中遇到了一些错误找不到问题这是我的 docker com
连接字符串的节点内存使用情况

我有以下代码来测试节点虚拟机的内存使用情况 setInterval gt console log process memoryUsage 1000 gt const MAXTIMES 10000000 let a gt let res fo

连接字符串的节点内存使用情况

连接字符串的节点内存使用情况 的相关文章

随机推荐

热门标签

连接字符串的节点内存使用情况的相关文章