javascript的垃圾回收机制与内存管理

原创 2017-01-17 17:35:31 679
摘要:对于其他语言来说,如C,C++,需要开发者手动的来跟踪内存,而JS的垃圾回收机制使得JS开发人员无需再关系内存的情况,所有的内存分配以及回收都会由垃圾回收器自动完成,执行环境会对执行过程中占有的内存负责。其原理就是找出那些不在被使用的变量,然后释放其所占有的内存。回收器一般是按照固定的时间间隔或者预设的时间进行处理的。e.g. 1function test1(){  

对于其他语言来说,如C,C++,需要开发者手动的来跟踪内存,而JS的垃圾回收机制使得JS开发人员无需再关系内存的情况,所有的内存分配以及回收都会由垃圾回收器自动完成,执行环境会对执行过程中占有的内存负责。其原理就是找出那些不在被使用的变量,然后释放其所占有的内存。回收器一般是按照固定的时间间隔或者预设的时间进行处理的。

e.g. 1

function test1(){
    var i ={name:’nyf’};
}
function test2(){
    var i ={name:’nyf’};
    return i;
}
var m1 = test1();
var m2 = test2();

一般来说在e.g.1中,当 test1调用时,进入 test1 的环境,那么内存中会开辟存放 {name:’nyf’} 对象的内存,当调用结束后,出了 test1 的环境,那么该内存会被JS引擎中的垃圾回收器自动释放其内存。

在test2中,对象被返回,并且被变量 m2 所指向,所以虽然说在调用完 test2 后出了其环境,但是由于m2仍然持续着对对象的链接关系,所以该对象不会被释放。

但是我们需要注意上述两个例子函数中其实均有2块的内存占用,一个是变量名 i 以及对象 {name:’nyf’} ,i中只是保存着对该对象的地址值。运行test2 未被释放的只是对象,变量名i在2个方法中均被释放,i值才是JS引擎真正需要处理的目标。对于返回的对象,已经返回到上一层的环境,当没有变量再对其进行引用的时候自然也会变会被释放(个人理解)

垃圾回收机制的种类

目前JS的垃圾回收机制无非就是两种:1.标记清除(make-and-sweep) 2.引用计数(reference counting)

  1. 标记清除:标记清除简单的来说就是给各个变量名打上 YES or NO的标签以供JS引擎进行处理(当然打什么标签自己理解即可)。在和执行上下文类似的的环境中当变量名称进入环境的时候,那么变量会被打上 YES。一般来说是绝对不会释放被打上 YES 标签的变量内存的,一旦变量在出了该环境时,变会被打上 NO 标签(和作用域貌似有点像),JS引擎会在一定时间间隔或者设置的时间来进行扫描,对NO标签的进行剔除以释放其内存。

functiontest(){
 vara = 10 ; //被标记
 ,进入环境
 varb = 20 ; //被标记
 ,进入环境
}
test();//执行完毕
 之后 a、b又被标离开环境,被回收。

2.引用计数(查了很多资料,还是无法找到其真正的计算方式)

一般来说,引用计数的含义是跟踪记录每个值被引用的次数。当声明一个变量并将一个引用类型值赋给该变量时,则这个值的引用次数便是1,如果同一个值又被赋给另一个变量,则该值的引用次数加1,相反,如果包含对这个值引用的变量又取得了另一个值,则这个值的引用次数减1。当这个值的引用次数为0时,说明没有办法访问到它了,因而可以将其占用的内存空间回收。(感觉是有问题的)

functiontest(){
 vara = {} ; //a的引用次数为0
 varb = a ; //a的引用次数加1,为1
 varc =a; //a的引用次数再加1,为2
 varb ={}; //a的引用次数减1,为1
}

Netscape Navigator3是最早使用引用计数策略的浏览器,但很快它就遇到一个严重的问题:循环引用。循环引用指的是对象A中包含一个指向对象B的指针,而对象B中也包含一个指向对象A的引用。

functionfn() {
 vara = {};
 varb = {};
 a.pro
 = b;
 b.pro
 = a;
}
 
fn();

  以上代码a和b的引用次数都是2,fn()执行完毕后,两个对象都已经离开环境,在标记清除方式下是没有问题的,但是在引用计数策略下,因为a和b的引用次数不为0,所以不会被垃圾回收器回收内存,如果fn函数被大量调用,就会造成内存泄露。在IE7与IE8上,内存直线上升。

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

varelement = document.getElementById("some_element");
varmyObject = newObject();
myObject.e
 = element;
element.o
 = myObject;

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

看上面的例子,有同学回觉得太弱了,谁会做这样无聊的事情,其实我们是不是就在做

window.onload=functionouterFunction(){
 varobj = document.getElementById("element");
 obj.onclick=functioninnerFunction(){};
};

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

对于引用计数,我们需要知道如果具有循环引用,那么其计数问题就会暴露,导致计数永远不为0而无法释放内存,导致内存泄露,具体事例如下:

e.g.2

function(){
var a = {};
var b = {};
b.pro = a;
a.pro=b;
}

如果e.g.2使用引用计数的话就会导致问题,内存无法被释放,导致内存无故消耗占用。

IE的垃圾回收机制问题 

除了一些极老版本的IE,目前市面上的JS引擎基本采用标记清除来除了垃圾回收。但是需要注意的是IE中的DOM由于机制问题,是采用了引用计数的方式,所以会有循环引用的问题,如:

e.g.3

var ele = document.getElementById(“element”);
var obj = new Object();
ele.obj = obj;
obj.ele = ele;

这边就会倒是问题,内存无法再执行完毕后释放

解决方法其实也很简单,当所有的代码完毕末尾处只需要对变量进行 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造成的长时间停止响应。

3)、GC优化策略

David大叔主要介绍了2个优化方案,而这也是最主要的2个优化方案了:

(1)分代回收(Generation GC)
这个和Java回收策略思想是一致的。目的是通过区分“临时”与“持久”对象;多回收“临时对象”区(young generation),少回收“持久对象”区(tenured generation),减少每次需遍历的对象,从而减少每次GC的耗时。

这里需要补充的是:对于tenured generation对象,有额外的开销:把它从young generation迁移到tenured generation,另外,如果被引用了,那引用的指向也需要修改。

(2)增量GC
这个方案的思想很简单,就是“每次处理一点,下次再处理一点,如此类推”。

这种方案,虽然耗时短,但中断较多,带来了上下文切换频繁的问题。

因为每种方案都其适用场景和缺点,因此在实际应用中,会根据实际情况选择方案。

比如:低 (对象/s) 比率时,中断执行GC的频率,simple GC更低些;如果大量对象都是长期“存活”,则分代处理优势也不大。


发布手记

热门词条