深入浅出JavaScript内存泄漏

在过去一些的时候，Web开发人员并没有太多的去关注内存泄露问题。那时的页面间联系大都比较简单，并主要使用不同的连接地址在同一个站点中导航，这样的设计方式是非常有利于浏览器释放资源的。即使Web页面运行中真的出现了资源泄漏，那它的影响也是非常有限而且常常是不会被人在意的。

创新互联是一家专业提供米易企业网站建设,专注与网站设计、成都网站建设、html5、小程序制作等业务。10年已为米易众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。

推荐阅读：早该知道的7个JavaScript技巧

今天人们对Web应用有了高更的要求。一个页面很可能数小时不会发生URL跳转，并同时通过Web服务动态的更新页面内容。复杂的事件关联设计、基于对象的JavaScript和DHTML技术的广泛采用，使得代码的能力达到了其承受的极限。在这样的情况和改变下，弄清楚内存泄露方式变得非常的急迫，特别是过去这些问题都被传统的页面导航方法给屏蔽了。

还算好的事情是，当你明确了希望寻找什么时，内存泄露方式是比较容易被确定的。大多数你能遇到的泄露问题我们都已经知道，你只需要少量额外的工作就会给你带来好处。虽然在一些页面中少量的小泄漏问题仍会发生，但是主要的问题还是很容易解决的。

泄露方式

在接下来的内容中，我们会讨论内存泄露方式，并为每种方式给出示例。其中一个重要的示例是JavaScript中的Closure技术，另一个示例是在事件执行中使用Closures。当你熟悉本示例后，你就能找出并修改你已有的大多数内存泄漏问题，但是其它Closure相关的问题可能又会被忽视。

现在让我们来看看这些个方式都有什么：

1、循环引用(Circular References) — IE浏览器的COM组件产生的对象实例和网页脚本引擎产生的对象实例相互引用，就会造成内存泄漏。这也是Web页面中我们遇到的最常见和主要的泄漏方式；

2、内部函数引用(Closures) — Closures可以看成是目前引起大量问题的循环应用的一种特殊形式。由于依赖指定的关键字和语法结构，Closures调用是比较容易被我们发现的；

3、页面交叉泄漏(Cross-Page Leaks) — 页面交叉泄漏其实是一种较小的泄漏，它通常在你浏览过程中，由于内部对象薄计引起。下面我们会讨论DOM插入顺序的问题，在那个示例中你会发现只需要改动少量的代码，我们就可以避免对象薄计对对象构建带来的影响；

4、貌似泄漏(Pseudo-Leaks) — 这个不是真正的意义上的泄漏，不过如果你不了解它，你可能会在你的可用内存资源变得越来越少的时候极度郁闷。为了演示这个问题，我们将通过重写 Script元素中的内容来引发大量内存的"泄漏"。

循环引用

循环引用基本上是所有泄漏的始作俑者。通常情况下，脚本引擎通过垃圾收集器(GC)来处理循环引用，但是某些未知因数可能会妨碍从其环境中释放资源。对于 IE来说，某些DOM对象实例的状态是脚本无法得知的。下面是它们的基本原则：

#p#

Figure 1: 基本的循环引用模型

本模型中引起的泄漏问题基于COM的引用计数。脚本引擎对象会维持对DOM对象的引用，并在清理和释放DOM对象指针前等待所有引用的移除。在我们的示例中，我们的脚本引擎对象上有两个引用：脚本引擎作用域和DOM对象的expando属性。

当终止脚本引擎时第一个引用会释放，DOM对象引用由于在等待脚本擎的释放而并不会被释放。你可能会认为检测并修复假设的这类问题会非常的容易，但事实上这样基本的的示例只是冰山一角。你可能会在30个对象链的末尾发生循环引用，这样的问题排查起来将会是一场噩梦。如果你仍不清楚这种泄漏方式在HTML代码里到底怎样，你可以通过一个全局脚本变量和一个DOM对象来引发并展现它。

 
 
 
  
  
   
  
  
   
  
  
   
  
  
  var myGlobalObject;  
  
  
  function SetupLeak()  
  
  
  {  
  
  
  // First set up the script scope to element reference  
  
  
  myGlobalObject = document.getElementById("LeakedDiv");  
  
  
   
  
  
  // Next set up the element to script scope reference  
  
  
  document.getElementById("LeakedDiv").expandoProperty = myGlobalObject;  
  
  
  }  
  
  
   
  
  
  function BreakLeak()  
  
  
  {  
  
  
  document.getElementById("LeakedDiv").expandoProperty = null;  
  
  
  }

