本文深入分析 JavaScript 闭包在 Internet Explorer 浏览器中引发的内存泄露问题。通过对比直接循环引用与闭包间接引用的机制，揭示了 IE 旧版本 GC 无法回收 JS 对象与 DOM 对象混合引用的根本原因，并提供了断开引用链的有效修复方案及不同 IE 版本的回收行为差异。
直接循环引用导致的内存泄露
代码如下:
function fors(){
obj_a = obj_b;
obj_b.attr = obj_a;
} 代码如下:
function fors(){
obj_b = {};
obj_b.attr = obj_b;
} 上述两段代码展示了明显的循环引用现象。在 Internet Explorer 浏览器中，这种结构会导致内存泄露。由于 IE 特有的内存回收机制，这些被循环引用的对象会长期占用内存空间而无法被自动释放。
闭包间接引用与内存泄露机制
然而，由闭包引起的内存泄露往往更加隐蔽，因为其循环引用关系是间接形成的。
代码如下:
function iememery(){
var js_obj = document.createElement("div");
js_obj.oncontextmenu = function(){ return false;}
}
<body onload="iememery()">从表面代码来看，似乎不存在任何循环引用。但这实际上是一个闭包结构。根据闭包的特性，内部函数有权访问外部函数的变量对象。因此，当 iememery() 函数执行完毕后：
js_obj 是一个 DOM 元素的引用，该 DOM 元素长期存在于网页中不会消失。而该 DOM 元素的 oncontextmenu 属性指向一个内部函数（即闭包），这个匿名函数又通过作用域链与 js_obj 存在隐藏的关联。
由此形成了一个循环引用，具体表现为：
js_obj.oncontextmenu 间接引用到了 js_obj。也就是说，这个对象的一个属性，通过闭包机制间接地引用了自身。
只要存在循环引用，就会在 IE 环境下产生内存泄露。你可以打开 Windows 任务管理器，在 IE 中不停刷新包含此代码的 HTML 页面，观察 Iexplore.exe 进程的内存占用情况。你会发现内存占用持续上升，且不会自动回收降低。
修复方案与不同 IE 版本的回收行为
解决办法：
代码如下:
function iememery(){
var js_obj = document.createElement("div");
js_obj.oncontextmenu = function(){ return false;}; js_obj.oncontextmenu = null;//加上这句，断开引用 }当 IE 中发生 JavaScript 对象与 DOM 对象之间的循环引用，且后续没有其他引用指向它们时：
如果是 IE 6，内存将发生泄露，直到关闭 IE 进程为止。
如果是 IE 7，内存将发生泄露，直到离开当前页面为止。
如果是 IE 8，GC 回收器会回收它们的内存，无论当前是否处于兼容性模式。
之前的 IE JavaScript 引擎中的 GC 回收器只能处理 JavaScript 对象，不能处理 DOM 对象。