垃圾回收解放了我们，它让我们可将精力集中在应用程序逻辑（而不是内存管理）上。但是，垃圾收集并不神奇。了解它的工作原理，以及如何使它保留本应在很久以前释放的内存，就可以实现更快更可靠的应用程序。在本文中，学习一种定位 JavaScript 应用程序中内存泄漏的系统方法、几种常见的泄漏模式，以及解决这些泄漏的适当方法。
一、简介
当处理 JavaScript 这样的脚本语言时，很容易忘记每个对象、类、字符串、数字和方法都需要分配和保留内存。语言和运行时的垃圾回收器隐藏了内存分配和释放的具体细节。
许多功能无需考虑内存管理即可实现，但却忽略了它可能在程序中带来重大的问题。不当清理的对象可能会存在比预期要长得多的时间。这些对象继续响应事件和消耗资源。它们可强制浏览器从一个虚拟磁盘驱动器分配内存页，这显著影响了计算机的速度（在极端的情形中，会导致浏览器崩溃）。
内存泄漏指任何对象在您不再拥有或需要它之后仍然存在。在最近几年中，许多浏览器都改善了在页面加载过程中从 JavaScript 回收内存的能力。但是，并不是所有浏览器都具有相同的运行方式。Firefox 和旧版的 Internet Explorer 都存在过内存泄漏，而且内存泄露一直持续到浏览器关闭。
过去导致内存泄漏的许多经典模式在现代浏览器中以不再导致泄漏内存。但是，如今有一种不同的趋势影响着内存泄漏。许多人正设计用于在没有硬页面刷新的单页中运行的 Web 应用程序。在那样的单页中，从应用程序的一个状态到另一个状态时，很容易保留不再需要或不相关的内存。
在本文中，了解对象的基本生命周期，垃圾回收如何确定一个对象是否被释放，以及如何评估潜在的泄漏行为。另外，学习如何使用 Google Chrome 中的 Heap Profiler 来诊断内存问题。一些示例展示了如何解决闭包、控制台日志和循环带来的内存泄漏。
二、对象生命周期
要了解如何预防内存泄漏，需要了解对象的基本生命周期。当创建一个对象时，JavaScript 会自动为该对象分配适当的内存。从这一刻起，垃圾回收器就会不断对该对象进行评估，以查看它是否仍是有效的对象。
垃圾回收器定期扫描对象，并计算引用了每个对象的其他对象的数量。如果一个对象的引用数量为 0（没有其他对象引用过该对象），或对该对象的惟一引用是循环的，那么该对象的内存即可回收。图 1 显示了垃圾回收器回收内存的一个示例。
图 1. 通过垃圾收集回收内存
看到该系统的实际应用会很有帮助，但提供此功能的工具很有限。了解您的 JavaScript 应用程序占用了多少内存的一种方式是使用系统工具查看浏览器的内存分配。有多个工具可为您提供当前的使用，并描绘一个进程的内存使用量随时间变化的趋势图。
例如，如果在 Mac OSX 上安装了 XCode，您可以启动 Instruments 应用程序，并将它的活动监视器工具附加到您的浏览器上，以进行实时分析。在 Windows® 上，您可以使用任务管理器。如果在您使用应用程序的过程中，发现内存使用量随时间变化的曲线稳步上升，那么您就知道存在内存泄漏。
观察浏览器的内存占用只能非常粗略地显示 JavaScript 应用程序的实际内存使用。浏览器数据不会告诉您哪些对象发生了泄漏，也无法保证数据与您应用程序的真正内存占用确实匹配。而且，由于一些浏览器中存在实现问题，DOM 元素（或备用的应用程序级对象）可能不会在页面中销毁相应元素时释放。视频标记尤为如此，视频标记需要浏览器实现一种更加精细的基础架构。
人们曾多次尝试在客户端 JavaScript 库中添加对内存分配的跟踪。不幸的是，所有尝试都不是特别可靠。例如，流行的 stats.js 包由于不准确性而无法支持。一般而言，尝试从客户端维护或确定此信息存在一定的问题，是因为它会在应用程序中引入开销且无法可靠地终止。
理想的解决方案是浏览器供应商在浏览器中提供一组工具，帮助您监视内存使用，识别泄漏的对象，以及确定为什么一个特殊对象仍标记为保留。
目前，只有 Google Chrome（提供了 Heap Profile）实现了一个内存管理工具作为它的开发人员工具。我在本文中使用 Heap Profiler 测试和演示 JavaScript 运行时如何处理内存。
三、分析堆快照
在创建内存泄漏之前，请查看一次适当收集内存的简单交互。首先创建一个包含两个按钮的简单 HTML 页面，如清单 1 所示。
清单 1. index.html