Ruby's Louvre

每天学习一点点算法

导航

js闭包测试

本文的诞生,源自近期打算做的一个关于javascript中的闭包的专题,由于需要解析闭包对垃圾回收的影响,特此针对不同的javascript引擎,做了相关的测试。

为了能从本文中得到需要的知识,看本文前,请明确自己知道闭包的概念,并对垃圾回收的常用算法有一定的了解。

问题的提出
假设有如下的代码:

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function() {
        console.log('inner');
    };
}
var inner = outer();

在这一段代码中,outer函数和inner函数间会形成一个闭包,致使inner函数能够访问到largeObject,但是显然inner并没有访问largeObject,那么在闭包中的largeObject对象是否能被回收呢?

如果引入更复杂的情况:

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
    var anotherLargeObject = LargeObject.fromSize('100MB');
 
    return function() {
        largeObject.work();
        console.log('inner');
    };
}
var inner = outer();

首先一个显然的概念是largeObject肯定不能被回收,因为inner确实地需要使用它。但是anotherLargeObject又能不能被回收呢?它将跟随largeObject一起始终存在,还是和largeObject分离,独立地被回收呢?

测试方法
带着这个疑问,对现有的几款现代javascript引擎分别进行了测试,参与测试的有:
~IE8自带的JScript.dll
~IE9自带的Chakra
~Opera 11.60自带的Carakan
~Chrome 16.0.912.63自带的V8(3.6.6.11)
~Firefox 9.0.1自带的SpiderMonkey

测试的基本方案是,使用类似以下的代码:

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function() {
        debugger;
    };
}
var inner = outer();

通过各浏览器的开发者工具(Developer Tools、Firebug、Dragonfly等),在断点处停止javascript的执行,并通过控制台或本地变量查看功能检查largeObject的值,如果其值存在,则认为GC并没有回收该对象。

对于部分浏览器(特别是IE),考虑到对脚本执行有2种模式(执行模式和调试模式,IE通过开发者工具的Script面板中的“Start Debugging”按钮切换),在调试模式下才会命中断点,但是调试模式下可能存在不同的引擎优化方案,因此采用内存比对的方式进行测试。即打开资源浏览器,在var inner = outer();一行后强制执行一次垃圾回收(IE使用window.CollectGarbage();Opera使用window.opera.collect();),查看内存的变化。如果内存始终有100MB的占用,没有明显的下降现象,则认为GC并没有回收该对象。

对于用例的设计,由于从ECMAScript标准中可以得知,所有的变量访问是通过一个LexicalEnvironment对象进行的,因此目标在于在不同的LexicalEnvironment结构下进行测试。从标准中,搜索LexicalEnvironment不难得出能够改变LexicalEnvironment结构的情况有以下几种:

1.进入一个函数。
2.进入一段eval代码。
3.使用with语句。
4.使用catch语句。
因此以下将针对这4种情况,进行多用例的测试。

测试过程级结果
基本测试
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function() {
        debugger;
    };
}
var inner = outer();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收,内存会恢复到outer函数执行前的状态。
~Carakan – 不回收,内存无下降趋势。
~V8 – 回收,访问largeObject抛出ReferenceError。
~SpiderMonkey – 回收,访问largeObject得到undefined。

结论
当一个函数outer返回另一个函数inner时,Chakra、V8和SpiderMonkey会对outer中声明,但inner中不使用的变量进行回收,其中V8直接将变量从LexicalEnvironment上解除绑定,而SpiderMonkey仅仅将变量的值设为undefined,并不解除绑定。

多个变量的情况
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
    var anotherLargeObject = LargeObject.fromSize('100MB');
 
    return function() {
        largeObject;
        debugger;
    };
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收anotherLargeObject,内存会回到outer调用前并增加100MB左右。
~Carakan – 不回收,内存无下降趋势。
~V8 – 回收,访问largeObject能得到正确的值,访问anotherLargeObject抛出ReferenceError。
~SpiderMonkey – 回收,访问largeObject能得到正确的值,访问anotherLargeObject得到undefined。

结论
当一个LexicalEnvironment上存在多个变量绑定时,Chakra、V8和SpiderMonkey会针对不同的变量判断是否有被使用,该判断方法是扫描返回的函数inner的源码来实现的,随后会将没有被inner使用的变量从LexicalEnvironment中解除绑定(同样的,SpiderMonkey不解除绑定,仅赋值为undefined),而剩下的变量继续保留。

