垃圾回收机制

原理

http://www.jb51.net/article/75292.htm

找到不再被使用的变量，然后释放其占用的内存，但这个过程不是时时的，因为其开销比较大，所以垃圾回收器会按照固定时间间隔周期性的执行

IE6的垃圾回收是根据内存分配量运行的，当环境中存在256个变量、4096个对象、64k的字符串任意一种情况的时候就会触发垃圾回收器工作，

不再使用的变量也就是生命周期结束的变量，当然只可能是局部变量，全局变量的生命周期直至浏览器卸载页面才会结束。局部变量只在函数的执行过程中存在，而在这个过程中会为局部变量在栈或堆上分配相应的空间，以存储它们的值，然后在函数中使用这些变量，直至函数结束，而闭包中由于内部函数的原因，外部函数并不能算是结束。

回收方式

a.标记清除

当变量进入环境时，将这个变量标记为“进入环境”;当变量离开环境时，则将其标记为“离开环境”。标记“离开环境”的就回收内存

垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记（当然，可以使用任何标记方式）。然后，它会去掉环境中的变量以及被环境中的变量引用的变量的标记（闭包）。而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。最后，垃圾回收器完成内存清除工作，销毁那些带标记的值并回收它们所占用的内存空间。

（前端小白，如有错误，欢迎指正~~）

b.引入计数(低级浏览器)

当变量声明，第一次赋值时记为1，然后当这个变量值改变时，记录为0，将计数为0的回收

IE中有一部分对象并不是原生js对象。例如，其内存泄露DOM和BOM中的对象就是使用C++以COM对象的形式实现的，而COM对象的垃圾回收机制采用的就是引用计数策略。因此，即使IE的js引擎采用标记清除策略来实现，但js访问的COM对象依然是基于引用计数策略的。换句话说，只要在IE中涉及COM对象，就会存在循环引用的问题

var element = document.getElementById("some_element");

var myObject = new Object();

myObject.e = element;

element.o = myObject;

这个例子在一个DOM元素（element)与一个原生js对象（myObject)之间创建了循环引用。其中，变量myObject有一个名为element的属性指向element对象；而变量element也有一个属性名为o回指myObject。由于存在这个循环引用，即使例子中的DOM从页面中移除，它也永远不会被回收。

window.οnlοad=function outerFunction(){  var obj = document.getElementById("element");  obj.οnclick=function innerFunction(){}; };

这段代码看起来没什么问题，但是obj引用了document.getElementById(“element”)，而document.getElementById(“element”)的onclick方法会引用外部环境中德变量，自然也包括obj，是不是很隐蔽啊。

解决办法

最简单的方式就是自己手工解除循环引用，比如刚才的函数可以这样

1 2	myObject.element = null; element.o = null;

1 2 3 4 5

window.οnlοad=function outerFunction(){  var obj = document.getElementById("element");  obj.οnclick=function innerFunction(){};  obj=null; };

将变量设置为null意味着切断变量与它此前引用的值之间的连接。当垃圾回收器下次运行时，就会删除这些值并回收它们占用的内存。

内存泄露

a.意外的全局变量引起的内存泄露

原因: 全局变量不会被回收

解决：使用严格模式避免

b.闭包引起的

原因: 活动对象被引用，使闭包内的变量不会被释放

解决: 将活动对象赋值为null

c.被清理的DOM元素的引用

原因: 虽然DOM被删掉了，但对象中还存在对DOM的引用

解决: 将对象赋值为null

d.被遗忘的定时器或回调

原因: 定时器内部实现闭包，回调也是闭包

解决: 清理定时器clearInterval、null

内存管理

1、什么时候触发垃圾回收？

垃圾回收器周期性运行，如果分配的内存非常多，那么回收工作也会很艰巨，确定垃圾回收时间间隔就变成了一个值得思考的问题。IE6的垃圾回收是根据内存分配量运行的，当环境中存在256个变量、4096个对象、64k的字符串任意一种情况的时候就会触发垃圾回收器工作，看起来很科学，不用按一段时间就调用一次，有时候会没必要，这样按需调用不是很好吗？但是如果环境中就是有这么多变量等一直存在，现在脚本如此复杂，很正常，那么结果就是垃圾回收器一直在工作，这样浏览器就没法儿玩儿了。

微软在IE7中做了调整，触发条件不再是固定的，而是动态修改的，初始值和IE6相同，如果垃圾回收器回收的内存分配量低于程序占用内存的15%，说明大部分内存不可被回收，设的垃圾回收触发条件过于敏感，这时候把临街条件翻倍，如果回收的内存高于85%，说明大部分内存早就该清理了，这时候把触发条件置回。这样就使垃圾回收工作职能了很多

2、合理的GC方案

1）、Javascript引擎基础GC方案是（simple GC）：mark and sweep（标记清除），即：

• （1）遍历所有可访问的对象。
• （2）回收已不可访问的对象。

2）、GC的缺陷

和其他语言一样，javascript的GC策略也无法避免一个问题：GC时，停止响应其他操作，这是为了安全考虑。而Javascript的GC在100ms甚至以上，对一般的应用还好，但对于JS游戏，动画对连贯性要求比较高的应用，就麻烦了。这就是新引擎需要优化的点：避免GC造成的长时间停止响应。

（前端小白，如有错误，欢迎指正~~）