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