eval的影响
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function() {
        eval('');
        debugger;
    };
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 不回收,内存无下降趋势。
~Carakan – 不回收,内存无下降趋势。
~V8 – 不回收,访问largeObject可得到正确的值。
~SpiderMonkey – 不回收,访问largeObject可得到正确的值。

结论
如果返回的inner函数中有使用eval函数,则不LexicalEnvironment中的任何变量进行解除绑定的操作,保留所有变量的绑定,以避免产生不可预期的结果。

间接调用eval
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function() {
        window.eval('');
        debugger;
    };
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收,内存会恢复到outer函数执行前的状态。
~Carakan – 不回收,内存无下降趋势。
~V8 – 回收,访问largeObject抛出ReferenceError。
~SpiderMonkey – 回收,访问largeObject得到undefined。

结论
由于ECMAScript规定间接调用eval时,代码将在全局作用域下执行,是无法访问到largeObject变量的。因此对于间接调用eval的情况,各javascript引擎将按标准的方式进行处理,无视该间接调用eval的存在。
同样的,对于new Function(‘return largeObject;’)这种情形,由于标准规定new Function创建的函数的[[Scope]]是全局的LexicalEnvironment,因此也无法访问到largeObject,所有引擎都参照间接调用eval的方式,选择无视Function构造函数的调用。

多个嵌套函数
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    function help() {
        largeObject;
        // eval('');
    }
 
    return function() {
        debugger;
    };
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 不回收,内存无下降趋势。
~Carakan – 不回收,内存无下降趋势。
~V8 – 不回收,访问largeObject可得到正确的值。
~SpiderMonkey – 不回收,访问largeObject可得到正确的值。

结论
不仅仅是被返回的inner函数,如果在outer函数中定义的嵌套的help函数中使用了largeObject变量(或直接调用eval),也同样会造成largeObject变量无法回收。因此javascript引擎扫描的不仅仅是inner函数的源码,同样扫描了其他所有嵌套函数的源码,以判断是否可以解除某个特定变量的绑定。

使用with表达式
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
    var scope = { o: LargeObject.fromSize('100MB') };
 
    with (scope) {
        return function() {
            debugger;
        };
    }
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收largeObject,但不回收scope.o,内存恢复至outer函数被调用前并增加100MB左右(无法得知scope是否被回收)。
~Carakan – 不回收,内存无下降趋势。
~V8 – 不回收,访问largeObject和scope以及o均可得到正确的值。
~SpiderMonkey – 回收largeObject和scope,访问该2个变量均得到undefined,不回收o,可得到正确的值。

结论
当有with表达式时,V8将会放弃所有变量的回收,保留LexicalEnvironment中所有变量的绑定。而SpiderMonkey则会保留由with表达式生成的新的LexicalEnvironment中的所有变量的绑定,而对于outer函数生成的LexicalEnvironment,按标准的方式进行处理,尽可能解除其中的变量绑定。

使用catch表达式
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    try {
        throw { o: LargeObject.fromSize('100MB'); }
    }
    catch (ex) {
        return function() {
            debugger;
        };
    }
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收largeObject和ex,内存会恢复到outer函数被调用前的状态。
~Carakan – 不回收,内存无下降趋势。
~V8 – 仅回收largeObject,访问largeObject抛出ReferenceError,但仍可访问到ex。
~SpiderMonkey – 仅回收largeObject,访问largeObject得到undefined,但仍可访问到ex。

结论
catch表达式虽然会增加一个LexicalEnvironment,但对闭包内变量的绑定解除算法几乎没有影响,这源于catch生成的LexicalEnvironment仅仅是追加了被catch的Error对象一个绑定,是可控的(相对的with则不可控),因此对变量回收的影响也可以控制和优化。但对于新生成并添加了Error对象的LexicalEnvironment,V8和SpiderMonkey均不会进一步优化回收,而Chakra则会对该LexicalEnvironment进行处理,如果其中的Error对象可以回收,则会解除其绑定。

嵌套函数中声明的同名变量
使用代码

function outer() {
    var largeObject = LargeObject.fromSize('100MB');
 
    return function(largeObject /* 或在函数体内声明 */) {
        // var largeObject;
    };
}
var inner = outer();
inner();

