垃圾回收在javascript中如何工作_怎样编写高效代码【教程】_技术教程

JavaScript垃圾回收由引擎自动执行，采用标记-清除为主、引用计数为辅的策略；根对象出发标记可达值，未标记者被清除；全局变量、未解绑事件监听器、未清理定时器及闭包中意外持有对象是常见泄漏源。

JavaScript 的垃圾回收是自动的，你无法手动触发或控制具体回收时机，但可以显著影响回收效率和内存驻留时间。关键不是“怎么调用 GC”，而是“怎么让引擎更快识别哪些值该被回收”。

哪些值会被自动回收？

JavaScript 使用标记-清除（Mark-and-Sweep）为主、辅以引用计数（仅用于循环引用检测优化）的混合策略。引擎会从一组根对象（如全局对象、当前执行上下文中的局部变量、闭包中捕获的变量）出发，递归标记所有可达值；未被标记的即为“不可达”，随后被清除。

常见误判场景：

全局变量或 window / globalThis 上意*载的对象永远不会被标记为不可达
事件监听器未 removeEventListener，且回调引用了外部大对象 → 该对象因被闭包持有而长期驻留
setTimeout 或 setInterval 的回调持续存活，其作用域链中的变量无法释放
数组或 Map 中保留已失效的引用（如已卸载组件的实例），即使逻辑上不再需要

`delete` 和赋值为 `null` 的区别

delete 操作符只对对象属性有效，它移除属性本身（包括键），但不保证立即释放内

存——如果其他地方仍有对该值的引用，值依然存活。

赋值为 null 是更直接的“断开引用”方式，尤其适用于局部变量、对象字段、数组元素：

let bigData = new Array(1000000).fill('payload');
// ✅ 主动释放引用
bigData = null;

const obj = { data: bigData };
obj.data = null; // 比 delete obj.data 更明确地切断引用

注意：delete obj.data 后，obj.data 变成 undefined，但若 bigData 还被其他变量持有，它仍不会被回收。

闭包与定时器：最隐蔽的内存泄漏源

闭包天然延长变量生命周期。问题不在闭包本身，而在“本该结束却没结束”的闭包。

典型模式：

异步回调（如 fetch）中引用了大型 DOM 元素或组件实例，但请求完成时组件早已 unmount
setInterval 回调里持续访问已销毁对象的属性（如 this.state）
为 DOM 元素绑定事件后，未在元素移除时清理监听器，且监听器是闭包形式

解决方式不是避免闭包，而是加“存活检查”或“清理钩子”：

let timerId;
function startLoop() {
  timerId = setInterval(() => {
    if (!this.isValid) return; // ✅ 提前退出
    doSomething(this.data);
  }, 1000);
}
// 卸载时：
clearInterval(timerId);
this.isValid = false;