基于EventEmitter3的组件代码是否存在内存泄漏风险？

问题场景代码 #

组件渲染方法 #

renderComponent(component) {
  let timeout = null;

  component.on("rerender", () => {
    clearTimeout(timeout);

    timeout = setTimeout(() => {
      // do stuff
    });
  });
}

组件卸载方法 #

unrenderComponent(component) {
  component.off('rerender');
}

组件继承自EventEmitter3，疑问点在于：当component对象变为不可达时，renderComponent内的timeout变量是否会引发内存泄漏？考虑将timeout存储到component对象中，以便组件被垃圾回收时定时器也随之回收。

内存泄漏风险分析 #

• 未调用卸载方法时的风险：timeout变量被rerender事件的回调闭包捕获，component的事件注册表会持有该回调的引用。如果未调用unrenderComponent移除监听，即使component看似不可达，也会因为事件监听的引用链无法被垃圾回收，连带timeout和未触发的定时器都会残留，造成内存泄漏。
• 正确调用卸载方法后的情况：unrenderComponent会通过off移除rerender事件的回调引用，此时回调函数失去被持有的来源，闭包中的timeout也会失去引用，最终会被垃圾回收器处理，未触发的定时器也会被清理，不会产生内存泄漏。

关于将timeout挂载到component对象的方案 #

将timeout直接挂载到component实例上（如component._rerenderTimeout = timeout）是可行的优化方案，优势如下：

1. 关联生命周期：当component对象被垃圾回收时，挂载在它上面的timeout变量也会失去引用，即便因异常情况未调用卸载方法，只要component真正不可达，相关定时器引用也会被回收。
2. 便于主动清理：可以在unrenderComponent中主动清理定时器，进一步规避风险，示例代码如下：

unrenderComponent(component) {
  component.off('rerender');
  clearTimeout(component._rerenderTimeout);
}

核心注意事项 #

• 无论采用哪种方案，必须保证组件卸载时调用unrenderComponent移除事件监听，这是避免EventEmitter系列组件内存泄漏的核心操作。
• 对于延迟较长的定时器，即使组件已不可用，未清理的定时器仍会占用资源，在卸载时主动调用clearTimeout是更稳妥的做法。

内容的提问来源于stack exchange，提问作者Jose Carlos Ramírez