JavaScript垃圾回收机制详解与内存泄漏排查

从现在开始，努力学习吧！本文《JavaScript垃圾回收机制解析及内存泄漏原因分析》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

现代 JavaScript 引擎不使用引用计数，而是以标记-清除为主，辅以增量标记和分代式垃圾回收；引用计数因无法处理循环引用已被弃用。

JavaScript 垃圾回收靠的是引用计数还是标记清除？

现代 JavaScript 引擎（V8、SpiderMonkey、JavaScriptCore）**不使用引用计数**，而是以标记-清除（Mark-and-Sweep）为主，辅以增量标记（Incremental Marking）和分代式垃圾回收（Generational GC）优化。引用计数因无法处理循环引用（如 a.ref = b; b.ref = a）早已被弃用。

引擎会定期启动 GC：先从根对象（全局对象、当前执行上下文中的局部变量、栈中引用等）出发，递归标记所有可达对象；未被标记的即为“不可达”，随后被清除。

• 全局变量、闭包中被捕获的变量、DOM 节点引用、定时器回调中的外层作用域变量 都可能让对象长期“可达”，阻碍回收
• V8 将对象分为新生代（Young Generation）和老生代（Old Generation），小对象先分配在新生代，多次存活后晋升到老生代——老生代 GC 成本更高，更需避免无谓驻留
• 频繁触发 GC（如每秒多次）往往意味着内存压力大，可通过 Chrome DevTools 的 Memory > Allocation instrumentation on timeline 追踪对象生命周期

闭包意外保留大对象是常见泄漏源

闭包本身不是问题，但若内部函数被意外长期持有（比如挂到全局、传给事件监听器、塞进定时器），它所捕获的整个外层作用域就无法释放。

function createHandler() {
  const bigData = new Array(1000000).fill('leak');
  return function () {
    console.log('still alive');
  };
}
// ❌ 错误：handler 持有对 bigData 的引用，即使不用 bigData 也回不去了
const handler = createHandler();
window.importantHandler = handler; // 意外挂载到全局

• 检查闭包是否真的需要捕获全部变量：可用let或const缩小作用域，或显式解构提取必要值
• 避免把闭包赋值给window、document或长期存在的对象（如单例类实例）
• 使用WeakMap或WeakRef（ES2021）缓存关联数据，它们不阻止回收

事件监听器和 DOM 引用没清理就会卡住整棵子树

只要一个 JS 对象还引用着某个 DOM 元素，该元素及其所有子节点（包括内联事件、CSS 样式、布局信息）都无法被回收——哪怕它已从文档中remove()。

• 手动绑定的事件监听器必须配对调用removeEventListener()，尤其注意匿名函数无法移除：el.addEventListener('click', fn) ✅，el.addEventListener('click', () => {}) ❌
• 使用AbortController统一控制多个异步操作和监听器：addEventListener(..., { signal })
• 框架组件卸载时（如 React useEffect cleanup、Vue beforeUnmount），务必清理定时器、IntersectionObserver、ResizeObserver 等持有 DOM 引用的实例

定时器和 Promise 微任务链容易隐式延长生命周期

setTimeout、setInterval、未处理的Promise拒绝、requestIdleCallback 回调里的闭包，都会让其作用域持续存活。

function startPolling() {
  const cache = {};
  setInterval(() => {
    fetch('/api/data').then(res => {
      cache[Date.now()] = res; // cache 不断增长
      // ❌ 忘记清理过期项，也不清除定时器
    });
  }, 5000);
}
startPolling(); // cache 和定时器 ID 永远不会被回收

• 总是保存setInterval返回的 ID，并在不需要时调用clearInterval(id)
• 避免在定时器回调中累积数据结构（如Array.push、Map.set），或设置自动淘汰策略（LRU、TTL）
• 未捕获的Promise拒绝会留在微任务队列中，虽不直接阻止对象回收，但可能掩盖真正泄漏点；用window.addEventListener('unhandledrejection')监控

最隐蔽的泄漏往往不在代码逻辑里，而在你认为“它应该自己消失”的地方——比如一个被遗忘的console.log(obj)会让obj在 DevTools 控制台中保持引用，直到你刷新或清空控制台。

到这里，我们也就讲完了《JavaScript垃圾回收机制详解与内存泄漏排查》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！