一.垃圾回收
JS的垃圾回收机制是为了以防内存泄漏，内存泄漏的含义就是当已经不需要某块内存时这块内存还存在着，垃圾回收机制就是间歇的不定期的寻找到不再使用的变量，并释放掉它们所指向的内存。
垃圾回收的方式：
① 标记清除：
垃圾回收器会在运行的时候给存储在内存中的所有变量加上标记，然后去掉环境中的变量以及被环境中变量所引用的变量（闭包），在这些完成之后仍存在标记的就是要删除的变量了，因为环境中的变量已经无法访问到这些变量了，然后垃圾回收器相会这些带有标记的变量机器所占空间。至于怎么标记有很多种方式，比如特殊位的反转、维护一个列表等，这些并不重要。
②引用计数：
在低版本IE中经常会出现内存泄露，很多时候就是因为其采用引用计数方式进行垃圾回收。引用计数的策略是跟踪记录每个值被使用的次数，当声明了一个变量并将一个引用类型赋值给该变量的时候这个值的引用次数就加1，如果该变量的值变成了另外一个，则这个值得引用次数减1，当这个值的引用次数变为0的时候，说明没有变量在使用，这个值没法被访问了，因此可以将其占用的空间回收，这样垃圾回收器会在运行的时候清理掉引用次数为0的值占用的空间。为什么很少有浏览器采用，还会带来内存泄露问题呢？主要是因为这种方式没办法解决循环引用问题。
合理的GC方案
Javascript引擎基础GC方案是（simple GC）：mark and sweep（标记清除），即：
遍历所有可访问的对象。
回收已不可访问的对象。
GC的缺陷
和其他语言一样，javascript的GC策略也无法避免一个问题：GC时，停止响应其他操作，这是为了安全考虑。而Javascript的GC在100ms甚至以上，对一般的应用还好，但对于JS游戏，动画对连贯性要求比较高的应用，就麻烦了。这就是新引擎需要优化的点：避免GC造成的长时间停止响应。
二、内存泄漏
引起内存泄漏的可能：
1. 意外的全局变量引起的内存泄漏。
原因：全局变量，不会被回收。
解决：使用严格模式避免。
2. 闭包引起的内存泄漏
原因：闭包可以维持函数内局部变量，使其得不到释放。
解决：将事件处理函数定义在外部，解除闭包,或者在定义事件处理函数的外部函数中，删除对dom的引用。
3. 没有清理的DOM元素引用
原因：虽然别的地方删除了，但是对象中还存在对dom的引用
解决：手动删除。
4. 被遗忘的定时器或者回调
原因：定时器中有dom的引用，即使dom删除了，但是定时器还在，所以内存中还是有这个dom。
解决：手动删除定时器和dom。
5. 子元素存在引用引起的内存泄漏
原因：div中的ul li 得到这个div，会间接引用某个得到的li，那么此时因为div间接引用li，即使li被清空，也还是在内存中，并且只要li不被删除，他的父元素都不会被删除。
解决：手动删除清空。