你可以使用直接赋null值得方式来破坏该泄漏情形。在页面文档卸载前赋null值，将会让脚本引擎知道对象间的引用链没有了。现在它将能正常的清理引用并释放DOM对象。在这个示例中，作为Web开发员的你因该更多的了解了对象间的关系。

作为一个基本的情形，循环引用可能还有更多不同的复杂表现。对基于对象的JavaScript，一个通常用法是通过封装JavaScript对象来扩充DOM对象。在构建过程中，你常常会把DOM对象的引用放入JavaScript对象中，同时在DOM对象中也存放上对新近创建的JavaScript对象的引用。你的这种应用模式将非常便于两个对象之间的相互访问。这是一个非常直接的循环引用问题，但是由于使用不用的语法形式可能并不会让你在意。要破环这种使用情景可能变得更加复杂，当然你同样可以使用简单的示例以便于清楚的讨论。

 
 
 
  
  
   
  
  
   
  
  
   
  
  
   
  
  
  function Encapsulator(element)  
  
  
  {  
  
  
  // Set up our element  
  
  
  this.elementReference = element;  
  
  
   
  
  
  // Make our circular reference  
  
  
  element.expandoProperty = this;  
  
  
  }  
  
  
   
  
  
  function SetupLeak()  
  
  
  {  
  
  
  // The leak happens all at once  
  
  
  new Encapsulator(document.getElementById("LeakedDiv"));  
  
  
  }  
  
  
   
  
  
  function BreakLeak()  
  
  
  {  
  
  
  document.getElementById("LeakedDiv").expandoProperty = null;  
  
  
  }

更复杂的办法还有记录所有需要解除引用的对象和属性，然后在Web文档卸载的时候统一清理，但大多数时候你可能会再造成额外的泄漏情形，而并没有解决你的问题。

由于闭包函数会使程序员在不知不觉中创建出循环引用，所以它对资源泄漏常常有着不可推卸的责任。而在闭包函数自己被释放前，我们很难判断父函数的参数以及它的局部变量是否能被释放。实际上闭包函数的使用已经很普通，以致人们频繁的遇到这类问题时我们却束手无策。在详细了解了闭包背后的问题和一些特殊的闭包泄漏示例后，我们将结合循环引用的图示找到闭包的所在，并找出这些不受欢迎的引用来至何处。

普通的循环引用，是两个不可探知的对象相互引用造成的，但是闭包却不同。代替直接造成引用，闭包函数则取而代之从其父函数作用域中引入信息。通常，函数的局部变量和参数只能在该被调函数自身的生命周期里使用。当存在闭包函数后，这些变量和参数的引用会和闭包函数一起存在，但由于闭包函数可以超越其父函数的生命周期而存在，所以父函数中的局部变量和参数也仍然能被访问。

在下面的示例中，参数1将在函数调用终止时正常被释放。当我们加入了一个闭包函数后，一个额外的引用产生，并且这个引用在闭包函数释放前都不会被释放。如果你碰巧将闭包函数放入了事件之中，那么你不得不手动从那个事件中将其移出。如果你把闭包函数作为了一个expando属性，那么你也需要通过置null将其清除。

同时闭包会在每次调用中创建，也就是说当你调用包含闭包的函数两次，你将得到两个独立的闭包，而且每个闭包都分别拥有对参数的引用。由于这些显而易见的因素，闭包确实非常用以带来泄漏。下面的示例将展示使用闭包的主要泄漏因素：

function AttachEvents(element)
{
// This structure causes element to ref ClickEventHandler
element.attachEvent("onclick", ClickEventHandler);
function ClickEventHandler()
{
// This closure refs element
}
}
function SetupLeak()
{
// The leak happens all at once
AttachEvents(document.getElementById("LeakedDiv"));
}
function BreakLeak()
{
}

function AttachEvents(element)
{
// In order to remove this we need to put
// it somewhere. Creates another ref
element.expandoClick = ClickEventHandler;
// This structure causes element to ref ClickEventHandler
element.attachEvent("onclick", element.expandoClick);
function ClickEventHandler()
{
// This closure refs element
}
}
function SetupLeak()
{
// The leak happens all at once
AttachEvents(document.getElementById("LeakedDiv"));
}
function BreakLeak()
{
document.getElementById("LeakedDiv").detachEvent("onclick",
document.getElementById("LeakedDiv").expandoClick);
document.getElementById("LeakedDiv").expandoClick = null;
}

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("");
var childDiv =
document.createElement("");
// 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("");
var childDiv =
document.createElement("");
// 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;
}
Memory Leaking Insert
Clean Insert

function LeakMemory()
{
// Do it a lot, look at Task Manager for memory response
for(i = 0; i < 5000; i++)
{
hostElement.text = "function foo() { }";
}
}
Memory Leaking Insert
function foo() { }