17370845950

JavaScript垃圾回收由引擎自动执行，依据可达性判断对象是否可回收；V8采用Scavenge（新生代）和Mark-Sweep/Mark-Compact（老生代）算法；隐式引用如未移除的事件监听器、未清除的定时器、DOM缓存等易致内存泄漏。

JavaScript 的垃圾回收机制不是你手动控制的，它由引擎自动运行，核心目标是识别并释放那些“不再被访问”的对象所占的内存。

什么是可达性（Reachability）——垃圾回收的判断依据

引擎不靠“有没有被 delete”或“变量是否已 undefined”来决定回收，而是看一个值是否能从根（如全局对象、当前执行上下文中的局部变量、活动函数参数等）通过引用链访问到。只要可达，就不会被回收。

• let obj = { a: 1 }; → obj 是局部变量，指向的对象可达
• obj = null; → 引用断开，若无其他引用，该对象变成不可达，下次 GC 可能回收
• 闭包中捕获的外部变量，即使外层函数执行结束，只要闭包还活着，那些变量就仍可达

V8 中主要使用的两种回收算法：Scavenge 和 Mark-Sweep/Mark-Compact

V8 将堆内存分为新生代（new_space）和老生代（old_space），不同区域用不同策略，兼顾速度与空间效率。

• 新生代用 Scavenge 算法：只复制存活对象到另一块半区（from-space → to-space），原空间直接清空。快但只适合小内存、短生命周期对象
• 老生代用 Mark-Sweep（标记-清除）或 Mark-Compact（标记-整理）：先遍历标记所有可达对象，再清除未标记的；后者还会移动存活对象以减少碎片
• 频繁创建短命对象（如循环中 let arr = []）会快速填满新生代，触发 Scavenge；而长期存活对象（如全局缓存、DOM 引用）会晋升到老生代，GC 成本更高

哪些常见写法会意外阻止垃圾回收？

不是所有 null 赋值或作用域结束都能立即释放内存。真正的问题常出在隐式引用上。

立即学习“Java免费学习笔记（深入）”；

• 事件监听器没用 removeEventListener 移除，且监听函数是匿名函数 → 回调无法被解绑，绑定的目标对象（如 DOM 元素）及其闭包依赖全被持留
• 定时器（setInterval）里引用了外部大对象，且忘记 clearInterval → 定时器活跃时，回调及其中所有自由变量都保持可达
• 将 DOM 元素作为对象属性存储（如 cache[id] = element），又没在元素卸载时清理 cache → 即使元素从页面移除，JS 仍持有引用，无法被回收
• 使用 console.log(obj) 在开发者工具中展开查看后，Chrome 有时会隐式保留对该对象的引用（尤其在断点暂停时），造成“疑似内存泄漏”假象

function setupHandler() {
  const data = new Array(1000000).fill('leak');
  document.body.addEventListener('click', () => {
    console.log(data.length); // 闭包捕获 data
  });
  // ❌ 忘记 removeEventListener，data 永远不会被回收
}

真正难排查的不是“怎么触发 GC”，而是“为什么某个对象一直不被回收”。重点永远在检查引用链：谁还拿着它的引用？Chrome DevTools 的 Memory 面板 + Retainers 视图，比猜更可靠。