JavaScript 内存泄露
1、什么是闭包、以及闭包所涉及的作用域链这里就不说了。
2、JavaScript垃圾回收机制
JavaScript不需要手动地释放内存，它使用一种自动垃圾回收机制（garbage collection）。当一个对象无用的时候，即程序中无变量引用这个对象时，就会从内存中释放掉这个变量。
Java代码
var s = [ 1, 2 ,3];
var s = null;
//这样原始的数组[1 ,2 ,3]就会被释放掉了。
var s = [ 1, 2 ,3];
var s = null;
//这样原始的数组[1 ,2 ,3]就会被释放掉了。
3、循环引用
三个对象 A 、B 、C
A->B->C ：A的某一属性引用着B，同样C也被B的属性引用着。如果将A清除，那么B、C也被释放。
A->B->C->B ：这里增加了C的某一属性引用B对象，如果这是清除A，那么B、C不会被释放，因为B和C之间产生了循环引用。Java代码
var a = {};
a.pro = { a:100 };
a.pro.pro = { b:100 };
a = null ;
//这种情况下，{a:100}和{b:100}就同时也被释放了。
var obj = {};
obj.pro = { a : 100 };
obj.pro.pro = { b : 200 };
var two = obj.pro.pro;
obj = null;
//这种情况下 {b:200}不会被释放掉，而{a:100}被释放了。
var a = {};
a.pro = { a:100 };
a.pro.pro = { b:100 };
a = null ;
//这种情况下，{a:100}和{b:100}就同时也被释放了。
var obj = {};
obj.pro = { a : 100 };
obj.pro.pro = { b : 200 };
var two = obj.pro.pro;
obj = null;
//这种情况下 {b:200}不会被释放掉，而{a:100}被释放了。
4、循环引用和闭包
Java代码
function outer(){
var obj = {};
function inner(){
//这里引用了obj对象
}
obj.inner = inner;
}
function outer(){
var obj = {};
function inner(){
//这里引用了obj对象
}
obj.inner = inner;
}这是一种及其隐蔽的循环引用，。当调用一次outer时，就会在其内部创建obj和inner两个对象，obj的inner属性引用了inner；同样inner也引用了obj，这是因为obj仍然在innerFun的封闭环境中，准确的讲这是由于JavaScript特有的“作用域链”。
因此，闭包非常容易创建循环引用，幸运的是JavaScript能够很好的处理这种循环引用。
5、IE中的内存泄漏
IE中的内存泄漏有好几种，这里有详细的解释（http://msdn.microsoft.com/en-us/library/bb250448.aspx），园子里也有翻译了（http://www.cnblogs.com/birdshome/archive/2006/05/28/ie_memoryleak.html）。
这里只讨论其中一种，即循环引用所造成的内存泄漏，因为，这是一种最普遍的情况。
当在DOM元素或一个ActiveX对象与普通JavaScript对象之间存在循环引用时，IE在释放这类变量时存在特殊的困难，最好手动切断循环引用，这个bug在IE 7中已经被修复了（http://www.quirksmode.org/blog/archives/2006/04/ie_7_and_javasc.html）。
“IE 6 suffered from memory leaks when a circular reference between several objects, among which at least one DOM node, was created. This problem has been solved in IE 7. ”
如果上面的例子（第4点）中obj引用的不是一个JavaScript Function对象（inner），而是一个ActiveX对象或Dom元素，这样在IE中所形成的循环引用无法得到释放。Java代码
function init(){
var elem = document.getElementByid( 'id' );
elem.onclick = function(){
alert('rain-man');
//这里引用了elem元素
};
}
function init(){
var elem = document.getElementByid( 'id' );
elem.onclick = function(){
alert('rain-man');
//这里引用了elem元素
};
}
Elem引用了它的click事件的监听函数，同样该函数通过其作用域链也引用回了elem元素。这样在IE中即使离开当前页面也不会释放这些循环引用。
6、解决方法
基本的方法就是手动清除这种循环引用，下面一个十分简单的例子，实际应用时可以自己构建一个addEvent()函数，并且在window的unload事件上对所有事件绑定进行清除。
Java代码
function outer(){
var one = document.getElementById( 'one' );
one.onclick = function(){};
}
window.onunload = function(){
var one = document.getElementById( 'one' );
one.onclick = null;
};
JavaScript 中的内存泄漏
JavaScript 是一种垃圾收集式语言，这就是说，内存是根据对象的创建分配给该对象的，并会在没有对该对象的引用时由浏览器收回。JavaScript 的垃圾收集机制本身并没有问题，但浏览器在为 DOM 对象分配和恢复内存的方式上却有些出入。
Internet Explorer 和 Mozilla Firefox 均使用引用计数来为 DOM 对象处理内存。在引用计数系统，每个所引用的对象都会保留一个计数，以获悉有多少对象正在引用它。如果计数为零，该对象就会被销毁，其占用的内存也会返回给堆。虽然这种解决方案总的来说还算有效，但在循环引用方面却存在一些盲点。
原因
1)循环引用导致了内存泄漏
<html>
<body>
<script type="text/javascript">
document.write("circular references between JavaScript and DOM!");
var obj;
window.onload = function(){
obj=document.getElementById("DivElement");
document.getElementById("DivElement").expandoProperty=obj;
obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX"));
};
</script>
<div id="DivElement">Div Element</div>
</body>
</html>
2)由外部函数调用引起的内存泄漏
<html>
<head>
<script type="text/javascript">
document.write(" object s between JavaScript and DOM!");
function myFunction(element)
{
this.elementReference = element;
// This code forms a circular reference here
//by DOM-->JS-->DOM
element.expandoProperty = this;
}
function Leak() {
//This code will leak
new myFunction(document.getElementById("myDiv"));
}
</script>
</head>
<body onload="Leak()">
<div id="myDiv"></div>
</body>
</html>
3)闭包引起的内存泄漏
function parentFunction(paramA){
var a = paramA;
function childFunction(){
return a + 2;
}
return childFunction();
}
4)由事件处理引起的内存泄漏模式
<html>
<body>
<script type="text/javascript">
document.write("Program to illustrate memory leak via closure");
window.onload=function outerFunction(){
var obj = document.getElementById("element");
obj.onclick=function innerFunction(){
alert("Hi! I will leak");
};
obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX"));
// This is used to make the leak significant
};
</script>
<button id="element">Click Me</button>
</body>
</html>
解决方法
1)打破循环引用
<html>
<body>
<script type="text/javascript">
document.write("Avoiding memory leak via closure by breaking the circular reference");
window.onload=function outerFunction(){
var obj = document.getElementById("element");
obj.onclick=function innerFunction()
{
alert("Hi! I have avoided the leak");
// Some logic here
};
obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX"));
obj = null; //This breaks the circular reference
};
</script>
<button id="element">"Click Here"</button>
</body>
</html>
2)添加另一个闭包
<html>
<body>
<script type="text/javascript">
document.write("Avoiding a memory leak by adding another closure");
window.onload=function outerFunction(){
var anotherObj = function innerFunction(){
// Some logic here
alert("Hi! I have avoided the leak");
};
(function anotherInnerFunction(){
var obj = document.getElementById("element");
obj.onclick=anotherObj
})();
};
</script>
<button id="element">"Click Here"</button>
</body>
</html>
3)避免闭包自身
<html>
<head>
<script type="text/javascript">
document.write("Avoid leaks by avoiding closures!");
window.onload=function(){
var obj = document.getElementById("element");
obj.onclick = doesNotLeak;
}
function doesNotLeak(){
//Your Logic here
alert("Hi! I have avoided the leak");
}
</script>
</head>
<body>
<button id="element">"Click Here"</button>
</body>
</html>
4)考虑用CollectGarbage()
jcl.MemFree = function(Mem){
Mem = null;
CollectGarbage();
};
检测软件
sIEve: 他是基于ie的内存泄露检测工具，需要下载运行，http://home.wanadoo.nl/jsrosman/
Leak Monitor: 他是基于firefox的内存泄露检测工具，https://addons.mozilla.org/firefox/2490/
个人建议
内存回收机制本身有问题，所以开发人员开发的时候尽量减少内存溢出。不要盲目的追求完美！
JS运行机制
从一个简单的问题谈起：
<script type="text/javascript">
alert(i); // ?
var i = 1;
</script>
输出结果是undefined, 这种现象被称成“预解析”：javascript引擎会优先解析var变量和function定义。在预解析完成后，才会执行代码。如果一个文档流中包含多个script代码段（用script标签分隔的js代码或引入的js文件），运行顺序是：
step1. 读入第一个代码段
step2. 做语法分析，有错则报语法错误（比如括号不匹配等），并跳转到step5
step3. 对var变量和function定义做“预解析”（永远不会报错的，因为只解析正确的声明）
step4. 执行代码段，有错则报错（比如变量未定义）
step5. 如果还有下一个代码段，则读入下一个代码段，重复step2
step6. 结束
上面的分析，已经能解释很多问题了，但老觉得欠缺点什么。比如step3里，“预解析”究竟是怎么回事？还有step4里，看下面的例子：
<script type="text/javascript">
alert(i); // error: i is not defined.
i = 1;
</script>
为什么第一句会导致错误？javascript中，变量不是可以不定义吗？
编译过程
时间如白马过隙，书柜旁翻开恍如隔世般的《编译原理》，熟悉而又陌生的空白处有着这样的笔记：
对于传统编译型语言来说，编译步骤分为：词法分析、语法分析、语义检查、代码优化和字节生成。
但对于解释型语言来说，通过词法分析和语法分析得到语法树后，就可以开始解释执行了。
简单地说，词法分析是将字符流(char stream)转换为记号流(token stream), 比如将c = a - b;转换为：
NAME "c"
EQUALS
NAME "a"
MINUS
NAME "b"
SEMICOLON
上面只是示例，更进一步的了解请查看 Lexical Analysis.
《javascript权威指南》的第2章，讲的就是词法结构（Lexical Structure），ECMA-262 中也有描述。词法结构是一门语言的基础，很容易掌握。至于词法分析的实现那是另一个研究领域，在此不探究。
可以拿自然语言来类比，词法分析是一对一的硬性翻译，比如一段英文，逐词翻译成中文，得到的是一堆记号流，还很难理解。进一步的翻译，就需要语法分析了，下图是一个条件语句的语法树：
构造语法树的时候，如果发现无法构造，比如if(a { i = 2; }, 就会报语法错误，并结束整个代码块的解析，这就是本文开头部分的step2.
通过语法分析，构造出语法树后，翻译出来的句子可能还会有模糊不清的地方，接下来还需要进一步的语义检查。对于传统强类型语言来说，语义检查的主要部分是类型检查，比如函数的实参和形参类型是否匹配。对于弱类型语言来说，这一步可能没有（精力有限，没时间去看JS的引擎实现，不敢确定JS引擎中是否有语义检查这一步）。
通过上面的分析可以看出，对于javascript引擎来说，肯定有词法分析和语法分析，之后可能还有语义检查、代码优化等步骤，等这些编译步骤完成之后（任何语言都有编译过程，只是解释型语言没有编译成二进制代码），才会开始执行代码。
上面的编译过程，还是无法更深入的解释文章开头部分的“预解析”，我们还得仔细探究下javascript代码的执行过程。
执行过程
周爱民在《javascript语言精髓与编程实践》的第二部分，对此有非常仔细的分析。下面是我的一些领悟：
通过编译，javascript代码已经翻译成了语法树，然后会立刻按照语法树执行。
进一步的执行过程，需要理解javascript的作用域机制，javascript采用的是词法作用域（lexcical scope）。通俗地讲，就是javascript变量的作用域是在定义时决定而不是执行时决定，也就是说词法作用域取决于源码，编译器通过静态分析就能确定，因此词法作用域也叫做静态作用域（static scope）。但需要注意，with和eval的语义无法仅通过静态技术实现，实际上，只能说JS的作用域机制非常接近lexical scope.
JS引擎在执行每个函数实例时，都会创建一个执行环境（execution context）。execution context中包含一个调用对象（call object）, 调用对象是一个scriptObject结构，用来保存内部变量表varDecls、内嵌函数表funDecls、父级引用列表upvalue等语法分析结构（注意：varDecls和funDecls等信息是在语法分析阶段就已经得到，并保存在语法树中。函数实例执行时，会将这些信息从语法树复制到scriptObject上）。scriptObject是与函数相关的一套静态系统，与函数实例的生命周期保持一致。
lexical scope是JS的作用域机制，还需要理解它的实现方法，这就是作用域链（scope chain）。scope chain是一个name lookup机制，首先在当前执行环境的scriptObject中寻找，没找到，则顺着upvalue到父级scriptObject中寻找，一直lookup到全局调用对象（global object）。
当一个函数实例执行时，会创建或关联到一个闭包（closure）。 scriptObject用来静态保存与函数相关的变量表，closure则在执行期动态保存这些变量表及其运行值。closure的生命周期有可能比函数实例长。函数实例在活动引用为空后会自动销毁，closure则要等要数据引用为空后，由JS引擎回收（有些情况下不会自动回收，就导致了内存泄漏）。
别被上面的一堆名词吓住，一旦理解了执行环境、调用对象、闭包、词法作用域、作用域链这些概念，JS语言的很多现象都能迎刃而解。
小结
至此，对于文章开头部分的疑问，可以解释得很清楚了：
step3中所谓的“预解析”，其实是在step2的语法分析阶段完成，并存储在语法树中。当执行到函数实例时，会将varDelcs和funcDecls从语法树中复制到执行环境的scriptObject上。
step4中，未定义变量意味着在scriptObject的变量表中找不到，JS引擎会沿着scriptObject的upvalue往上寻找，如果都没找到，对于写操作i = 1; 最后就会等价为 window.i = 1; 给window对象新增了一个属性。对于读操作，如果一直追溯到全局执行环境的scriptObject上都找不到，就会产生运行期错误。
JavaScript 内存泄露
今天下午同事让帮忙看web内存泄露问题。当时定位到创建ActiveX 对象的时候产生的，于是我对这个奇怪的问题进行了一些深入探索。
很多时候我都依赖javascript的垃圾回收机制，所以对C 以及C++ 操作内存语言常发生的内存泄露是很陌生的。当时创建回调函数用了闭包，当然最终的解决方法是也避免闭包调用。
随着这个问题的浮出水面，我回忆起以前的一个项目中也应该存在这个内存泄露问题。于是查阅了相关资料把类似的问题总结下来，希望对大家也有帮助。
原因：对于一门具有垃圾收回机制的语言存在内存泄露，其原因不外乎就是javascript脚本引擎存在bug。
很多时候，我们要做的不是去修正那样的bug，而是想办法去规避。
目前发现的可能导致内存泄露的代码有三种：
- · 循环引用
- · 自动类型装箱转换
- · 某些DOM操作
下面具体的来说说内存是如何泄露的
循环引用：这种方式存在于IE6和FF2中（FF3未做测试），当出现了一个含有DOM对象的循环引用时，就会发生内存泄露。
什么是循环引用？首先搞清楚什么是引用，一个对象A的属性被赋值为另一个对象B时，则可以称A引用了B。假如B也引用了A，那么A和B之间构成了循环引用。同样道理 如果能找到A引用B B引用C C又引用A这样一组饮用关系，那么这三个对象构成了循环引用。当一个对象引用自己时,它自己形成了循环引用。注意，在js中变量永远是对象的属性，它可以指向对象，但决不是对象本身。
循环引用很常见，而且通常是无害的，但如果循环引用中包含DOM对象或者ActiveX对象，那么就会发生内存泄露。例子：
var a=document.createElement("div");
var b=new Object();
a.b=b;
b.a=a;
很多情况下循环引用不是这样的明显，下面就是著名的闭包（closure）造成内存泄露的例子，每执行一次函数A()都会产生内存泄露。试试看，根据前面讲的scope对象的知识，能不能找出循环引用？
function A()...{
var a=document.createElement("div");
a.onclick=function()...{
alert("hi");
}
}
A();
OK, 让我们来看看。假设A()执行时创建的作用域对象叫做ScopeA 找到以下引用关系
ScopeA引用DOM对象document.createElement("div");
DOM对象document.createElement("div");引用函数function(){alert("hi")}
函数function(){alert("hi")}引用ScopeA
这样就很清楚了，所谓closure泄露，只不过是几个js特殊对象的循环引用而已。
自动类型装箱转换：这种泄露存在于ie6 ie7中。这是极其匪夷所思的一个bug，看下面代码
var s="lalalalala";
alert(s.length);
这段代码怎么了？看看吧，"lalalalala"已经泄露了。关键问题出在s.length上，我们知道js的类型中，string并非对象，但可以对它使用.运算符，为什么呢？因为js的默认类型转换机制，允许js在遇到.运算符时自动将string转换为object型中对应的String对象。而这个转换成的临时对象100%会泄露（汗一下）。
某些DOM操作也可能导致泄露 这些恶心的bug只存在于ie系列中。在ie7中 因为试图fix循环引用bug而让情况变得更糟，以至于我对写这一段种满了恐惧。
从ie6谈起，下面是微软的例子，
<html>
<head>
<script language="JScript">...
function LeakMemory()
...{
var hostElement = document.getElementById("hostElement");
// Do it a lot, look at Task Manager for memory response
for(i = 0; i < 5000; i++)
...{
var parentDiv =
document.createElement("<div onClick='foo()'>");
var childDiv =
document.createElement("<div onClick='foo()'>");
// This will leak a temporary object
parentDiv.appendChild(childDiv);
hostElement.appendChild(parentDiv);
hostElement.removeChild(parentDiv);
parentDiv.removeChild(childDiv);
parentDiv = null;
childDiv = null;
}
hostElement = null;
}
function CleanMemory()
...{
var hostElement = document.getElementById("hostElement");
// Do it a lot, look at Task Manager for memory response
for(i = 0; i < 5000; i++)
...{
var parentDiv =
document.createElement("<div onClick='foo()'>");
var childDiv =
document.createElement("<div onClick='foo()'>");
// Changing the order is important, this won't leak
hostElement.appendChild(parentDiv);
parentDiv.appendChild(childDiv);
hostElement.removeChild(parentDiv);
parentDiv.removeChild(childDiv);
parentDiv = null;
childDiv = null;
}
hostElement = null;
}
</script>
</head>
<body>
<button onclick="LeakMemory()">Memory Leaking Insert</button>
<button onclick="CleanMemory()">Clean Insert</button>
<div id="hostElement"></div>
</body>
</html>
看看结果吧，LeakMemory造成了内存泄露，而CleanMemory没有，循环引用了么？仔细看看没有。那么是什么问题呢？MS的解释是"插入顺序不对",必须先将父级元素appendChild。这听起来有些模糊，这里给出一个比较恰当的等价描述：永远不要使用DOM节点树之外元素的appendChild方法。
我曾经看到过这样的说法，创建dom的时候，先创建子节点，当子节点完善后一次性添加到页面中，不要一点点朝页面上加东西，尽量减少document刷新次数，这样效率会高点。（打个比方就是应该像 LeakMemory ）可见这里我还是被某些书籍误导了。至少他没有告诉我内存泄露的问题。
接下来是ie7和ie8 beta 1中运行这段程序，看到什么？没看错吧，2个都泄露了！别急，刷新一下页面就好了。为什么呢？ie7改变了DOM元素的回收方式：在离开页面时回收DOM树上的所有元素，所以ie7下的内存管理非常简单：在所有的页面中只要挂在DOM树上的元素，就不会泄露，没挂在DOM树上，肯定泄露。所以，ie7中记住一条原则：在离开页面之前把所有创建的DOM元素挂到DOM树上。
接下来谈谈ie7的这个设计吧，坦白的说，这种做法纯粹是偷懒的垃圾做法。动态垃圾回收不是保证所有内存都在离开页面时收回，而是要保证内存的充分利用，运行时不回收，等到离开时回收有什么用？这只是名义上的避免泄露，其实是完全的泄露。况且还没有回收DOM节点树之外的元素。
4.内存泄露的解决方案
内存泄露怎么办？真的以后不用闭包了么？没法封装控件了？这样做还不如要了js程序员的命，嘿嘿。
事实上，通过一些很简单的小技巧，可以巧妙的绕开这些危险的bug。
to be continued......
coming soon:
- · 显式类型转换
- · 避免事件导致的循环引用
- · 不影响返回值地打破循环引用
- · 延迟appendChild
- · 代理DOM对象
- · 显式类型转换
首先说说最容易处理的情况 对于类型转换造成的错误，我们可以通过显式类型转换来避免：
var s=newString("lalalalala");//此处将string转换成object
alert(s.length);
这个太容易了，算不上正经方案。不过类型转换泄露也就这一种处理方法了。
- · 避免事件导致的循环引用
在比较成熟的js程序员里，把事件函数写成闭包是再正常不过了：
function A(){
var a=document.createElement("div");
a.onclick=function(){
alert("hi");
}
}
这将导致内存泄露。按照IBM那两位老大的说法，当然是把函数放外面或者a=null就没问题了，不过还要访问A()里面的变量呢？假如有下面的代码：
function A(){
var a=document.createElement("div");
var b=document.createElement("div");
a.onclick=function(){
alert(b.outerHTML);
}
return a;
}
如何将它的逻辑表达出来 还避免内存泄露？ 分析一下这个内存泄露的形式：只要onclick的外部环境中不包含a那么，就不会泄露。那么办法有2个一是将环境到a的引用断开 另一个是将function到环境的引用断开，但是，如果要在函数中访问b就不能将Function放到外面，如果要返回a的值，就不能a=null，怎么办呢？
解决方案1：
构造一个不含a的新环境
function A(){
var a=document.createElement("div");
var b=document.createElement("div");
a.onclick=BuildEvent(b);
return a;
}
function BuildEvent(b)
{
return function(){
alert(b.outerHTML);
}
}
a本身可以通过this访问，将其它需要访问的外层函数变量传递给BuildEvent就可以了。保持BuildEvent定义和调用的参数名一致，会带来方便。
解决方案2：
在return 之后a=null,不可能？ 看看下面：
function A(){
try{
var a=document.createElement("div");
var b=document.createElement("div");
a.onclick= function(){
alert(b.outerHTML);
}
return a;
} finally {
a=null;
}
}
finally在try之后执行，如果finall块不返回值，才会返回try块的返回值。
- · 延迟appendChild
还记得函数的lazy initalize吧，对于ie恶心至极的DOM操作泄露，我们需要用类似的方法去处理。在一个函数中构造一个复杂对象，在需要的时候将之appendChild到DOM树上，这是很常见的做法，但在IE6中，这样做将导致所谓的"插入顺序内存泄露"，没有别的办法，我们只能用一个数组parts保存子节点，编写一个appendTo方法先序遍历节点树，去把它挂在某个DOM节点上。
function appendTo(Element)
...{
Element.appendChild(this);
if(!this.parts)return;
for(var i=0;i<this.parts.length;i++)
parts.appendTo(this);
}
- · 垃圾箱
对于ie7，我比较无可奈何，因为DOM对象不会被CG程序回收，只有离开页面时会被回收，所以我的建议是：使用DOM要有节制，尽量多用innerHTML吧...... good luck.
一旦你使用了DOM对象，千万不要试图o=null，你可以设置一个叫做Garbage的div并且将其display设置为none，将不用的DOM对象存入其中（就是appendChild上去）就好了
- · 代理对象
这是Ext的做法，这里只是顺带提一下。将每个元素用一个"代理对象"操作，不论appendChild还是其他操作都不是对DOM对象本身的操作，而是通过这个代理对象操作。这是一个很不错的Proxy模式，不过要想避免泄露还是需要一点功夫的，并非用了Proxy之后就不会泄露，有时反而更容易泄露。
5 .ＦＡＱ
1 内存泄露是内存占用很大么？ 不是，即使1byte内存也叫做内存泄露。
2 程序中提示,内存不足，是内存泄露么？不是，这一般是无限递归函数调用导致栈内存溢出。
3 内存泄露是哪个区域泄露？堆区，栈区是不会泄露的。
4 window对象是DOM对象么？不是，window对象参与的循环引用不会内存泄露。
5 内存泄露后果是什么？大多数时候后果不很严重，但过多DOM操作会导致网页执行变慢。
6 跳转页面后，内存泄露仍然存在么？仍然存在，直到关闭浏览器。
7 FireFox也会内存泄露么？FF2仍然有内存泄露
我的浏览器存在泄漏么？
Internet Explorer 和 Mozilla Firefox 是两个与 JavaScript 中的内存泄漏联系最为紧密的浏览器。两个浏览器中造成这种问题的“罪魁祸首”是用来管理 DOM 对象的组件对象模型。本机 Windows COM 和 Mozilla's XPCOM 都使用引用计数的垃圾收集来进行内存分配和检索。引用计数与用于 JavaScript 的标记-清除式的垃圾收集并不总是能相互兼容。本文侧重介绍的是如何应对 JavaScript 代码中的内存泄漏。有关如何处理 Firefox 和 IE 中 COM 层内存泄漏的更多信息，请参看 参考资料。
JavaScript 中的内存泄露模式
JavaScript 是用来向 Web 页面添加动态内容的一种功能强大的脚本语言。它尤其特别有助于一些日常任务，比如验证密码和创建动态菜单组件。JavaScript 易学易用，但却很容易在某些浏览器中引起内存的泄漏。在这个介绍性的文章中，我们解释了 JavaScript 中的泄漏由何引起，展示了常见的内存泄漏模式，并介绍了如何应对它们。
注意本文假设您已经非常熟悉使用 JavaScript 和 DOM 元素来开发 Web 应用程序。本文尤其适合使用 JavaScript 进行 Web 应用程序开发的开发人员，也可供有兴趣创建 Web 应用程序的客户提供浏览器支持以及负责浏览器故障排除的人员参考。
JavaScript 中的内存泄漏
JavaScript 是一种垃圾收集式语言，这就是说，内存是根据对象的创建分配给该对象的，并会在没有对该对象的引用时由浏览器收回。JavaScript 的垃圾收集机制本身并没有问题，但浏览器在为 DOM 对象分配和恢复内存的方式上却有些出入。
Internet Explorer 和 Mozilla Firefox 均使用引用计数来为 DOM 对象处理内存。在引用计数系统，每个所引用的对象都会保留一个计数，以获悉有多少对象正在引用它。如果计数为零，该对象就会被销毁，其占用的内存也会返回给堆。虽然这种解决方案总的来说还算有效，但在循环引用方面却存在一些盲点。
循环引用的问题何在？
当两个对象互相引用时，就构成了循环引用，其中每个对象的引用计数值都被赋 1。在纯垃圾收集系统中，循环引用问题不大：若涉及到的两个对象中的一个对象被任何其他对象引用，那么这两个对象都将被垃圾收集。而在引用计数系统，这两个对象都不能被销毁，原因是引用计数永远不能为零。在同时使用了垃圾收集和引用计数的混合系统中，将会发生泄漏，因为系统不能正确识别循环引用。在这种情况下，DOM 对象和 JavaScript 对象均不能被销毁。清单 1 显示了在 JavaScript 对象和 DOM 对象间存在的一个循环引用。
清单 1. 循环引用导致了内存泄漏
<html>
<body>
<script type="text/javascript">
document.write("circular references between JavaScript and DOM!");
var obj;
window.onload = function(){
obj=document.getElementById("DivElement");
document.getElementById("DivElement").expandoProperty=obj;
obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX"));
};
</script>
<div id="DivElement">Div Element</div>
</body>
</html>
如上述清单中所示，JavaScript 对象 obj 拥有到 DOM 对象的引用，表示为 DivElement。而 DOM 对象则有到此 JavaScript 对象的引用，由 expandoProperty 表示。可见，JavaScript 对象和 DOM 对象间就产生了一个循环引用。由于 DOM 对象是通过引用计数管理的，所以两个对象将都不能销毁。
另一种内存泄漏模式
在清单 2 中，通过调用外部函数 myFunction 创建循环引用。同样，JavaScript 对象和 DOM 对象间的循环引用也会导致内存泄漏。
清单 2. 由外部函数调用引起的内存泄漏
<html> <head> <script type="text/javascript"> document.write(" object s between JavaScript and DOM!"); function myFunction(element) { this.elementReference = element; // This code forms a circular reference here //by DOM-->JS-->DOM element.expandoProperty = this; } function Leak() { //This code will leak new myFunction(document.getElementById("myDiv")); } </script> </head> <body onload="Leak()"> <div id="myDiv"></div> </body> </html>
正如这两个代码示例所示，循环引用很容易创建。在 JavaScript 最为方便的编程结构之一：闭包中，循环引用尤其突出。
JavaScript 中的闭包
JavaScript 的过人之处在于它允许函数嵌套。一个嵌套的内部函数可以继承外部函数的参数和变量，并由该外部函数私有。清单 3 显示了内部函数的一个示例。
清单 3. 一个内部函数
function parentFunction(paramA) { var a = paramA; function childFunction() { return a + 2; } return childFunction(); }
JavaScript 开发人员使用内部函数来在其他函数中集成小型的实用函数。如清单 3 所示，此内部函数 childFunction 可以访问外部函数 parentFunction 的变量。当内部函数获得和使用其外部函数的变量时，就称其为一个闭包。
了解闭包
考虑如清单 4 所示的代码片段。
清单 4. 一个简单的闭包
<html> <body> <script type="text/javascript"> document.write("Closure Demo!!"); window.onload= function closureDemoParentFunction(paramA) { var a = paramA; return function closureDemoInnerFunction (paramB) { alert( a +" "+ paramB); }; }; var x = closureDemoParentFunction("outer x"); x("inner x"); </script> </body> </html>
在上述清单中，closureDemoInnerFunction 是在父函数 closureDemoParentFunction 中定义的内部函数。当用外部的 x 对 closureDemoParentFunction 进行调用时，外部函数变量 a 就会被赋值为外部的 x。函数会返回指向内部函数 closureDemoInnerFunction 的指针，该指针包括在变量 x 内。
外部函数 closureDemoParentFunction 的本地变量 a 即使在外部函数返回时仍会存在。这一点不同于 C/C++ 这样的编程语言，在 C/C++ 中，一旦函数返回，本地变量也将不复存在。在 JavaScript 中，在调用 closureDemoParentFunction 的时候，带有属性 a 的范围对象将会被创建。该属性包括值 paramA，又称为“外部 x”。同样地，当 closureDemoParentFunction 返回时，它将会返回内部函数 closureDemoInnerFunction，该函数包括在变量 x 中。
由于内部函数持有到外部函数的变量的引用，所以这个带属性 a 的范围对象将不会被垃圾收集。当对具有参数值 inner x 的 x 进行调用时，即 x("inner x")，将会弹出警告消息，表明 “outer x innerx”。
清单 4 简要解释了 JavaScript 闭包。闭包功能非常强大，原因是它们使内部函数在外部函数返回时也仍然可以保留对此外部函数的变量的访问。不幸的是，闭包非常易于隐藏 JavaScript 对象 和 DOM 对象间的循环引用。
闭包和循环引用
在清单 5 中，可以看到一个闭包，在此闭包内，JavaScript 对象（obj）包含到 DOM 对象的引用（通过 id "element" 被引用）。而 DOM 元素则拥有到 JavaScript obj 的引用。这样建立起来的 JavaScript 对象和 DOM 对象间的循环引用将会导致内存泄漏。
清单 5. 由事件处理引起的内存泄漏模式
<html> <body> <script type="text/javascript"> document.write("Program to illustrate memory leak via closure"); window.onload=function outerFunction(){ var obj = document.getElementById("element"); obj.onclick=function innerFunction(){ alert("Hi! I will leak"); }; obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX")); // This is used to make the leak significant }; </script> <button id="element">Click Me</button> </body> </html>
避免内存泄漏
幸好，JavaScript 中的内存泄漏是可以避免的。当确定了可导致循环引用的模式之后，正如我们在上述章节中所做的那样，您就可以开始着手应对这些模式了。这里，我们将以上述的 由事件处理引起的内存泄漏模式 为例来展示三种应对已知内存泄漏的方式。
一种应对 清单 5 中的内存泄漏的解决方案是让此 JavaScript 对象 obj 为空，这会显式地打破此循环引用，如清单 6 所示。
清单 6. 打破循环引用
<html> <body> <script type="text/javascript"> document.write("Avoiding memory leak via closure by breaking the circular reference"); window.onload=function outerFunction(){ var obj = document.getElementById("element"); obj.onclick=function innerFunction() { alert("Hi! I have avoided the leak"); // Some logic here }; obj.bigString=new Array(1000).join(new Array(2000).join("XXXXX")); obj = null; //This breaks the circular reference }; </script> <button id="element">"Click Here"</button> </body> </html>
清单 7 是通过添加另一个闭包来避免 JavaScript 对象和 DOM 对象间的循环引用。
清单 7. 添加另一个闭包
<html> <body> <script type="text/javascript"> document.write("Avoiding a memory leak by adding another closure"); window.onload=function outerFunction(){ var anotherObj = function innerFunction() { // Some logic here alert("Hi! I have avoided the leak"); }; (function anotherInnerFunction(){ var obj = document.getElementById("element"); obj.onclick=anotherObj })(); }; </script> <button id="element">"Click Here"</button> </body> </html>
清单 8 则通过添加另一个函数来避免闭包本身，进而阻止了泄漏。
清单 8. 避免闭包自身
<html> <head> <script type="text/javascript"> document.write("Avoid leaks by avoiding closures!"); window.onload=function() { var obj = document.getElementById("element"); obj.onclick = doesNotLeak; } function doesNotLeak() { //Your Logic here alert("Hi! I have avoided the leak"); } </script> </head> <body> <button id="element">"Click Here"</button> </body> </html>