闭包的“连坐”悬案：一个内存泄漏引发的血案

第一章：案发现场

夜深了，我还在吭哧吭哧地写代码。突然，监控系统发来警报：内存占用率飙升！

我心里一惊，赶紧冲到案发现场。经过一番排查，我把嫌疑锁定在了一段看似人畜无害的代码上：

function demo() {
  // 一个 100MB 的大胖子
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  // 一个 1 秒后执行的定时器，用到了大胖子
  const id = setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);

  // 返回一个清理函数，用来取消定时器
  return () => clearTimeout(id);
}

// 把清理函数挂到全局，以便随时调用
globalThis.cancelDemo = demo();

我百思不得其解。这段代码的逻辑很清晰：

1. demo 函数执行，创建了一个 100MB 的大胖子 bigArrayBuffer。
2. 一个 setTimeout 在 1 秒后会用一下这个大胖子。
3. demo 函数返回了一个 cancelDemo 函数，这个函数只认识 id，根本不认识 bigArrayBuffer。

我的推理是：1 秒钟之后，setTimeout 的回调执行完毕，再也没有人认识 bigArrayBuffer 了。它应该被垃圾回收（GC）大叔带走，释放那 100MB 的宝贵内存。

但现实是残酷的。bigArrayBuffer 像个钉子户，永远地赖在了内存里！

为什么？难道是 GC 大叔偷懒了？还是 V8 引擎出了 Bug？

为了搞清楚真相，我决定从头开始，审问每一个嫌疑人。

第二章：排除嫌疑

我写了几个简单的变种，想看看 GC 大叔到底是怎么想的。

嫌疑人 A：最简单的函数

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);
  console.log(bigArrayBuffer.byteLength);
}

demo();

结果 ：demo 函数一执行完，bigArrayBuffer 立刻被回收。内存瞬间恢复正常。

结论：GC 大叔很敬业，人走茶凉，绝不含糊。嫌疑人 A 无罪释放。

嫌疑人 B：只有 setTimeout

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);
}

demo();

结果 ：demo 函数执行完后，bigArrayBuffer 并没有马上被回收。GC 大叔很有耐心，它知道 1 秒后还有人要用它。等到 setTimeout 的回调执行完毕，bigArrayBuffer 才被带走。

结论：GC 大叔不仅敬业，还很智能，能预判未来的使用情况。嫌疑人 B 也无罪。

嫌疑人 C：返回的函数不引用任何东西

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  const id = setTimeout(() => {
    console.log("hello"); // 注意，这里没用大胖子
  }, 1000);

  return () => clearTimeout(id);
}

globalThis.cancelDemo = demo();

结果 ：bigArrayBuffer 在 demo 函数执行完后立刻被回收！

结论 ：GC 大叔简直是火眼金睛！它通过静态分析发现，虽然 demo 函数里有一堆内部函数，但没有一个真正用到了 bigArrayBuffer。于是它大笔一挥："此物无用，收走！"

到这里，我更糊涂了。GC 大叔明明这么聪明，为什么在最初的案发现场就"失手"了呢？

第三章：真相大白

我把最初的案发现场代码又看了一遍，感觉自己漏掉了什么关键线索。

function demo() {
  // 作用域开始
  const bigArrayBuffer = new ArrayBuffer(100_000_000);
  const id = setTimeout(/* ... */);
  return () => clearTimeout(id);
  // 作用域结束
}

问题就出在 作用域（Scope）上。

在 JavaScript 的世界里，当 demo 函数被调用时，它会创建一个自己的"小世界"，也就是它的作用域。这个小世界里住着它所有的孩子：bigArrayBuffer、id、setTimeout 的回调函数，还有那个被 return 出去的匿名函数。

GC 大叔的回收原则，和我们想的不太一样。它不是一个一个地检查变量是否需要回收，而是以"作用域"为单位进行回收。

你可以把一个作用域想象成一个"家庭"。GC 大叔的规则是：

只要这个家庭里还有任何一个成员（函数）在外面有"关系"（能被外界访问到），那整个家庭（作用域）就得给我好好地待在内存里，一个都不能少！

这就是闭包的"连坐"制度！

现在，我们再来看看案发现场：

1. demo 函数执行，创建了一个作用域"家庭"。家庭成员有：bigArrayBuffer、id、定时器回调、返回的清理函数。
2. 定时器回调函数引用了 bigArrayBuffer，所以 bigArrayBuffer 被留在了这个家庭里。
3. demo 函数把"清理函数" () => clearTimeout(id) 返回给了外界，并赋值给了 globalThis.cancelDemo。这意味着，这个清理函数在外面有了"关系"，它还活着！
4. GC 大叔来检查了。它发现 cancelDemo 这个家庭成员还活着，于是它大手一挥："这个家庭不能动！所有人原地待命！"

