javascript - Node.js (v8) 垃圾收集器如何工作？

Question

我已经对我的 node.js 应用程序进行了一些测试，以寻找我的代码应该做的内存泄漏。我运行的脚本在我看来应该会泄漏内存，但我对结果感到惊讶。

redisClient.on('message', initRequest);

function onSuccess(self, json){
    console.dir(json);
}

function initRequest(channel, message){

  var request = new RequestObject({
      redisMessage: message
  });
  
  request.on('success', onSuccess);

}

redisClient 每秒发出几个“消息”事件。这意味着 initRequest 函数被经常调用。每次在内存中创建 request 对象，函数 onSuccess 都会绑定(bind)到它的“成功”事件。

我假设(但在这里我可能错了)，只要有监听器(在这种情况下为 onSuccess)绑定(bind)到这个对象，它就不能被垃圾收集。然后我想，内存使用量会增加，因为内存不会被释放。

作为这种潜在泄漏的解决方案，我想使用 .once 而不是 .on，因为这将取消绑定(bind)监听器并且对象可能会被垃圾回收。

我已经使用 pmap 来测试这两种场景(比较 .on 和 .once 以及另一个不值得一提的场景这里)，我没有发现很大的不同。

总结一下我有2个问题:

1. 这种正常的 GC 行为是在某些时间间隔内清理内存，还是在达到某个阈值后而不是连续清理？

2. 我是否正确假设带有 .on 的示例代码应该泄漏内存，而我在内存消耗图表上看不到？

Answer 1

1: 是的:-)

2:一般来说，使用事件监听器时的内存泄漏是阻止了正在监听的对象被垃圾回收，因为发出的对象保留了对它的引用。

所以在您的代码中，您的 request 对象将引用 onSuccess 函数。但是，onSuccess 只是一个函数，它被用作所有请求对象的监听器，因此不会导致内存累积。

旁注:我不知道 redisClient 和 RequestObject 的内部结构，但在我看来，request 似乎也准备好了initRequest 函数完成后立即进行垃圾收集，这可能是在调用其任何监听器之前。