我很困惑，因为我的应用程序正在泄漏内存。它是一个每分钟处理数十万个数据包的 tcp 服务器。我检查了代码，对其进行了改进并分析了内存。
一切似乎都很好，在低流量的本地测试实际上表明 gc 正确释放了内存。但是当在实时流量大的服务器上时，它不会。
所以我尝试使用 expose-gc 选项并在每次断开连接时添加强制 gc，现在我发现内存不再泄漏或者是否每次都泄漏？
所以，我的结论是 gc 没有激活。我的服务器有 3GB 的内存，应用程序在短短几个小时内就吃掉了其中的 2.8GB。
现在使用强制 gc，应用程序不再泄漏。它维持着大约 200MB 的内存。
那么，我的问题是，为什么 gc 没有被触发？
最佳答案
The fundamental problem garbage collection solves is to identify dead memory regions (unreachable objects/garbage) which are not reachable through some chain of pointers from an object which is live. Once identified, these regions can be re-used for new allocations or released back to the operating system
使用事件监听器时内存泄漏非常常见，这是由于正在监听的对象无法被垃圾回收的情况引起的，因为事件发射器(也是一个对象)正在保留对它的引用。
因此在您的代码中，onSuccess 方法将被您的请求对象引用。但是，onSuccess 只是一个被重用为所有请求对象监听器的函数，因此不应导致内存堆积。
为了找到代码中对象保持事件状态的真正原因，我会检查连接结束并确保没有指针保持事件状态。 另外，并非在某些情况下，V8 会在每次使用时创建一个函数实例，而这可能就是这种情况。如果两者结合，您分配的内存将不断堆积回调实例。
Objects which have survived two minor garbage collections are promoted to “old-space.” Old-space is garbage collected in full GC (major garbage collection cycle), which is much less frequent. I assume this is far fetched, but the option of you allocating faster than sweeping cycles might be considered, and thus when you trigger garbage collection manually, a full GC cycle is triggered.
To ensure fast object allocation, short garbage collection pauses, and the “no memory fragmentation V8” employs a stop-the-world, generational, accurate, garbage collector. V8 essentially stops program execution when performing a full garbage collection cycle.
这可以解释为什么V8强制进入垃圾清理时内存不会泄漏。
关于javascript - node.js v8 垃圾回收似乎没有触发，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28321015/