递归 setTimeout 调用会导致闭包链内存泄漏吗？

Question

我有以下场景：

let func = () => {
  //...
  let id = setTimeout(() => {
    console.trace();
    clearTimeout(id);
    func();
  }, 2000);
}

func();

例如，如果我们在 Chrome 控制台中运行以下代码，我们会得到以下堆栈跟踪

console.trace
(anonymous) @ VM89644:4
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
setTimeout (async)
func @ VM89644:3
(anonymous) @ VM89644:6
...
...
...

在每次迭代中不断增加。最终它达到了一个最大值（我认为在 35 次迭代之后），链 似乎 停止增长，但我很好奇它是否只是 Chrome 没有显示它。到底发生了什么？

Answer 1

递归 setTimeout 调用会导致闭包链内存泄漏吗？

没有。每次触发定时器后，浏览器中的定时器子系统都会释放它与定时器函数的链接，而定时器函数又会释放它与创建它的环境的链接，从而使它们都可以被回收。

在每次迭代中不断增加。最终它达到了一个最大值（我认为在 35 次迭代之后），链似乎停止增长，但我很好奇它是否只是 Chrome 没有显示它。到底发生了什么？

这是标准的内存管理，根据 JavaScript 引擎的内存管理启发式进行清理，并不总是主动清理。我怀疑如果你反复点击 devtools 的“收集垃圾”按钮（在内存选项卡上），你会注意到它回到了接近基线。

可能会阻止返回接近基线的一件事是 V8 的漂亮async stack traces。它们被宣传为“零成本”，但当然，这不可能完全正确，因为它们必须跟踪异步堆栈信息（即使只是作为字符串）。