在过去一些的时候，Web开发人员并没有太多的去关注内存泄露问题。那时的页面间联系大都比较简单，并主要使用不同的连接地址在同一个站点中导航，这样的设计方式是非常有利于浏览器释放资源的。即使Web页面运行中真的出现了资源泄漏，那它的影响也是非常有限而且常常是不会被人在意的。
今天人们对Web应用有了高更的要求。一个页面很可能数小时不会发生URL跳转，并同时通过Web服务动态的更新页面内容。复杂的事件关联设计、基于对象的JScript和DHTML技术的广泛采用，使得代码的能力达到了其承受的极限。在这样的情况和改变下，弄清楚内存泄露方式变得非常的急迫，特别是过去这些问题都被传统的页面导航方法给屏蔽了。
还算好的事情是，当你明确了希望寻找什么时，内存泄露方式是比较容易被确定的。大多数你能遇到的泄露问题我们都已经知道，你只需要少量额外的工作就会给你带来好处。虽然在一些页面中少量的小泄漏问题仍会发生，但是主要的问题还是很容易解决的。
什么是内存泄露？
内存泄露是指分配给应用的内存不能被重新分配，即使在内存已经不被使用的时候。正常情况下，垃圾回收器在DOM元素和event处理器不被引用或访 问的时候回收它们。但是，IE的早些版本（IE7和之前）中内存泄露是很容易出现的，因为内存管理器不能正确理解Javascript生命周期而且在周期 被打破(可以通过赋值为null实现)前不会回收内存。
为什么需要注意它？
在大型Web应用程序中内存泄露是一种常见的意外编程错误。内存泄露会降低Web应用程序的性能，直到浪费的内存超过了系统所能分配的，应用程序将 不能使用。作为一Web开发者，开发一个满足功能要求的应用程序只是第一步，性能要求和Web应用程序的成功是同样重要的，更何况它可能会导致应用程序错 误或浏览器崩溃。
常见内存泄露的主要方式
(1)、循环引用(Circular References)
IE浏览器的COM组件产生的对象实例和网页脚本引擎产生的对象实例相互引用，就会造成内存泄漏。这也是Web页面中我们遇到的最常见和主要的泄漏方式；
一个很简单的例子：一个DOM对象被一个Javascript对象引用，与此同时这个Dom又引用了这个Javascript对象或其它的Javascript对象，这个DOM对象可 能会引发内存泄露。这个DOM对象的引用将不会在脚本停止的时候被垃圾回收器回收。要想破坏循环引用，引用DOM元素的对象或DOM对象的引用需要被赋值 为null。
(2)、Javascript闭包(Closures)
Closures可以看成是目前引起大量问题的循环应用的一种特殊形式。由于依赖指定的关键字和语法结构，Closures调用是比较容易被我们发现的；
因为Javascript范围的限制，许多实现依赖Javascript闭包，闭包可以导致内存泄露是因为内部方法保持一个对外部方法变量的引用，所以尽管方法返回了内部方法还可以继续访问在外部方法中定义的私有变量。对Javascript程序员来说最好的做法是在页面重载前断开所有的事件处理器。
(3)、页面交叉泄漏(Cross-Page Leaks)
页面交叉泄漏其实是一种较小的泄漏，它通常在你浏览过程中，由于内部对象创建引起。
当2个不同范围的 DOM 对象连添加到一起的时候一个临时的对象会被创建。这个DOM对象改变范围到document时，那个临时对象就没用了。也就是说， DOM 对象应该按照从当前页面存在的最上面的 DOM 元素开始往下直到剩下的 DOM 元素的顺序添加，这样它们就总是有同样的范围，不会产生临时对象。
(4). 自动类型装箱转换，下面的代码在早期ie系列中会导致内存泄露
var s=”lalala”;
alert(s.length);
s本身是一个string而非object，它没有length属性，所以当访问length时，JS引擎会自动创建一个临时String对象封装s，而这个对象一定会泄露。这个bug匪夷所思，所幸解决起来相当容易，记得所有值类型做.运算之前先显式转换一下：
var s="lalala";
alert(new String(s).length);
如何检测？
内存泄露对开发者来说一般很难检测因为它们是由一些大量代码中的意外的错误引起的，但它在系统内存不足前并不影响程序的功能。这就是为什么会有人在很长时间的测试期中收集应用程序性能指标来测试性能。
最简单的检测内存泄露的方式是用任务管理器检查内存使用情况。在Chrome浏览器的新选项卡中打开应用并查看内存使用量是不是越来越多。还有其他的调试工具提供内存监视器，比如Chrome开发者工具。这是谷歌开者这网站中的堆分析的特性的教程。