垃圾回收解放了我们，它让我们可将精力集中在应用程序逻辑（而不是内存管理）上。但是，垃圾收集并不神奇。了解它的工作原理，以及如何使它保留本应在很久以前释放的内存，就可以实现更快更可靠的应用程序。在本文中，学习一种定位 JavaScript 应用程序中内存泄漏的系统方法、几种常见的泄漏模式，以及解决这些泄漏的适当方法。
一、简介
当处理 JavaScript 这样的脚本语言时，很容易忘记每个对象、类、字符串、数字和方法都需要分配和保留内存。语言和运行时的垃圾回收器隐藏了内存分配和释放的具体细节。
许多功能无需考虑内存管理即可实现，但却忽略了它可能在程序中带来重大的问题。不当清理的对象可能会存在比预期要长得多的时间。这些对象继续响应事件和消耗资源。它们可强制浏览器从一个虚拟磁盘驱动器分配内存页，这显著影响了计算机的速度（在极端的情形中，会导致浏览器崩溃）。
内存泄漏指任何对象在您不再拥有或需要它之后仍然存在。在最近几年中，许多浏览器都改善了在页面加载过程中从 JavaScript 回收内存的能力。但是，并不是所有浏览器都具有相同的运行方式。Firefox 和旧版的 Internet Explorer 都存在过内存泄漏，而且内存泄露一直持续到浏览器关闭。
过去导致内存泄漏的许多经典模式在现代浏览器中以不再导致泄漏内存。但是，如今有一种不同的趋势影响着内存泄漏。许多人正设计用于在没有硬页面刷新的单页中运行的 Web 应用程序。在那样的单页中，从应用程序的一个状态到另一个状态时，很容易保留不再需要或不相关的内存。
在本文中，了解对象的基本生命周期，垃圾回收如何确定一个对象是否被释放，以及如何评估潜在的泄漏行为。另外，学习如何使用 Google Chrome 中的 Heap Profiler 来诊断内存问题。一些示例展示了如何解决闭包、控制台日志和循环带来的内存泄漏。
二、对象生命周期
要了解如何预防内存泄漏，需要了解对象的基本生命周期。当创建一个对象时，JavaScript 会自动为该对象分配适当的内存。从这一刻起，垃圾回收器就会不断对该对象进行评估，以查看它是否仍是有效的对象。
垃圾回收器定期扫描对象，并计算引用了每个对象的其他对象的数量。如果一个对象的引用数量为 0（没有其他对象引用过该对象），或对该对象的惟一引用是循环的，那么该对象的内存即可回收。图 1 显示了垃圾回收器回收内存的一个示例。
垃圾收集回收内存
看到该系统的实际应用会很有帮助，但提供此功能的工具很有限。了解您的 JavaScript 应用程序占用了多少内存的一种方式是使用系统工具查看浏览器的内存分配。有多个工具可为您提供当前的使用，并描绘一个进程的内存使用量随时间变化的趋势图。
例如，如果在 Mac OSX 上安装了 XCode，您可以启动 Instruments 应用程序，并将它的活动监视器工具附加到您的浏览器上，以进行实时分析。在 Windows® 上，您可以使用任务管理器。如果在您使用应用程序的过程中，发现内存使用量随时间变化的曲线稳步上升，那么您就知道存在内存泄漏。
观察浏览器的内存占用只能非常粗略地显示 JavaScript 应用程序的实际内存使用。浏览器数据不会告诉您哪些对象发生了泄漏，也无法保证数据与您应用程序的真正内存占用确实匹配。而且，由于一些浏览器中存在实现问题，DOM 元素（或备用的应用程序级对象）可能不会在页面中销毁相应元素时释放。视频标记尤为如此，视频标记需要浏览器实现一种更加精细的基础架构。
人们曾多次尝试在客户端 JavaScript 库中添加对内存分配的跟踪。不幸的是，所有尝试都不是特别可靠。例如，流行的 stats.js 包由于不准确性而无法支持。一般而言，尝试从客户端维护或确定此信息存在一定的问题，是因为它会在应用程序中引入开销且无法可靠地终止。
理想的解决方案是浏览器供应商在浏览器中提供一组工具，帮助您监视内存使用，识别泄漏的对象，以及确定为什么一个特殊对象仍标记为保留。
目前，只有 Google Chrome（提供了 Heap Profile）实现了一个内存管理工具作为它的开发人员工具。我在本文中使用 Heap Profiler 测试和演示 JavaScript 运行时如何处理内存。
三、分析堆快照
在创建内存泄漏之前，请查看一次适当收集内存的简单交互。首先创建一个包含两个按钮的简单 HTML 页面，如清单 1 所示。
清单 1. index.html
清单 11. assets/scripts/leaker.js
init:function(name,parent,registry){
this._name = name;
this._registry = registry;
this._parent = parent;
this._child = null;
this.createChildren();
this.registerCallback();
},createChildren:function(){
if(this._parent !== null){
// Only create child if this is the root
return;
}
this._child = new Leaker();
this._child.init("leaker 2",this,this._registry);
},registerCallback:function(){
this._registry.add(this);
},destroy: function(){
this._registry.remove(this);
}
};
最后，更新 main.js 以设置注册表，并将对注册表的一个引用传递给 leaker 父对象，如清单 12 所示。
清单 12. assets/scripts/main.js
$("#destroy_button").click(function(){
leak.destroy();
leak = null;
});
registry = new Registry();
registry.init();
现在，当执行堆分析时，您应看到每次选择 Start 按钮时，会创建并保留 Leaker 对象的两个新实例。图 5 显示了对象引用的流程。
从表面上看，它像一个不自然的示例，但它实际上非常常见。更加经典的面向对象框架中的事件侦听器常常遵循类似图 5 的模式。这种类型的模式也可能与闭包和控制台日志导致的问题相关联。
尽管有多种方式来解决此类问题，但在此情况下，最简单的方式是更新 Leaker 类，以在销毁它时销毁它的子对象。对于本示例，更新destroy 方法（如清单 13 所示）就足够了。
清单 13. assets/scripts/leaker.js
有时，两个没有足够紧密关系的对象之间也会存在循环，其中一个对象管理另一个对象的生命周期。在这样的情况下，在这两个对象之间建立关系的对象应负责在自己被销毁时中断循环。
结束语
即使 JavaScript 已被垃圾回收，仍然会有许多方式会将不需要的对象保留在内存中。目前大部分浏览器都已改进了内存清理功能，但评估您应用程序内存堆的工具仍然有限（除了使用 Google Chrome）。通过从简单的测试案例开始，很容易评估潜在的泄漏行为并确定是否存在泄漏。
不经过测试，就不可能准确度量内存使用。很容易使循环引用占据对象曲线图中的大部分区域。Chrome 的 Heap Profiler 是一个诊断内存问题的宝贵工具，在开发时定期使用它也是一个不错的选择。在预测对象曲线图中要释放的具体资源时请设定具体的预期，然后进行验证。任何时候当您看到不想要的结果时，请仔细调查。
在创建对象时要计划该对象的清理工作，这比在以后将一个清理阶段移植到应用程序中要容易得多。常常要计划删除事件侦听器，并停止您创建的间隔。如果认识到了您应用程序中的内存使用，您将得到更可靠且性能更高的应用程序。
