nodejs减少v8垃圾收集器的内存使用量
我正在使用util模块调试nodejs应用程序，而 heapUsed
值保持在30-100MB左右，而 heapTotal 值增长到1.4GB。
我已经读到这是v8垃圾收集器的行为方式，但是问题是，例如在512 MB设备上运行时，如何减少其分配的内存量（使其小于1.4GB）
问题答案：
您需要控制最大内存大小标志（所有大小以MB为单位）。
对于“低内存设备”，建议的数量为：
node --max-executable-size=96 --max-old-space-size=128 --max-semi-space-size=1 app.js
适用于32位和/或Android和
node --max-executable-size=192 --max-old-space-size=256 --max-semi-space-size=2 app.js
适用于64位非Android。
这些将分别限制堆总数为225mb和450mb。它不包括JS外部的内存使用情况。例如，缓冲区被分配为“ c memory”，而不是在JavaScript堆中。
您还应该知道，越接近堆限制，GC中浪费的时间就越多。例如，如果您的内存使用率为95％，则90％的CPU将用于GC，而10％的CPU将用于运行实际代码（不是实数，而是给出总体思路）。因此，您应该尽可能地宽大，并且不要超过最大内存使用量的16％（IE
heapUsed/limit不应大于0.16）。16％只是我从某些论文中得出的结论，它可能不是最理想的。
标志：
--max-executable-size为可执行代码保留的最大堆大小（即时编译的JavaScript的本机代码结果）。--max-old-space-size保留给长期对象的最大堆大小--max-semi-space-size为短期对象保留的堆的最大大小
-
问题内容： 这是我到目前为止所读的内容，如果我写错了，请更正我： Node.js基于V8 JavaScript引擎。 V8 JavaScript引擎实现了世界垃圾收集 这导致Node.js有时完全关闭几秒钟到几分钟来处理垃圾回收。 如果这是为生产代码运行的，那么对于10,000个用户而言，这是几秒钟。 这在生产环境中真的可以接受吗？ 问题答案： 是否可接受取决于您的应用程序和堆大小。Big Gc约
-
我有一个相当复杂的Javascript应用程序，它有一个每秒调用60次的主循环。似乎有很多垃圾回收正在进行中（基于Chrome开发工具中内存时间轴的“锯齿”输出） - 这通常会影响应用程序的性能。 所以，我正在研究减少垃圾收集器必须做的工作量的最佳实践。（我在网上能找到的大部分信息都是关于避免内存泄漏的，这是一个稍微不同的问题——我的内存正在被释放，只是有太多的垃圾回收机制在进行。）我假设这主要归
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。 即使在机器学习应用程序等海量数据应用程序的情况下，ZGC 也具有高性能和高效工作。它确保在处理数据时不会因垃圾收集而长时间停顿。它支持 Linux、Window
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。从那时起，对这个垃圾收集做了很多改进，例如 - 并发类卸载 取消提交未使用的内存 支持班级数据共享 NUMA 多线程堆Pre-touch 最大堆大小限制从 4 T
-
在面对中的一些内存泄漏后，我想知道中是否存在内存泄漏。快速搜索将我带到了以下stackoverflow线程。 @david wasser对此帖子的评论如下： 对象a- 在本例中，ObjectA是代码中正在使用的对象。然而，ObjectA包含一个对ObjectB的引用，该引用实际上是死的（即：ObjectB已经分配和使用，从程序员的角度来看，现在是死的），但程序员忘记了将ObjectA中的引用设置为
-
问题内容： 我从带有node.js的线程垃圾收集中学到了node.js使用世代GC。 我通常使用循环对象引用（最终我都会删除/确保超出范围），并想知道node.js是否能很好地处理它们。所以例如。如果使用参考完成。计数，会有一个问题，所以我想知道这个节点有多好。 一些使用场景： 对于每个http请求，我创建一个带有lambda的setTimeout，该lambda可能引用了范围对象。作用域对象还引