所以在这个例子中，在onDataLoad函数定义时，就为默认为其绑定了一个[[scope]]属性指向其父函数的 ExecutionContext的ScopeChain。而当函数onDataLoad执行时，就可以通过[[scope]]属性来访问父函数的VO对 象来找到id，如果父函数的VO中没有id这个属性，就再继续向上查找其祖先的VO对象，直到找到id这个属性或到达最外层返回undefined。也正 是因为这个引用，造成VO的引用计数不为0，在走出作用域时，才不会被垃圾回收。
很多朋友觉得闭包较难理解，其实我们只要能明确的区分函数定义和函数运行两个时机，那么闭包就是让函数在运行时能够访问到函数定义时的所处作用域内的所有变量，或者说函数定义时能访问到什么变量，那么在函数运行时通过相同的变量名一样能访问到。
关于状态保持是本文的重点，在我看到的多数Node.js的介绍文章中并没有详解这里，我们只是知道了要解决阻塞问题，但是JavaScript解决阻塞问题的优势到底在哪里，作为一名前端工程师，我想有必要花一些篇幅详细解释一下。
而之所以我叫它”状态保持”因为还有一个非常相似的场景可以类比：
用户从A页面提交表单到B页面，如果提交数据校验不通过，则需要返回A页面，同时保持用户在A页面填写的内容并提示用户修改不对的地方。从提交到校验出错再返回继续填写是一个包含网络交互的异步过程，这相当于填写表单这个任务过会儿再继续。
在传统网页开发中，用户的状态通过请求传递到服务端，交由后端状态保持(类似交给db.query的currentSate)。而使用Ajax的网 页，因为并未离开原页面，那么服务端只要负责校验用户提交的数据是否正确即可，发送错误，返回错误处相关信息即可，这就是所谓前端状态保持。可以看到这个 场景里边服务端做的事情变少了，变纯粹了。正如我们的例子中db.query不再存储转发第三个state参数，变得更在轻量。
我们看到通过JavaScript函数式语言特性，匿名函数支持和闭包很漂亮的解决了同步编程到异步编程转化过程中遇到的一系列最重要的问题。但JavaScript是否就是最好的？这就要回答我们引用新技术时需要考虑的最后一个问题了。
使用Node.js是否带来额外的困扰，如何解决？
Node.js性能真的是最好么？不用比较我们也可以得到结论，Node.js做无阻塞编程性能较难做到极致。何为极致？处理一个请求需要占用多少 内存，多少cpu资源，多少带宽，有丁点浪费就不是极致。阻塞式编程浪费了大量进程资源只是在等待，导致大量内存和cpu的浪费。在这方面Node.js 好很多，但也正是因为一些闭包等JavaScript内建机制也会导致资源的浪费，看下面的代码：
1
2
3
4
5
6
7
8
function main(){
var id = "1";
var str = "..."; //这里局部变量str存储一个2M的字符串
db.query("select name from persons where id=" + id,function(name){
output("person id:" + id + ", name:" + name);//n秒后数据返回后执行回调
});
}
main();
至少整个数据查询过程中，变量str所使用的2M内存并不会被释放，而str保持下去可能并没有意义。前面已经解释过闭包的原理，闭包并没有智能到只包起来今后可能被访问到的对象。即使不了解闭包的原理，也可以通过一段简单脚本验证这点：
1
2
3
4
5
6
7
8
function main(){
var id = "1";
var str = "..."; //这里存储一个2M的字符串
window.setTimeout(function(){
debugger; //我们在这里设置断点
},10000)
}
main();
我们在回调函数当中只设置一个断点，并不指明我们要访问哪个变量。然后我们在控制台监视一下，id和str都是可以拿到的。
所以我来猜想一下，性能极端苛刻的场景，无阻塞是未来，但无阻塞发展下去，或者有更轻量的脚本引擎产生，或者JavaScript引擎可能要调整可以dISAble闭包，或者我们要通过给JS开发静态编译器在代码发布前自动优化我们的代码。
静态编译是如今JavaScript技术领域的又一个热点，我们都知道JavaScript是解释型脚本语言，在运行时自动编译。但是运行时编译只是将代码转为机器码执行，却并未覆盖传统编译型语言在编译阶段所做的任务。比如，语法检查，接口校验，全局性能优化等等。
最常见的JavaScript静态编译就是脚本压缩工具，在代码发布到线上之前，我们通过各种压缩工具，将代码压缩，达到减少网络传输量的问题。而 在这个时间点，已经有越来越多的事情可做，比如：Google利用ClouserComplier提供的系列编译指令，让JavaScript更好的实现 OO编程。也有GWT，CoffeeScript这样的项目，将其他语言编译为JavaScript。在淘宝我们在代码静态编译阶段来解决因 JavaScript细粒度模块化改造引入各种性能问题，也用来对第三方提供JavaScript代码进行一定的安全检查。
我们期待前面的代码经过静态编译器编译后变成如下结果：
1
2
3
4
5
6
7
8
9
function main(){
var id = "1";
var str = "..."; //这里局部变量str存储一个2M的字符串
db.query("select name from persons where id=" + id,function(name){
output("person id:" + id + ", name:" + name);
});
str = ""; //通过这一行，及时释放不必要的内存占用。
}
main();
除了性能方面的担忧，使用Node.js进行编程增加了代码编写的复杂度。因为我们习惯于阻塞式编程的写法，切换到异步模式编程，往往对于太多多层次的callback函数嵌套弄得不知所措。老赵最近开发了项目JSCEX正是要解决这个问题，它让大家在遵守一些小的约定后，能够仍然保持同步编程的写法进行代码开发。写完的代码同样通过静态编译器编译成异步回调式模式的代码再交给JavaScript引擎执行。
Node.js还要解决什么问题
说了这么多，无阻塞编程要做的还远不止这些。首先需要一个高效的JS引擎，高效的事件池和线程池。另外几乎所有和Node.js交互的传统模块如文件系统，数据访问，HTTP解析，DNS解析都是阻塞式的，都需要额外改造。
Node.js作者极其团队，正是认清问题所在以及JS解决这些问题方面的优势。基于Google开源的高效JavaScript引擎V8，贡献了大量的智慧和精力解决上述大部分问题后才有Node.js横空出世。
当前Node社区如此火热，千余开源的Node.js模块，活跃在WebFramework，WebSocket，RPC，模板引擎，数据抓取服务，图形图像几乎所有工程领域。
后记
本文主要的信息来自Node.js作者在JSConf09，JSConf10上的分享。 而作为前端开发，着重讲了函数式编程，闭包对于无阻塞开发的重要意义。我期待这篇文章能够给前端和后端工程师都带来收获。
同样作为前端开发，不得不再插几句，说说服务端JS能够解决的另一个问题：当前的Web开发前后端使用不同的语言，很多相同的业务逻辑要前后端分别 用不同语言重复实现。比如越来越多重度依赖JavaScript的胖客户端应用，当客户浏览器禁用JavaScript时，则需要使用服务端语言将主业务 流程再实现一次，这即是前端常说的”渐进增强”。
当我们拥有了服务端JavaScript语言，我们自然就会想到能否利用Node.js做到”一次开发，渐进增强”。解决掉这个为小量用户，浪费大量时间的恼人的问题。这方面的实践，YAHOO仍然是先驱，早在一年多前开始YAHOO通过nodejs-yui3项目做了很多卓越的贡献，而淘宝自主开发的前端框架Kissy也有服务端运行的相关尝试。
JavaScript在诞生之时就不仅仅是浏览器端工具，如今JavaScript能够再一次回到服务端展示拳脚，感谢V8，感谢NodeJS作者，团队和社区的诸多贡献者，祝Node好运，JavaScript好运。
本文关键字：工程师 电脑-单片机-自动控制，电子学习 - 基础知识 - 电脑-单片机-自动控制
上一篇：Linux下的多线程编程