测试结果
~JScript.dll – 不回收,内存无下降趋势。
~Chakra – 回收,内存会恢复到outer函数被调用前的状态。
~Carakan – 不回收,内存无下降趋势。
~V8 – 回收,内存会恢复到outer函数被调用前的状态。
~SpiderMonkey – 回收,内存会恢复到outer函数被调用前的状态。

结论
嵌套函数中有与外层函数同名的变量或参数时,不会影响到外层函数中该变量的回收优化。即javascript引擎会排除FormalParameterList和所有VariableDeclaration表达式中的Identifier,再扫描所有Identifier来分析变量的可回收性。

总体结论
首先一个较为明确的结论是,以下内容会影响到闭包内变量的回收:
~嵌套的函数中是否有使用该变量。
~嵌套的函数中是否有直接调用eval。
~是否使用了with表达式。

Chakra、V8和SpiderMonkey将受以上因素的影响,表现出不尽相同又较为相似的回收策略,而JScript.dll和Carakan则完全没有这方面的优化,会完整保留整个LexicalEnvironment中的所有变量绑定,造成一定的内存消耗。

由于对闭包内变量有回收优化策略的Chakra、V8和SpiderMonkey引擎的行为较为相似,因此可以总结如下,当返回一个函数fn时:
1.如果fn的[[Scope]]是ObjectEnvironment(with表达式生成ObjectEnvironment,函数和catch表达式生成DeclarativeEnvironment),则:
A.如果是V8引擎,则退出全过程。
B.如果是SpiderMonkey,则处理该ObjectEnvironment的外层LexicalEnvironment。

2.获取当前LexicalEnvironment下的所有类型为Function的对象,对于每一个Function对象,分析其FunctionBody:
A.如果FunctionBody中含有直接调用eval,则退出全过程。
B.否则得到所有的Identifier。
C.对于每一个Identifier,设其为name,根据查找变量引用的规则,从LexicalEnvironment中找出名称为name的绑定binding。
D.对binding添加notSwap属性,其值为true。

3.检查当前LexicalEnvironment中的每一个变量绑定,如果该绑定有notSwap属性且值为true,则:
A.如果是V8引擎,删除该绑定。
B.如果是SpiderMonkey,将该绑定的值设为undefined,将删除notSwap属性。
对于Chakra引擎,暂无法得知是按V8的模式还是按SpiderMonkey的模式进行。

从以上测试及结论来看,V8确实是一个优秀的javascript引擎,在这一方面的优化相当到位。而SpiderMonkey则采取一种更为友好的方式,不直接删除变量的绑定,而是将值赋为undefined,也许是SpiderMonkey团队考虑到有一些极端特殊的情况,依旧有可能导致使用到该变量,因此保证至少不会抛出ReferenceError打断代码的执行。而IE9的Chakra相比IE8的JScript.dll进步非常大,细节上的处理也很优秀。Opera的Carakan在这一方面则相对落后,完全没有对闭包内的变量回收进行优化,选择了最为稳妥但略显浪费的方式。

此外,所有带有优化策略的浏览器,都在内在开销和速度之间选择了一个平衡点,这也正是为什么“多个嵌套函数”这一测试用例中,虽然inner没有再使用largeObject对象,甚至在inner中的断点处,连help函数对象也已经解除绑定,却没有解除largeObject的绑定。基于这种现象,可以推测各引擎均只选择检查一层的关联性,即不去处理inner -> help -> largeObject这样深度的引用关系,只找inner -> largeObject和help -> largeObject并做一个合集来处理,以提高效率。也许这种方式依旧存在内存开销的浪费,但同时CPU资源也是非常贵重的,如何掌握这之间的平衡,便是javascript引擎的选择。

此外,根据部分开发者的测试,Chakra甚至有资格被称为现有最快速的javascript引擎,微软也一直在努力,而开发者更不应该一味地谩骂和嘲笑IE。
我们可以嘲笑IE6的落后,可以看不到低版本的IE曾经为互联网的发展做过的贡献,可以在这些历史产品已经没落的今天无情地给予打击,却最最不应该将整个IE系列一视同仁,挂上“垃圾”的名号。客观地去看待,去评价,正是一个技术人员应该具备的最基本的准则和素养。

posted on 2013-10-01 08:15  司徒正美  阅读(18974)  评论(4编辑  收藏  举报