1，javascript具有自动的垃圾回收机制，自动内存的分配和无用内存的回收都可以自动管理。垃圾回收器周期性的执行；
2，Javascript的垃圾回收策略分为：引用计数和标记清除；2.1 标记清除：根据变量是否进入环境和离开环境，来判断此变量的标记，如果离开“环境”，则将其的标记更新为“离开环境”，等到下次垃圾回收器执行垃圾回收的时候，对这些已经打上“离开环境”标记的变量执行回收操作，回收其内存。（主流）2.2 引用计数：跟踪变量被引用的次数，当申明一个变量并引用类型值赋给变量时，引用次数+1，每次把该变量赋值给另一个变量的时候，引用计数+1，以此类推；相反，如果包含对这个值引用的变量有获得另外一个值时，引用次数-1，以此类推，当该变量的引用计数等于0时，则说明该变量已经没有变量引用，垃圾回收器下次执行的时候，就会回收该变量，释放该变量所占的内存空间。（注意：引用计数存在一个严重的问题：循环引用。对象 A 中包含一个指向对象 B 的指针，而对象 B 中也包含一个指向对象 A 的引用。）
var objectA = new Object();
var objectB = new Object();
objectA.someOtherObject = objectB;
objectB.anotherObject = objectA;
IE 中有一部分对象并不是原生 JavaScript 对象。例如，其 BOM 和 DOM 中的对象就是使用 C++以 COM（ Component Object Model，组件对象模型）对象的形式实现的，而 COM 对象的垃圾收集机制采用的就是引用计数策略。因此，即使 IE 的 JavaScript 引擎是使用标记清除策略来实现的，但JavaScript 访问的 COM 对象依然是基于引用计数策略的。换句话说，只要在 IE 中涉及 COM 对象，就会存在循环引用的问题。 IE9 把 BOM 和 DOM 对象都转换成了真正的 JavaScript 对象。这样，就避免了两种垃圾收集算法并存导致的问题，也消除了常见的内存泄漏现象。（节选于《Javascript高级程序设计》（第3版））
垃圾收集器是周期性运行的，而且如果为变量分配的内存数量很可观，那么回收工作量也是相当大的。在这种情况下，确定垃圾收集的时间间隔是一个非常重要的问题。说到垃圾收集器多长时间运行一次，不禁让人联想到 IE 因此而声名狼藉的性能问题。 IE 的垃圾收集器是根据内存分配量运行的，具体一点说就是 256 个变量、 4096 个对象（或数组）字面量和数组元素（slot）或者 64KB 的字符串。达到上述任何一个临界值，垃圾收集器就会运行。这种实现方式的问题在于，如果一个脚本中包含那么多变量，那么该脚本很可能会在其生命周期中一直保有那么多的变量。而这样一来，垃圾收集器就不得不频繁地运行。结果，由此引发的严重性能问题促使 IE7 重写了其垃圾收集例程。随着 IE7 的发布，其 JavaScript 引擎的垃圾收集例程改变了工作方式：触发垃圾收集的变量分配、字面量和（或）数组元素的临界值被调整为动态修正。 IE7 中的各项临界值在初始时与 IE6 相等。如果垃圾收集例程回收的内存分配量低于 15%，则变量、字面量和（或）数组元素的临界值就会加倍。如果例程回收了 85%的内存分配量，则将各种临界值重置回默认值。这一看似简单的调整，极大地提升了 IE在运行包含大量JavaScript 的页面时的性能。（节选于《Javascript高级程序设计》（第3版））3，管理内存Javascript分配给web浏览器的可用内存数量通常要比分配给桌面应用程序的少，这样做的目的主要是出于安全方面的考虑，目的是防止运行 JavaScript 的网页耗尽全部系统内存而导致系统崩溃。内存限制问题不仅会影响给变量分配内存，同时还会影响调用栈以及在一个线程中能够同时执行的语句数量。因此，确保占用最少的内存可以让页面获得更好的性能。而优化内存占用的最佳方式，就是为执行中的代码只保存必要的数据。一旦数据不再有用，最好通过将其值设置为 null 来释放其引用——这个做法叫做解除引用（ dereferencing）。这一做法适用于大多数全局变量和全局对象的属性。局部变量会在
它们离开执行环境时自动被解除引用。解除引用的真正作用是让值脱离执行环境，以便垃圾收集器下次运行时将其回收。（节选于《Javascript高级程序设计》（第3版））
