中国领先的IT技术网站
51CTO旗下网站
闭包会造成内存泄漏吗？
在谈内存泄漏这个问题之前先看看JavaScript的垃圾收集机制，JavaScript 具有自动垃圾收集机制，就是找出那些不再继续使用的变量，然后释放其占用的内存。为此，垃圾收集器会按照固定的时间间隔（或代码执行中预定的收集时间）。常用的的方法有两种，即标记清楚和引用计数。
作者：yancyenough来源：| 20:56
在谈内存泄漏这个问题之前先看看JavaScript的垃圾收集机制，JavaScript
具有自动垃圾收集机制，就是找出那些不再继续使用的变量，然后释放其占用的内存。为此，垃圾收集器会按照固定的时间间隔(或代码执行中预定的收集时间)。常用的的方法有两种，即标记清楚和引用计数。
1. 标记清除
JavaScript
中最常用的垃圾收集方式是标记清除(mark-and-sweep)。垃圾收集器在运行的时候会给存储在内存中的所有变量都加上标记(可以使用任何标记方式)。然后，它会去掉环境中的变量以及被环境中的变量引用的变量的标记。而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。最后，垃圾收集器完成内存清除工作，销毁那些带标记的值并回收它们所占用的内存空间。
2. 引用计数
引用计数(reference
counting)的含义是跟踪记录每个值被引用的次数。当声明了一个变量并将一个引用类型值赋给该变量时，则这个值的引用次数就是1。如果同一个值又被赋给另一个变量，则该值的引用次数加1。相反，如果包含对这个值引用的变量又取得了另外一个值，则这个值的引用次数减1。当这个值的引用次数变成0
时，则说明没有办法再访问这个值了，因而就可以将其占用的内存空间回收回来。这样，当垃圾收集器下次再运行时，它就会释放那些引用次数为零的值所占用的内存。
Netscape Navigator 3.0 是最早使用引用计数策略的浏览器，但很快它就遇到了一个严重的问题，请看下面这个例子：
function&problem(){&&&&&var&objectA&=&new&Object();&&&&&var&objectB&=&new&Object();&&&&&objectA.someOtherObject&=&objectB;&&&&&objectB.anotherObject&=&objectA;&}&&
说明：objectA 和objectB
通过各自的属性相互引用，即这两个对象的引用次数都是2，在采用标记清除策略的实现中，由于函数执行之后，这两个对象都离开了作用域，因此这种相互引用不是个问题。但在采用引用计数策略的实现中，当函数执行完毕后，objectA
和objectB 还说明将继续存在，因为它们的引用次数永远不会是0。假如这个函数被重复多次调用，就会导致大量内存得不到回收。
为此，Netscape 在Navigator 4.0
中放弃了引用计数方式，然而引用计数导致的麻烦并未就此了结。IE9以前中有一部分对象并不是原生JavaScript 对象。例如，其BOM 和DOM
中的对象就是使用C++以COM(Component Object Model，组件对象模型)对象的形式实现的，而COM
对象的垃圾收集机制采用的就是引用计数策略。因此，即使IE 的JavaScript 引擎是使用标记清除策略来实现的，但JavaScript 访问的COM
对象依然是基于引用计数策略的。换句话说，只要在IE 中涉及COM 对象，就会存在循环引用的问题。
var&element&=&document.getElementById(&some_element&);&var&myObject&=&new&Object();&myObject.element&=&&element.someObject&=&myO&&
DOM 元素(element)与一个原生JavaScript 对象(myObject)之间创建了循环引用。其中，变量myObject
有一个名为element 的属性指向element 对象;而变量element 也有一个属性名叫someObject
回指myObject。由于存在这个循环引用，即使将例子中的DOM 从页面中移除，它也永远不会被回收。
解决办法：将变量设为null从而切断变量与它此前引用的值之间的连接。
myObject.element&=&null;&&element.someObject&=&null;&&
看完上面的内容，我来谈正题。
闭包不会引起内存泄漏
由于IE9 之前的版本对JScript 对象和COM 对象使用不同的垃圾收集。因此闭包在IE
的这些版本中会导致一些特殊的问题。具体来说，如果闭包的作用域链中保存着一个HTML 元素，那么就意味着该元素将无法被销毁请看例子：
function&assignHandler(){&&&&&var&element&=&document.getElementById(&someElement&);&&&&&element.onclick&=&function(){&&&&&&&&&alert(element.id);&&&&&};&}&&
以上代码创建了一个作为element
元素事件处理程序的闭包，而这个闭包则又创建了一个循环引用。由于匿名函数保存了一个对assignHandler()的活动对象的引用，因此就会导致无法减少element
的引用数。只要匿名函数存在，element 的引用数至少也是1，因此它所占用的内存就永远不会被回收
解决办法前言已经提到过，把element.id 的一个副本保存在一个变量中，从而消除闭包中该变量的循环引用同时将element变量设为null。
function&assignHandler(){&&&&&var&element&=&document.getElementById(&someElement&);&&&&&var&id&=&element.&&&&&element.onclick&=&function(){&&&&&&&&&alert(id);&&&&&};&&&&&element&=&null;&}&&
总结：闭包并不会引起内存泄漏，只是由于IE9之前的版本对JScript对象和COM对象使用不同的垃圾收集，从而导致内存无法进行回收，这是IE的问题，所以闭包和内存泄漏没半毛钱关系。
里做了详细的测试，有兴趣的可以点击查看【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
外电头条头条外电头条
24H热文一周话题本月最赞
讲师：1人学习过
讲师：1人学习过
讲师：4人学习过
精选博文论坛热帖下载排行
本书将介绍如何创建可交互的Web站点，包括从最简单的订单表单到复杂的安全电子商务站点。而且，读者还将了解如何使用开放源代码技术来实现...
订阅51CTO邮刊可以, 但小心使用.
闭包也许是 JS 中最有用的特性了. 有一份比较好的介绍闭包原理的.
有一点需要牢记, 闭包保留了一个指向它封闭作用域的指针, 所以, 在给 DOM 元素附加闭包时, 很可能会产生循环引用, 进一步导致内存泄漏. 比如下面的代码:
function foo(element, a, b) {
element.onclick = function() { /* uses a and b */ };
这里, 即使没有使用&element, 闭包也保留了&element,&a&和&b&的引用, . 由于&element&也保留了对闭包的引用, 这就产生了循环引用, 这就不能被 GC 回收. 这种情况下, 可将代码重构为:
function foo(element, a, b) {
element.onclick = bar(a, b);
function bar(a, b) {
return function() { /* uses a and b */ }
&&&&& 谷歌js编码规范
这是谷歌js编码规范里的。"闭包",是个绕不开的话题，我查阅了不少资料，各种解释都有，关于为什么会造成内存泄漏，也都介绍的很晦涩，没有把原理讲透，在这里，我就这两个问题详细讲一下。
首先讲闭包。闭包简而言之，就是一个函数（fa），的内部函数（fb）被fa外的变量引用，就形成了一个闭包；下面给出两种事例：
function fa() {
function fb() {
alert("hello word");
var myfun = fa();
function fa() {
var e = document.getElementById("id");
e.event = function () {
alert("hello word");
这两种形式的形成闭包的机制不同，一个通过一个return 返回这个内部函数，从而被包外引用，而另一个则是通过 e，这个docment这个宿主对象的事件而完成外部引用。这两种形式形成的结果就是fa这个函数的的内部函数可以被fa的外部变量所引用，这就形成了闭包。
闭包讲到这里我想大家琢磨一下应该很清楚了，下面我们来分析下这个内存泄漏是怎么形成的。很多资料都说循环引用，IE的计数式的垃圾回收机制，但我相信，这些概念很模糊，到底是怎么们回事，我们下面详细来剖析。
垃圾回收机制现在很成熟了，但早期的IE版本里（ie4-ie6），对宿主对象（也就是document对象）采用是计数的垃圾回收机制，闭包导致内存泄漏的一个原因就是这个算法的一个缺陷。循环引用会导致没法回收，这个循环引用只限定于有宿主对象参与的循环引用，而js对象之间即使形成循环引用，也不会产生内存泄漏，因为对js对象的回收算法不是计数的方式。
首先我们明确下内存泄漏的概念：内存里不能被回收也不能被利用的空间即为内存泄漏。为什么不能被回收呢？不符合内存回收的算法；为什么不能被利用呢？在栈上没有指向他的指针。在这里我简单的讲一下堆和栈的关系:
function fa() {
var o = new Object();
我们看这段代码执行的时候发生了什么
我们看到，栈上只是存了一个指针，指针就是堆上对象的的地址；我们的程序通过这个指针句可以操作堆上的对象。栈上的这个指针是自动管理的，当函数退出后，就销毁了；这样程序就在没办法访问到堆上的这个对象了，而堆上的这个对象这个时候就会被我们的GC自动回收了；如果回收不了，就是内存泄漏了。
讲到这里大家对内存泄露应该是有所了解了，对于计数回收方式大家查下资料，相信大家根据上面讲的应该可以看明白了，这里不再详细描述。下面我们着重描述下内存泄露的原因，大家先看下面的代码：
function fa() {
var a = "hello word";
return function () {
var o = fa();
& & 这段代码输出hello word，这说明什么？说明在堆上的&hello word& 没有被回收，什么原因？因为o这个函数还要引用这个变量。下面我们用计数的GC方式来逐句分析程序的代码
& & 在堆上有两个对象 一个是&hello word 我们叫做O1，匿名函数function（）{alert(a);}我们叫做O2
var a = "hello word"; 的时候 O1的计数为1；当执行
return function () {
的时候 O2的计数变为1；当执行完fa这个函数后 栈上的 var a 会被销毁，同是他指向的对象计数减1，这样问题就来了，这样O1的计数变为0了，那不被gc回收了嘛？怎么还会输出"hello word"?原来在执行
return function () {
}这个函数的时候，为了保持函数对这个变量的引用，在这个匿名函数的作用域链上加了一个对O1的引用，这样 其实 O1的计数在变成了2，在a被销毁后，O1减变成了1而不是0.那么O1时候被回收呢？当O2被回收的时候。O2什么时候被回收呢？当指向他的var o 从栈上消失的时候。
好，讲到这里，原理我们讲完了下面我们就看下
function fa() {
var e = document.getElementById("id");
e.event = function () {
alert("hello word");
这段代码为什么会造成内存泄露
var e = document.getElementById("id"); 执行这段代码的时候 右边（O1）的对象计数变为了1
执行这段代码的时候
e.event = function () {
alert("hello word");
匿名函数（O2）的计数变了1；对象O1的计数变了2；
当函数fa执行完毕时 栈上的指针var e 消失，他指向的对象 O1的计数减1变为了1；这样当函数执行完毕，O1、O2的这两个对象的计数都为1，根据计数的回收算法，就都留在内存里了不能被GC回收了，就造成了内存泄漏。
上面说法不完全正确，实际上执行完fa后O2的计数是2，这个大家可以想一下原因。
&其实fa里面的宿主对象只是真正对象一个副本，当执行
e.event 这句指令的时候 做了两件事，一个是副本的对象指向O2 这时O2的计数加1，真正的宿主对象又指向这个O2，这个O2的计数再加1 变为了2所以 在fa的外面执行 e.event=null 的时候，这时O2计数减1变为了1， 这时候，栈上再没有指向O2的指针了，所以O2的计数再没有减少的机会了。这样O2就永远存在了，O2存在，那么O2的作用域链指向O1的指针就永远存在了，所以O1也就永远存了，这样O1、O2 就再没机会释放了，就造成了内存泄漏。
阅读(...) 评论()解决js函数闭包内存泄露问题的办法
作者：billyangg
字体：[ ] 类型：转载 时间：
这篇文章主要通过举例介绍了解决js函数闭包内存泄露问题的办法，感兴趣的小伙伴们可以参考一下
本文通过举例，由浅入深的讲解了解决js函数闭包内存泄露问题的办法，分享给大家供大家参考，具体内容如下
原始代码：
function Cars(){
this.name = "Benz";
this.color = ["white","black"];
Cars.prototype.sayColor = function(){
var outer =
return function(){
return outer.color
var instance = new Cars();
console.log(instance.sayColor()())
优化后的代码：
function Cars(){
this.name = "Benz";
this.color = ["white","black"];
Cars.prototype.sayColor = function(){
var outerColor = this. //保存一个副本到变量中
return function(){
return outerC //应用这个副本
outColor = //释放内存
var instance = new Cars();
console.log(instance.sayColor()())
稍微复杂一点的例子：
function inheritPrototype(subType,superType){
var prototype = Object(superType.prototype);
prototype.constructor = subT
subType.prototype =
function Cars(){
this.name = "Benz";
this.color = ["white","black"];
Cars.prototype.sayColor = function(){
var outer =
return function(){
return outer.
function Car(){
Cars.call(this);
this.number = [321,32];
inheritPrototype(Car,Cars);
Car.prototype.sayNumber = function(){
var outer =
return function(){
return function(){
return outer.number[outer.number.length - 1];
var instance = new Car();
console.log(instance.sayNumber()()());
首先，该例子组合使用了构造函数模式和原型模式创建Cars 对象，并用了寄生组合式继承模式来创建Car 对象并从Cars 对象获得属性和方法的继承；
其次，建立一个名为instance 的Car 对象的实例；instance 实例包含了sayColor 和sayNumber 两种方法；
最后，两种方法中，前者使用了一个闭包，后者使用了两个闭包，并对其this 进行修改使其能够访问到this.color 和this.number。
这里存在内存泄露问题，优化后的代码如下：
function inheritPrototype(subType,superType){
var prototype = Object(superType.prototype);
prototype.constructor = subT
subType.prototype =
function Cars(){
this.name = "Benz";
this.color = ["white","black"];
Cars.prototype.sayColor = function(){
var outerColor = this. //这里
return function(){
return outerC //这里
this = //这里
function Car(){
Cars.call(this);
this.number = [321,32];
inheritPrototype(Car,Cars);
Car.prototype.sayNumber = function(){
var outerNumber = this. //这里
return function(){
return function(){
return outerNumber[outerNumber.length - 1]; //这里
this = //这里
var instance = new Car();
console.log(instance.sayNumber()()());
以上就是为大家分享的解决方法，希望对大家的学习有所帮助。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具最新教程周点击榜
微信扫一扫4类JavaScript内存泄露及如何避免 - 编程语言 - ITeye资讯
相关知识库：
引用
原文：
译文来自：
本文将探索常见的客户端 JavaScript 内存泄露，以及如何使用 Chrome 开发工具发现问题。
简介
内存泄露是每个开发者最终都要面对的问题，它是许多问题的根源：反应迟缓，崩溃，高延迟，以及其他应用问题。
什么是内存泄露？
本质上，内存泄露可以定义为：应用程序不再需要占用内存的时候，由于某些原因，内存没有被操作系统或可用内存池回收。编程语言管理内存的方式各不相同。只有开发者最清楚哪些内存不需要了，操作系统可以回收。一些编程语言提供了语言特性，可以帮助开发者做此类事情。另一些则寄希望于开发者对内存是否需要清晰明了。
JavaScript 内存管理
JavaScript 是一种垃圾回收语言。垃圾回收语言通过周期性地检查先前分配的内存是否可达，帮助开发者管理内存。换言之，垃圾回收语言减轻了“内存仍可用”及“内存仍可达”的问题。两者的区别是微妙而重要的：仅有开发者了解哪些内存在将来仍会使用，而不可达内存通过算法确定和标记，适时被操作系统回收。
JavaScript 内存泄露
垃圾回收语言的内存泄露主因是不需要的引用。理解它之前，还需了解垃圾回收语言如何辨别内存的可达与不可达。
Mark-and-sweep
大部分垃圾回收语言用的算法称之为 Mark-and-sweep 。算法由以下几步组成：
1.垃圾回收器创建了一个“roots”列表。Roots 通常是代码中全局变量的引用。JavaScript 中，“window” 对象是一个全局变量，被当作 root 。window 对象总是存在，因此垃圾回收器可以检查它和它的所有子对象是否存在（即不是垃圾）；
2.所有的 roots 被检查和标记为激活（即不是垃圾）。所有的子对象也被递归地检查。从 root 开始的所有对象如果是可达的，它就不被当作垃圾。
3.所有未被标记的内存会被当做垃圾，收集器现在可以释放内存，归还给操作系统了。
现代的垃圾回收器改良了算法，但是本质是相同的：可达内存被标记，其余的被当作垃圾回收。
不需要的引用是指开发者明知内存引用不再需要，却由于某些原因，它仍被留在激活的 root 树中。在JavaScript中，不需要的引用是保留在代码中的变量，它不再需要，却指向一块本该被释放的内存。有些人认为这是开发者的错误。
为了理解JavaScript中最常见的内存泄露，我们需要了解哪种方式的引用容易被遗忘。
三种类型的常见JavaScript内存泄露
1：意外的全局变量
JavaScript 处理未定义变量的方式比较宽松：未定义的变量会在全局对象创建一个新变量。在浏览器中，全局对象是 window 。
function foo(arg) {
bar = "this is a hidden global variable";
function foo(arg) {
window.bar = "this is an explicit global variable";
函数 foo 内部忘记使用 var ，意外创建了一个全局变量。此例泄露了一个简单的字符串，无伤大雅，但是有更糟的情况。
另一种意外的全局变量可能由 this 创建：
function foo() {
this.variable = "potential accidental global";
// Foo 调用自己，this 指向了全局对象（window）
// 而不是 undefined
引用
在 JavaScript 文件头部加上 'use strict'，可以避免此类错误发生。启用严格模式解析 JavaScript ，避免意外的全局变量。
全局变量注意事项
尽管我们讨论了一些意外的全局变量，但是仍有一些明确的全局变量产生的垃圾。它们被定义为不可回收（除非定义为空或重新分配）。尤其当全局变量用于临时存储和处理大量信息时，需要多加小心。如果必须使用全局变量存储大量数据时，确保用完以后把它设置为 null 或者重新定义。与全局变量相关的增加内存消耗的一个主因是缓存。缓存数据是为了重用，缓存必须有一个大小上限才有用。高内存消耗导致缓存突破上限，因为缓存内容无法被回收。
2：被遗忘的计时器或回调函数
在JavaScript中使用setInterval非常平常。一段常见的代码：
var someResource = getData();
setInterval(function() {
var node = document.getElementById('Node');
if(node) {
// 处理 node 和 someResource
node.innerHTML = JSON.stringify(someResource));
此例说明了什么：与节点或数据关联的计时器不再需要，node 对象可以删除，整个回调函数也不需要了。可是，计时器回调函数仍然没被回收（计时器停止才会被回收）。同时，someResource 如果存储了大量的数据，也是无法被回收的。
对于观察者的例子，一旦它们不再需要（或者关联的对象变成不可达），明确地移除它们非常重要。老的 IE 6 是无法处理循环引用的。如今，即使没有明确移除它们，一旦观察者对象变成不可达，大部分浏览器是可以回收观察者处理函数的。
观察者代码示例：
var element = document.getElementById('button');
function onClick(event) {
element.innerHTML = 'text';
element.addEventListener('click', onClick);
对象观察者和循环引用注意事项
老版本的 IE 是无法检测 DOM 节点与 JavaScript 代码之间的循环引用，会导致内存泄露。如今，现代的浏览器（包括 IE 和 Microsoft Edge）使用了更先进的垃圾回收算法，已经可以正确检测和处理循环引用了。换言之，回收节点内存时，不必非要调用 removeEventListener 了。
3：脱离 DOM 的引用
有时，保存 DOM 节点内部数据结构很有用。假如你想快速更新表格的几行内容，把每一行 DOM 存成字典（JSON 键值对）或者数组很有意义。此时，同样的 DOM 元素存在两个引用：一个在 DOM 树中，另一个在字典中。将来你决定删除这些行时，需要把两个引用都清除。
var elements = {
button: document.getElementById('button'),
image: document.getElementById('image'),
text: document.getElementById('text')
function doStuff() {
image.src = 'http://some.url/image';
button.click();
console.log(text.innerHTML);
// 更多逻辑
function removeButton() {
// 按钮是 body 的后代元素
document.body.removeChild(document.getElementById('button'));
// 此时，仍旧存在一个全局的 #button 的引用
// elements 字典。button 元素仍旧在内存中，不能被 GC 回收。
此外还要考虑 DOM 树内部或子节点的引用问题。假如你的 JavaScript 代码中保存了表格某一个 &td& 的引用。将来决定删除整个表格的时候，直觉认为 GC 会回收除了已保存的 &td& 以外的其它节点。实际情况并非如此：此 &td& 是表格的子节点，子元素与父元素是引用关系。由于代码保留了 &td& 的引用，导致整个表格仍待在内存中。保存 DOM 元素引用的时候，要小心谨慎。
4：闭包
闭包是JavaScript开发的一个关键方面：匿名函数可以访问父级作用域的变量。
代码示例：
var theThing =
var replaceThing = function () {
var originalThing = theT
var unused = function () {
if (originalThing)
console.log("hi");
theThing = {
longStr: new Array(1000000).join('*'),
someMethod: function () {
console.log(someMessage);
setInterval(replaceThing, 1000);
代码片段做了一件事情：每次调用 replaceThing ，theThing 得到一个包含一个大数组和一个新闭包（someMethod）的新对象。同时，变量 unused 是一个引用 originalThing 的闭包（先前的 replaceThing 又调用了 theThing ）。思绪混乱了吗？最重要的事情是，闭包的作用域一旦创建，它们有同样的父级作用域，作用域是共享的。someMethod 可以通过 theThing 使用，someMethod 与 unused 分享闭包作用域，尽管 unused 从未使用，它引用的 originalThing 迫使它保留在内存中（防止被回收）。当这段代码反复运行，就会看到内存占用不断上升，垃圾回收器（GC）并无法降低内存占用。本质上，闭包的链表已经创建，每一个闭包作用域携带一个指向大数组的间接的引用，造成严重的内存泄露。
引用Meteor的博文解释了如何修复此种问题。在 replaceThing 的最后添加 originalThing = null 。
Chrome 内存剖析工具概览
Chrome 提供了一套很棒的检测 JavaScript 内存占用的工具。与内存相关的两个重要的工具：timeline 和 profiles。
timeline 可以检测代码中不需要的内存。在此截图中，我们可以看到潜在的泄露对象稳定的增长，数据采集快结束时，内存占用明显高于采集初期，Node（节点）的总量也很高。种种迹象表明，代码中存在 DOM 节点泄露的情况。
Profiles 是你可以花费大量时间关注的工具，它可以保存快照，对比 JavaScript 代码内存使用的不同快照，也可以记录时间分配。每一次结果包含不同类型的列表，与内存泄露相关的有 summary（概要） 列表和 comparison（对照） 列表。
summary（概要） 列表展示了不同类型对象的分配及合计大小：shallow size（特定类型的所有对象的总大小），retained size（shallow size 加上其它与此关联的对象大小）。它还提供了一个概念，一个对象与关联的 GC root 的距离。
对比不同的快照的 comparison list 可以发现内存泄露。
实例：使用Chrome发现内存泄露
实质上有两种类型的泄露：周期性的内存增长导致的泄露，以及偶现的内存泄露。显而易见，周期性的内存泄露很容易发现；偶现的泄露比较棘手，一般容易被忽视，偶尔发生一次可能被认为是优化问题，周期性发生的则被认为是必须解决的 bug。
以Chrome文档中的代码为例：
var x = [];
function createSomeNodes() {
frag = document.createDocumentFragment();
for (;i & 0; i--) {
div = document.createElement("div");
div.appendChild(document.createTextNode(i + " - "+ new Date().toTimeString()));
frag.appendChild(div);
document.getElementById("nodes").appendChild(frag);
function grow() {
x.push(new Array(1000000).join('x'));
createSomeNodes();
setTimeout(grow,1000);
当 grow 执行的时候，开始创建 div 节点并插入到 DOM 中，并且给全局变量分配一个巨大的数组。通过以上提到的工具可以检测到内存稳定上升。
找出周期性增长的内存
timeline 标签擅长做这些。在 Chrome 中打开例子，打开 Dev Tools ，切换到 timeline，勾选 memory 并点击记录按钮，然后点击页面上的 The Button 按钮。过一阵停止记录看结果：
两种迹象显示出现了内存泄露，图中的 Nodes（绿线）和 JS heap（蓝线）。Nodes 稳定增长，并未下降，这是个显著的信号。
JS heap 的内存占用也是稳定增长。由于垃圾收集器的影响，并不那么容易发现。图中显示内存占用忽涨忽跌，实际上每一次下跌之后，JS heap 的大小都比原先大了。换言之，尽管垃圾收集器不断的收集内存，内存还是周期性的泄露了。
确定存在内存泄露之后，我们找找根源所在。
保存两个快照
切换到 Chrome Dev Tools 的 profiles 标签，刷新页面，等页面刷新完成之后，点击 Take Heap Snapshot 保存快照作为基准。而后再次点击 The Button 按钮，等数秒以后，保存第二个快照。
筛选菜单选择 Summary，右侧选择 Objects allocated between Snapshot 1 and Snapshot 2，或者筛选菜单选择 Comparison ，然后可以看到一个对比列表。
此例很容易找到内存泄露，看下 (string) 的 Size Delta Constructor，8MB，58个新对象。新对象被分配，但是没有释放，占用了8MB。
如果展开 (string) Constructor，会看到许多单独的内存分配。选择某一个单独的分配，下面的 retainers 会吸引我们的注意。
我们已选择的分配是数组的一部分，数组关联到 window 对象的 x 变量。这里展示了从巨大对象到无法回收的 root（window）的完整路径。我们已经找到了潜在的泄露以及它的出处。
我们的例子还算简单，只泄露了少量的 DOM 节点，利用以上提到的快照很容易发现。对于更大型的网站，Chrome 还提供了 Record Heap Allocations 功能。
Record heap allocations 找内存泄露
回到Chrome Dev Tools 的 profiles 标签，点击 Record Heap Allocations。工具运行的时候，注意顶部的蓝条，代表了内存分配，每一秒有大量的内存分配。运行几秒以后停止。
上图中可以看到工具的杀手锏：选择某一条时间线，可以看到这个时间段的内存分配情况。尽可能选择接近峰值的时间线，下面的列表仅显示了三种 constructor：其一是泄露最严重的（string），下一个是关联的 DOM 分配，最后一个是 Text constructor（DOM 叶子节点包含的文本）。
从列表中选择一个 HTMLDivElement constructor，然后选择 Allocation stack。
现在知道元素被分配到哪里了吧（grow -& createSomeNodes），仔细观察一下图中的时间线，发现 HTMLDivElement constructor 调用了许多次，意味着内存一直被占用，无法被 GC 回收，我们知道了这些对象被分配的确切位置（createSomeNodes）。回到代码本身，探讨下如何修复内存泄露吧。
另一个有用的特性
在 heap allocations 的结果区域，选择 Allocation。
这个视图呈现了内存分配相关的功能列表，我们立刻看到了 grow 和 createSomeNodes。当选择 grow 时，看看相关的 object constructor，清楚地看到 (string), HTMLDivElement 和 Text 泄露了。
结合以上提到的工具，可以轻松找到内存泄露。}