如何理解javascript的垃圾回收机制_哪些操作会导致内存泄漏?

JavaScript垃圾回收通过标记-清除算法判断对象是否可回收:从全局对象等根出发,递归标记所有可达对象,未被标记的即不可达而被回收;循环引用问题使引用计数法被弃用。

JavaScript 垃圾回收怎么判断一个对象该被回收?

JavaScript 的垃圾回收器(GC)不靠程序员手动释放,而是自动运行。它主要用 标记-清除(Mark-and-Sweep) 算法:从全局对象(windowglobalThis)、当前执行上下文的局部变量等“根”出发,递归标记所有能访问到的对象;没被标记的,就被判定为不可达,随后被清除。

注意:引用计数(Reference Counting) 在早期 IE 中用过,但因无法处理循环引用(比如 a.ref = b; b.ref = a)已被主流引擎弃用。现代 V8、SpiderMonkey、JavaScriptCore 全部基于标记-清除或其变种(如 V8 的分代式 GC + 增量标记)。

所以关键不是“谁创建了对象”,而是“还有没有活的引用链能触达它”。只要存在一条从根出发的引用路径,哪怕你已经不用它了,它也不会被回收。

闭包不小心保留了外层作用域,是最常见的泄漏源头

闭包本身不是问题,问题在于闭包函数长期存活,又持有对外层变量的引用,而这些变量本该随外层函数结束而消失。

  • 典型场景:事件监听器里用了闭包,但监听器没被移除(比如绑定在 document 上),导致整个外层作用域被钉住
  • 定时器回调中引用了大数组或 DOM 节点,且 setTimeout/setInterval 没被 clearTimeout/clearInterval 清理
  • 把局部变量赋给全局对象(如 window.cache = bigData),或者意*到 this 上(类方法未绑定时,被当作普通函数调用,this 指向全局)
function createHandler() {
  const hugeArray = new Array(1000000).fill('data');
  return function() {
    console.log(hugeArray.length); // 闭包捕获了 hugeArray
  };
}
const handler = createHandler();
// 如果 handler 被长期持有(比如设为某个按钮的 onclick),hugeArray 就不会被回收

DOM 引用没清理,尤其在单页应用中特别危险

DOM 节点被 JS 引用时,即使它已从文档中 remove()innerHTML = '' 清空,只要 JS 还有变量指向它,它和它的整个子树就仍在内存中。

  • 缓存 DOM 节点但忘记在组件卸载时清空(React 中未在 useEffect 的 cleanup 函数里解绑,Vue 中未在 beforeUnmount 里清理)
  • 使用 addEventListener 绑定了匿名函数,后续无法用 removeEventListener 移除(因为匿名函数每次都是新引用)
  • MapWeakMap 存储 DOM 相关元数据时,误用了强引用的 Map —— 应优先用 WeakMap,它不会阻止键所指 DOM 被回收
// ❌ 错误:用 Map 持有 DOM 节点作为 key → 节点无法被 GC
const metadataMap = new Map();
metadataMap.set(document.getElementById('app'), { timestamp: Date.now() });

// ✅ 正确:WeakMap 不会阻止 key(DOM 节点)被回收
const metadataWM = new WeakMap();
metadataWM.set(document.getElementById('app'), { timestamp: Date.now() });

哪些操作看起来 harmless,其实悄悄吃内存?

有些写法看似无害,但在高频或长生命周期场景下会累积泄漏:

  • console.log(obj) 在 Chrome DevTools 打开时,会保持对 obj 的引用(用于后续展开查看),关闭控制台后才可能释放 —— 生产环境不影响,但调试时别 log 大对象
  • 频繁生成并丢弃正则对象(如 /pattern/g 字面量在循环里),V8 会缓存它们,但缓存有上限;更稳妥的是复用 RegExp 实例(new RegExp('pattern', 'g'))并手动管理
  • 使用 evalFunction 构造函数动态创建函数,会创建无法被静态分析的作用域链,干扰 GC 判断
  • Web Workers 中未正确关闭或未 postMessage 后及时 terminate(),Worker 实例及其全部堆内存持续驻留

真正难排查的泄漏,往往不是某一行代码,而是多个小引用叠加形成的“引用网”——比如一个未注销的事件监听器 → 持有回调函数 → 回调闭包引用了组件实例 → 实例上有对 DOM 和数据的引用。得用 Chrome DevTools 的 Memory 面板拍快照、对比、筛选 Detached DOM tree,才能定位到根因。