于是，整个 demo 函数的作用域都被保留了下来。

bigArrayBuffer 就这样，被无情地"连坐"了。即使 1 秒后，那个唯一引用它的定时器回调已经执行完毕，变成了"死人"，但只要 cancelDemo 这个"活人"还在，bigArrayBuffer 作为它的家庭成员，就必须陪着它一起留在内存里。

它就像一个无辜的路人，只是因为和某个"大人物"住在同一个小区，结果整个小区都被保护了起来，它也出不去了。

第四章：一荣俱荣，一损俱损

为了验证这个"连坐"理论，我又设计了一个更极端的实验：

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  // 大儿子，认识大胖子
  globalThis.innerFunc1 = () => {
    console.log(bigArrayBuffer.byteLength);
  };

  // 二儿子，不认识大胖子
  globalThis.innerFunc2 = () => {
    console.log("hello");
  };
}

demo();

现在，demo 家庭有两个儿子被送到了外面，都还活着。

接着，我把大儿子干掉：

globalThis.innerFunc1 = undefined;

现在，唯一认识 bigArrayBuffer 的函数已经没了。按理说，bigArrayBuffer 应该可以被回收了吧？

并不会！

因为二儿子 innerFunc2 还活着！GC 大叔一看，这个家庭还有后代在外面，于是整个家庭继续保留。bigArrayBuffer 再次被"连坐"。

只有当我把二儿子也干掉时：

globalThis.innerFunc2 = undefined;

现在，demo 家庭在外面已经没有任何"关系"了。GC 大叔终于可以放心地把整个作用域连锅端了。bigArrayBuffer 这才得以解脱。

这个发现令人震惊：闭包变量的生命周期，取决于"最后一个兄弟"的生命周期，而不是它自己的！

第五章：引擎的辩护

你可能会问：V8 引擎为什么设计得这么"蠢"？为什么不能更智能一点，只保留那些被真正引用的变量呢？

这是一个跨浏览器都存在的问题，而且很可能不会被修复。原因很简单：性能。

要做得更精细，就意味着 GC 大叔的工作量会大大增加。它不仅要检查哪个家庭还有后代，还得去调查每个后代到底和家里的哪些东西有联系。这个"尽职调查"的成本太高了，会让整个 JavaScript 的执行效率变慢。

所以，引擎的设计者们做了一个权衡：用一个简单粗暴但高效的"连坐"规则，换取整体的性能。在大多数情况下，这个规则都没问题。只是在某些特定的闭包场景下，会造成意想不到的内存泄漏。

第六章：如何破解"连坐"？

既然我们知道了"连坐"的规则，那破解它也就有了思路。

方案一：斩草除根

既然问题是 cancelDemo 这个"活口"导致的，那我们就在用完它之后，把它干掉！

// 用完了，或者确定不需要了
globalThis.cancelDemo = null;

一旦 cancelDemo 被设置为 null，demo 家庭在外面就再也没有任何"关系"了。GC 大叔会立刻把整个作用域回收，bigArrayBuffer 自然也就被释放了。

方案二：分家！

既然"连坐"是按"家庭"来的，那我们就把它们分成不同的家庭！

function demo() {
  let cancel;

  // 家庭 A：只负责定时器
  {
    const id = setTimeout(() => {
      console.log("hello");
    }, 1000);
    cancel = () => clearTimeout(id);
  }

  // 家庭 B：只负责大胖子
  {
    const bigArrayBuffer = new ArrayBuffer(100_000_000);
    console.log(bigArrayBuffer.byteLength);
  }

  return cancel;
}

globalThis.cancelDemo = demo();

在这个版本里，我们用 {} 创建了两个独立的块级作用域。

• bigArrayBuffer 住在"家庭 B"。这个家庭没有任何成员被暴露到外面，所以 demo 函数一执行完，家庭 B 就被整个回收了。
• cancel 函数来自"家庭 A"。它虽然活了下来，但它的家庭成员里根本没有 bigArrayBuffer。

这样一来，bigArrayBuffer 就不会被"连坐"了。

尾声：闭包的江湖

在 JavaScript 的江湖里，闭包是一个神奇的存在。它赋予了函数记忆的能力，但也带来了复杂的"社会关系"。

今天这个悬案告诉我们：

在闭包的世界里，一个变量能否被释放，不仅取决于它自己是否还在被使用，更取决于和它"同住一个屋檐下"的兄弟姐妹们，是否都已经"功成身退"。

所以，下次当你创建一个闭包时，特别是当它要和一个大对象共处一室时，请多留一个心眼。问问自己：那个即将被你 return 出去的函数，它的兄弟姐妹们都安排好了吗？

否则，下一个内存泄漏的案发现场，可能就在你的代码里。

---