这个代码运行之后，只要 element 不再被引用，a、b 也会被回收。题主的意图估计是希望 a、b 的生命周期比 element 短。那是你的设计错误。因为你把 element 的一个 event-handler 设计成依赖于 a、b，那 a、b 当然就要和 element 共生死了。题主给的这个逻辑用不用闭包都会有这个问题。如果硬要释放 a、b，那就是 release before use，会造成 null-dereference error。
很多资料都过时了，内存泄露这个点在js圈子里更多的是惯性而不是实际影响。一般情况下，不用担心那么多，浏览器有自己的垃圾回收机制，只要你不作死把所有不再需要的资源都放到某个永远不会释放的数组什么的里面就好。遇到具体的内存泄露问题再具体解决。
var test_obj = {
closure_fn: function () {
var that = this;
var val = setTimeout(function () {
console.log('Rambo!');
that.closure_fn();
}, 1000);
}
};
test_obj.closure_fn();
test_obj = null;
// 尝试之后，你会发现这他妈才是可怕的。
var test_obj_2 = {
closure_fn: function () {
var that = test_obj_2;
var val = setTimeout(function () {
console.log('Rambo!');
that ? that.closure_fn() : clearTimeout(val);
}, 1000);
}
};
我记得 @贺师俊 老师在ITEYE上有过一段关于这个的讨论。
首先，这是一个闭包。
题主贴的代码里之所以造成内存泄露是因为循环引用。一个闭包在创建时会附有三个属性：VO、thisValue、scope chain，而其中scope chain是指向外层parent scope的引用。
因此这个闭包实际上保存了外层函数中element的引用，而element本身又引用了闭包，循环引用因此而见。
但是我记得hax同时提到，因为循环引用导致的泄露实际上是IE浏览器引擎的bug而导致的，而如果element不是dom对象，不产生循环引用也就不会leak了。
这个不好说，有可能会泄露吧。。
我也有话说：
首先，IE9之前的版本因为对JScript对象和COM对象使用不同的垃圾收集机制，因此才有机会出现这个问题。再者，闭包的作用域链中保存着html元素，且包含循环引用。第三，取消循环引用并置空引用的html元素就可有效避免
仅供参考，未作过实验验证（附近确实找不到装IE6和IE7的机器了）：
据微软称这是IE6在XP上特有的问题，照下面这篇最后更新日期为2011年10月的kb文章
A memory leak occurs in Internet Explorer 6 when you view a Web page that uses JScript scripting on a Windows XP-based computer
的说法，如果你的系统包含了这个更新：
http://support.microsoft.com/kb/947864就没有这个问题了。
其实我很好奇的是，闭包，在什么情况下才会真的造成内存泄漏呢？
或许是我代码写少了，真的重来没有过内存泄漏的时候...
首先，题主问的闭包是否都会内存泄露，这个可以明确说不是。题主贴的代码产生了内存泄露是因为循环引用。低版本ie对这种循环引用的处理有bug，会造成内存泄露。
想要避免泄露，应该break circle。让element = null。这样handler就不持有dom的引用了。
内存泄漏和内存使用这两个概念搞清楚？
