闭包会延长外层变量生命周期，使其无法被gc回收，因闭包持有对词法环境的引用；常见泄漏场景包括缓存类闭包、未解绑事件监听器和未清除的定时器回调。

闭包会延长内部变量的生命周期，让本该被回收的对象持续“可达”，从而影响垃圾回收行为——不是 GC 失效了，而是你无意中给它留了一条引用链。

闭包让局部变量“活下来”

函数执行结束后，其执行上下文通常被销毁，栈中局部变量随之释放。但如果函数返回了一个内部函数（即闭包），且该内部函数引用了外层函数的变量，这些变量就无法被 GC 回收。

• 引擎判断“是否可达”的依据是：能否从全局对象、调用栈等根出发，顺着引用链访问到该变量
• 闭包形成的引用链，相当于在外层函数退出后，仍有一个活跃的函数体在“持有”那些变量
• 哪怕只捕获了一个小变量，只要闭包长期存在，整个外层作用域的变量都可能被一并保留

常见导致内存滞留的闭包模式

有些写法看似无害，实则悄悄阻止 GC 清理大块内存：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 缓存类闭包：比如用 IIFE 封装一个 map 对象，返回增删查方法——map 本身和所有已存数据都会一直驻留
• 事件处理器中的 this 绑定：在 class 方法里用箭头函数或 bind(this)，若未手动解绑，DOM 节点卸载后，this 实例仍被监听器引用
• 定时器回调闭包：setInterval 中引用了外部大数组或 DOM 节点，又没在合适时机 clear，该数组就一直不可回收

怎么判断是不是闭包引起的泄漏

别依赖 console.log 或 DevTools 的实时快照，它们本身会临时保留引用。更可靠的方式是：

• 在 Performance 面板录制一段操作，看内存占用是否阶梯式上升且不回落
• 用 Memory 面板拍 Heap Snapshot，筛选 Constructor 名，对比多次快照中同类型对象数量是否持续增加
• 检查是否存在“Detached DOM tree”但仍有 JS 引用指向它——典型就是事件监听器未移除 + 闭包捕获
• 对疑似闭包函数，尝试手动置 null 或用 WeakMap 替代强引用缓存

可控使用闭包的实践建议

闭包本身不是问题，问题在于引用关系是否必要且可控：

• 避免在闭包中直接捕获整个大对象，改用结构化提取所需字段
• 监听器绑定后，务必在组件卸载或节点移除时调用 removeEventListener
• 需要长期缓存时，优先考虑 WeakMap（键是弱引用，不阻止回收）而非普通 Object
• 定时任务用完及时 clear，或改用 requestIdleCallback 等更轻量的调度方式

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南