现代JavaScript及Node.js中Garbage Collection手动置空必要性疑问

直接结论 #

你给出的代码场景下，手动将data赋值为null是有必要的，是最稳妥的满足你内存释放需求的写法。

具体原因分析 #

1. 引擎自动提前回收的不确定性 #

Node.js基于V8引擎实现垃圾回收，GC的核心判断规则是对象的可达性：如果一个对象没有被任何存活的引用指向，就会被标记为可回收。
理论上现代V8确实会做逃逸分析、死代码检测类的优化，能识别到部分后续不再使用的变量，提前切断其引用链允许回收，但这个属于引擎的非强制性优化行为，ECMAScript标准没有要求所有场景都必须实现该逻辑，V8官方也没有明确给出这种提前回收的适用边界，实际运行中可能会因为代码结构、编译优化等级、闭包引用等多种因素失效，不能作为100%可靠的依赖。
你给出的代码中data的作用域覆盖了整个async函数的生命周期，只要async函数还没执行结束（longAsyncFunction的回调没执行完之前，async函数都处于存活状态），如果没有手动切断引用，引擎有可能不会主动把data指向的大Blob对象标记为不可达，导致内存无法提前释放。

2. 手动赋值null的确定性 #

你主动执行data = null的操作，相当于显式切断了变量和原Blob对象之间的引用链，此时原Blob对象直接变成不可达状态，不管引擎是否做提前回收的优化，下次GC运行时一定会回收这部分内存，完全符合你要在longAsyncFunction运行期间释放内存的需求，且写法成本极低，没有任何副作用。

替代写法 #

如果你不想手动赋值null，也可以通过缩小data的作用域来达到同样的效果：

(async() => {
  // 将data的使用限制在独立的async作用域内
  const name = await (async () => {
    let data = await getBigBlobFile()
    return data.name
  })()

  longAsyncFunction(name, (err, res) => {
    if (err) throw err
    return res
  })
})()

这种写法下data仅存在于内层的async立即执行函数作用域中，内层函数执行结束后data就脱离了作用域链，不需要手动赋值null也会被引擎标记为不可达。

额外说明 #

GC的触发时机本身由V8引擎自动控制，就算对象已经变成不可达，也不会立刻被回收，只会在下次GC调度时处理。如果是测试场景需要验证内存释放效果，可以给Node.js加--expose-gc启动参数，主动调用global.gc()触发全量GC。

内容的提问来源于stack exchange，提问作者thurasw