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;  }     

    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;  }     

    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;  }     

在这篇文章中，实际上建议我们除非迫不得已尽量不要创建使用闭包。文章中的示例，给我们演示了非闭包的事件引用方式，即把闭包函数放到页面的全局作用 域中。当闭包函数成为普通函数后，它将不再继承其父函数的参数和局部变量，所以我们也就不用担心基于闭包的循环引用了。在非必要的时候不使用闭包这样的编 程方式可以尽量使我们的代码避免这样的问题。

最后，脚本引擎开发组的Eric Lippert，给我们带来了一篇关于闭包使用通俗易懂的好文章。他的最终建议也是希望在真正必要的时候才使用闭包函数。虽然他的文章没有提及闭包会使用 的真正场景，但是这儿已有的大量示例非常有助于大家起步。

页面交叉泄漏(Cross-Page Leaks)

这种基于插入顺序而常常引起的泄漏问题，主要是由于对象创建过程中的临时对象未能被及时清理和释放造成的。它一般在动态创建页面元素，并将其添加到页面 DOM中时发生。一个最简单的示例场景是我们动态创建两个对象，并创建一个子元素和父元素间的临时域（译者注：这里的域(Scope)应该是指管理元素之 间层次结构关系的对象）。

然后，当你将这两个父子结构元素构成的的树添加到页面DOM树中时，这两个元素将会继承页面DOM中的层次管理域对象，并泄漏之 前创建的那个临时域对象。下面的图示示例了两种动态创建并添加元素到页面DOM中的方法。在第一种方法中，我们将每个子元素添加到它的直接父元素中，最后 再将创建好的整棵子树添加到页面DOM中。当一些相关条件合适时，这种方法将会由于临时对象问题引起泄漏。在第二种方法中，我们自顶向下创建动态元素，并 使它们被创建后立即加入到页面DOM结构中去。由于每个被加入的元素继承了页面DOM中的结构域对象，我们不需要创建任何的临时域。这是避免潜在内存泄漏 发生的好方法。

Figure 3. DOM插入顺序泄漏模型

接下来，我们将给出一个躲避了大多数泄漏检测算法的泄漏示例。因为我们实际上没有泄漏任何可见的元素，并且由于被泄漏的对象太小从而你可能根本不会注意这 个问题。为了使我们的示例产生泄漏，在动态创建的元素结构中将不得不内联的包含一个脚本函数指针。在我们设置好这些元素间的相互隶属关系后这将会使我们泄 漏内部临时脚本对象。由于这个泄漏很小，我们不得不将示例执行成千上万次。

事实上，一个对象的泄漏只有很少的字节。在运行示例并将浏览器导航到一个空白页 面，你将会看到两个版本代码在内存使用上的区别。当我们使用第一种方法，将子元素加入其父元素再将构成的子树加入页面DOM，我们的内存使用量会有微小的 上升。这就是一个交叉导航泄漏，只有当我们重新启动IE进程这些泄漏的内存才会被释放。如果你使用第二种方法将父元素加入页面DOM再将子元素加入其父元 素中，同样运行若干次后，你的内存使用量将不会再上升，这时你会发现你已经修复了交叉导航泄漏的问题。

    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   

这类泄漏应该被澄清，因为这个解决方法有悖于我们在IE中的一些有益经验。创建带有脚本对象的DOM元素，以及它们已进行的相互关联是了解这个泄漏的关键 点。这实际上这对于泄漏来说是至关重要的，因为如果我们创建的DOM元素不包含任何的脚本对象，同时使用相同的方式将它们进行关联，我们是不会有任何泄漏 问题的。示例中给出的第二种技巧对于关联大的子树结构可能更有效（由于在那个示例中我们一共只有两个元素，所以建立一个和页面DOM不相关的树结构并不会 有什么效率问题）。

第二个技巧是在创建元素的开始不关联任何的脚本对象，所以你可以安全的创建子树。当你把你的子树关联到页面DOM上后，再继续处理你需 要的脚本事件。牢记并遵守关于循环引用和闭包函数的使用规则，你不会再在挂接事件时在你的代码中遇到不同的泄漏。

我真的要指出这个问题，因为我们可以看出不是所有的内存泄漏都是可以很容易发现的。它们可能都是些微不足道的问题，但往往需要成千上万次的执行一个更小的 泄漏场景才能使问题显现出来，就像DOM元素插入顺序引起的问题那样。如果你觉得使用所谓的"最佳"经验来编程，那么你就可以高枕无忧，但是这个示例让我 们看到，即使是"最佳"经验似乎也可能带来泄漏。我们这里的解决方案希望能提高这些已有的好经验，或者介绍一些新经验使我们避免泄漏发生的可能。

貌似泄漏(Pseudo-Leaks)

在大多数时候，一些APIs的实际的行为和它们预期的行为可能会导致你错误的判断内存泄漏。貌似泄漏大多数时候总是出现在同一个页面的动态脚本操作中，而 在从一个页面跳转到空白页面的时候发生是非常少见的。那你怎么能象排除页面间泄漏那样来排除这个问题，并且在新任务运行中的内存使用量是否是你所期望的。 我们将使用脚本文本的重写来作为一个貌似泄漏的示例。

象DOM插入顺序问题那样，这个问题也需要依赖创建临时对象来产生"泄漏"。对一个脚本元素对象内部的脚本文本一而再再而三的反复重写，慢慢地你将开始泄 漏各种已关联到被覆盖内容中的脚本引擎对象。特别地，和脚本调试有关的对象被作为完全的代码对象形式保留了下来。

   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() { }  

如果你运行上面的示例代码并使用任务管理器查看，当从"泄漏"页面跳转到空白页面时，你并不会注意到任何脚本泄漏。因为这种脚本泄漏完全发生在页面内部， 而且当你离开该页面时被使用的内存就会回收。对于我们原本所期望的行为来说这样的情况是糟糕的。

你希望当重写了脚本内容后，原来的脚本对象就应该彻底的从 页面中消失。但事实上，由于被覆盖的脚本对象可能已用作事件处理函数，并且还可能有一些未被清除的引用计数。正如你所看到的，这就是貌似泄漏。在表面上内存消耗量可能看起来非常的糟糕，但是这个原因是完全可以接受的。

以上就是JavaScript中出现内存泄漏的原因是什么，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。