JavaScript垃圾回收通过标记-清除自动释放不可达对象内存，但全局变量残留、未清除定时器、未解绑事件监听器、闭包过度持有及控制台日志等会导致内存泄漏。
JavaScript 的垃圾回收机制（Garbage Collection，GC）是引擎自动管理内存的过程：它会定期识别并释放那些**不再被程序访问的变量、对象所占用的内存**。开发者不用手动 free 内存，但若理解不到位，就容易造成内存泄漏——即本该被回收的对象一直留在内存中，导致内存占用持续升高、页面变卡甚至崩溃。
常见的垃圾回收算法：标记-清除
现代 JavaScript 引擎（如 V8）主要用“标记-清除”（Mark-and-Sweep）方式：
从一组根对象（如全局变量、当前执行函数的局部变量、DOM 元素引用等）出发，递归标记所有能被访问到的对象； 未被标记的对象被视为“不可达”，随后被清除并回收内存。
注意：引用计数（Reference Counting）曾被部分老引擎使用，但它无法处理循环引用问题（比如两个对象互相引用），V8 等主流引擎已不依赖它。
典型内存泄漏场景及原因
以下情况会让对象意外保持“可达”，逃过垃圾回收：
立即学习“Java免费学习笔记（深入）”；
全局变量残留：无意中给全局对象（window 或 globalThis）挂载了大对象或回调函数，比如 window.cacheData = hugeArray，后续忘了清理； 定时器未清除：用 setInterval 或 setTimeout 时，回调函数里闭包引用了外部大对象，且定时器没被 clearInterval 清除，该回调和它捕获的变量就一直存活； 事件监听器未解绑：给 DOM 元素添加了事件监听器（如 btn.addEventListener('click', handler)），但元素被移除后没调用 removeEventListener，handler 及其闭包中的数据仍被持有； 闭包过度持有：内部函数长期存在（如暴露给全局或存入缓存），又引用了外层作用域的大对象（如整个 DOM 节点、大型数组），外层变量无法释放； 控制台日志保留引用：在 Chrome DevTools 中用 console.log(obj) 打印一个大对象后，即使代码里已无引用，控制台仍可能隐式持有它（尤其展开查看过），影响 GC 判断（仅开发环境需注意）。
如何检测和验证内存泄漏
录制堆快照（Heap Snapshot）：操作前拍一张，操作后（如打开关闭模块多次）再拍一张，对比“#Objects”和“Shallow Size”变化； 查看“Retainers”：选中疑似泄漏的对象，看谁在引用它（比如某个闭包、事件监听器、全局变量）； 使用 Allocation Instrumentation on Timeline：记录内存分配过程，观察是否有持续增长且不下降的构造函数（如反复创建未销毁的类实例）。
简单验证法：强制触发 GC（DevTools → Memory → Collect garbage 按钮），再看内存是否回落。若多次操作后内存只升不降，大概率存在泄漏。
基本上就这些。垃圾回收本身很可靠，问题往往出在我们“以为对象已失效”，其实还被某处悄悄引用着。写代码时多问一句：“这个对象什么时候该被释放？谁还在拿着它？” 就能避开大多数坑。
以上就是JavaScript中什么是垃圾回收机制_内存泄漏场景的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1543377.html
微信扫一扫 
支付宝扫一扫 
