闭包本身不被标记清除，真正回收的是其引用的变量对象；只要变量不可达（无任何活跃引用），GC 就会回收它。闭包存活取决于内部函数是否被全局变量、事件监听器、定时器等持有，一旦这些引用断开，相关变量即刻进入回收队列。
闭包本身不会“被标记清除”，真正被回收的是闭包所引用的变量对象（即词法环境中的数据），前提是这些变量已无任何活跃引用。JavaScript 的垃圾回收（GC）不直接针对“闭包”这个概念，而是基于可达性分析——只要某个变量对象无法从根（如全局对象、当前执行上下文、寄存器中的引用等）被访问到，它就可能被标记为可回收。
闭包存活的关键：外部引用是否还存在
闭包的本质是内部函数持有了对外部函数词法环境的引用。只要这个内部函数仍被引用（比如被赋值给全局变量、作为回调保存在事件监听器中、或被其他闭包间接持有），那么它所捕获的变量对象就不会被回收。
- 若返回的函数未被任何地方持有（例如未赋值、未传入异步操作），V8 等引擎通常能在函数调用结束后立即识别其不可达，相关闭包环境随之进入待回收队列
- 若函数被赋值给全局变量 const fn = outer() ，则闭包环境持续存活，直到 fn 被显式设为 null 或超出作用域
- 常见泄漏场景：DOM 事件监听器中使用闭包，但忘记 removeEventListener；或定时器回调引用了大对象，却未清理 clearInterval
V8 中的回收机制：主垃圾回收器（Mark-Sweep）与增量标记
主线程空闲时，V8 的主 GC 会启动标记-清除流程。它从根集出发遍历所有可达对象，标记活跃内存；未被标记的对象在清除阶段释放。闭包关联的上下文对象（Context）和堆内变量（如闭包捕获的数组、对象）都参与该过程。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 闭包变量若只被该闭包引用，且闭包函数本身不可达 → 整个变量对象会被一并标记回收
- 若闭包变量同时被其他对象引用（例如被全局对象属性引用），则仅闭包函数不可达时，变量对象仍存活
- V8 使用增量标记（Incremental Marking）将长耗时的标记拆成小任务，在主线程空闲帧中执行，避免卡顿
如何验证闭包是否已被回收？
实际开发中无法直接观测“某次 GC 是否清除了某闭包”，但可通过 Chrome DevTools 的 Memory 面板辅助判断：
立即学习“Java免费学习笔记（深入）”；
- 录制堆快照（Heap Snapshot），筛选 Closure 类型对象，对比操作前后数量变化
- 使用 console.memory 观察 usedJSHeapSize 波动，配合强制 GC（DevTools 的垃圾桶图标）观察回落情况
- 注意：即使手动触发 GC，也不保证立即回收所有不可达对象，引擎会根据内存压力和策略决定时机
写闭包时减少回收负担的小建议
不必手动“清理闭包”，但可主动切断不必要的引用链，帮助 GC 更早识别不可达对象：
- 在不再需要闭包功能时，将引用设为 null（尤其对大型缓存对象）
- 避免在闭包中无意捕获整个外部作用域；可用局部常量提前提取必要值，减少闭包捕获范围
- 异步回调中慎用 this 或大型实例，改用参数传递或弱引用（WeakMap）管理依赖关系
