给Node.js新手的7条小建议
发布于 3 年前 作者 liuyanghejerry 13785 次浏览 最后一次编辑是 3 个月前 来自 分享

不知不觉的已经用Node.js有将近一年了,这里我有几条出自实践的node.js建议送给刚刚入门的node.js的朋友。

命名而不是匿名

在JavaScript中,我们可以创建匿名对象和匿名函数。一般来说,匿名函数可以让代码更加简短精悍。

然而,对这些对象或函数进行命名,则有利于调试和优化。以下是我从Chrome DevTool的文章中借用的图片:

Picture

很明显,命名的实体更利于调试和优化。

尽早解引用

V8的GC是清除标记的做法,下面的内容有误导,不推荐阅读了。有关V8 GC的话题,可以阅读我翻译的另一篇文章

JavaScript的GC以一种类似引用计数的算法工作,一个对象当且仅当所有指向它的引用全部释放之后,它本身才会被释放掉。

然而可能你有其他的闭包或者全局对象持有它的引用,从而阻止了垃圾回收。为避免这一现象,应当尽早地解除不必要的引用:

var some_var = new net.Server(); // other code… var i_want_it_temperoray = some_var; some_operation(i_want_it_temperoray); i_want_it_temperoray = null; // derefernce // other code…

如果闭包中尚有一个变量未能被释放,那么整个闭包都有可能无法被回收,从而造成其它对象也无法释放。

现在有很多工具可以辅助我们监视内存的变化情况,比如heapdump、webkit-devtools-agent等等。同时,这也更加说明了为什么要尽可能使用命名而不是匿名的对象。

别复制代码

我用Node.js开发的项目代码变化非常快,重构也很频繁,常常会到处复制代码。然而每当我这样做的时候,后来都会发现某些变量要么就是忘了改名,要么就是有些变量压根就不存在了,导致代码变得极为不稳定。

JS是一门高度动态的语言,它不像C++这样可以利用编译器做静态检查,因此你几乎没有机会依靠工具检查出这些问题。所以我的建议是,尽可能地自己再输入一遍代码,这样IDE或者编辑器有机会利用代码自动补全来为你检查。如果你的IDE还没这功能,那你真得考虑换掉它了。

慎重引入新模块

Node.js社区非常活跃,有成千上万的现成模块可以取用,然而其中有些其实已经没人管了。Node.js的API也常常发生变化,适配node v0.8.x的模块,有可能不支持v0.10.x。

因此当你考虑引入新的模块的时候,务必先去它的pull request列表或者issue列表看看,确认一下这个模块是不是已经被抛弃,或者存在重大的隐患。

用async.js或者promise

Node.js基于回调。因为回调的本质,我们很容易写出嵌套多层的回调函数。回调对于异步来说是好事,但对于代码维护来说却是坏事。

如果你发现代码需要3层以上的回调函数嵌套,那你应该考虑一下,要不要使用async.js或者基于promise概念的模块。

以下是一个用async.js写出来的一系列异步操作:

async.auto([ ‘init_logger’: function(done){ set_handlers_to_logger(done); }, ‘load_config’: [‘init_logger’, function(done){ load_my_config(done); }], ‘init_database’: [‘load_config’, function(done){ connect_to_db_here(done); }], // 假定open_cache与数据库无关 ’open_cache’: [‘load_config’, function(done){ open_cache_here(done); }], // warm_up通常用于从数据库预先抓取一些数据 // 注意,warm_up只会在’init_database’以及’open_cache’结束后执行 ’warm_up’: [‘init_database’, ‘open_cache’, function(done){ fetch_some_data(done); }], ‘init_routers’: [‘load_config’, function(done){ install_routers(done); }], ‘emit_out’: [‘warm_up’, ‘init_routers’, function(done){ notify_others(done); }] ], function(err) { if(err){ // 在这处理异常 } });

我对promise相关的模块不是很熟,但使用Q,应该可以写出这样的代码,,同样易于阅读:

Q.nfcall(function init_logger(){ set_handlers_to_logger(); }) .then(function load_config(){ load_my_config(); }) .then(function init_database(){ connect_to_db_here(); }) .then(function open_cache(){ open_cache_here(); }) .then(function warm_up(){ fetch_some_data(); }) .then(function init_routers(){ install_routers(); }) .then(function emit_out(){ notify_others(); }) .catch(function (error) { // 在这处理异常 }) .done();

选取什么样的库来简化逻辑一般都是随便你。通常来说,async.js非常简单,而Q则更加灵活强大。

比如说async.js中各个函数独立而不嵌套,因此如果你想通过捕获某个函数中的变量就显得有些困难,而在Q中就可以使用嵌套的then语句。

本来我还想写一写不使用任何辅助模块的上述代码,但其实我都很怀疑自己能不能写对。

客户端也许特别慢

用Node.js的时候我们可能会变得有点过于理想化了,因此很容易写出下面这样的聊天室代码:

var net = require(‘net’); var clientList = []; var server = net.createServer(function© { //‘connection’ listener console.log(‘server connected’); clientList.push©; c.on(‘end’, function() { console.log(‘server disconnected’); unpipe_all(c, clientList); remove_from(c, clientList); }); clientList.forEach(function(item){ item.pipe©; // 注意这 c.pipe(item); // 还有这 }); }); server.listen(8124, function() { //‘listening’ listener console.log(‘server bound’); });

我觉得整个结构没什么大问题,但当我们遇上网络状况不好的客户端时,情况就不大好了。这里的两个pipe会把数据缓存在内存中,因此当客户端不能及时接收数据时,这些数据就会大量滞留在内存当中。我们往往假设客户端的速度还不错,但其实那都只是假设!

我想到的一个方法是,用一个中间件来做缓存,当数据太多时使用文件缓冲,而数据不多则用内存,如下:

Delegate delegate; clientList.forEach(function(item){ delegate.append(item); // delegate内部会有一个与文件关联的缓存 // 如果数据太大则把数据存入文件 });

如果你有其它的方案来处理这种情况,不妨也分享一下:)

用事件通知完成,而且不要太早

大多数小对象都是同步构造的,但对于某些封装了复杂操作的对象来说,初始化都有可能是异步的。

如果一个对象需要异步构造,那么最好使用事件通知完成。这时你要留意官方文档 中的一小段话:

This is important in developing APIs where you want to give the user the chance to assign event handlers after an object has been constructed, but before any I/O has occurred.

function MyThing(options) { this.setupOptions(options);

process.nextTick(function() { this.startDoingStuff(); }.bind(this)); }

var thing = new MyThing(); thing.getReadyForStuff();

// thing.startDoingStuff() gets called now, not before.

典型的解决方案是,在构造结束时用process.nextTick来发消息:

function SomeTCPServer(options) { var self = this; // 其他可能异步的初始化工作 process.nextTick(function(){ self.emit(‘ready’); }); }

// 其他代码 var server = new SomeTCPServer(ops); server.on(‘ready’, function when_ready(){ // 其它事情 });

因为用的是process.nextTickwhen_ready不会错过ready事件。

其它建议?

我暂时就想起来这么多,因为我自己也不是Node.js的真正专家。不过我还是希望上面的几条能对新手有所帮助,欢迎大家指出上面的任何错漏,谢啦。

21 回复

这个要 mark 的~其实感觉自己总是被异步绕得很晕,抓狂过很多次,不过写多了自然就熟悉啦~

确实不错,支持

我就记得,有一次读一个很大的文件,直接把我内存读爆了。今天看到楼主解引用这段,我觉得有必要看看我的代码是不是没有解引用。

读大文件尽量用流的方式处理,虽然现在node的流还不是特别完善:)

好顶赞 写的稍微有点简单。 不过确实给我指了些学习方向

nice, mark一下

必须mark~

赞!非常有帮助。刚初学一个月,摸索中 ……

gc不是改标记清除了么? 自豪地采用 CNodeJS ionic

@zlbbq 这个跟标记清除什么的没有关系。无论清除的方式是怎么样,回收永远只能针对没有在使用的变量,而回收引擎是不知道你程序中变量到底是有没有在用,它只能判断这个变量有没有被引用。leak 就是由于没有用的变量被某个活动的 context 引用而造成的,一般也就是设计上不正确。 在使用模块级变量应十分小心,模块级变量在程序运行中会一直存在,被它引用的变量是不会被释放的。闭包中局部变量是安全的,使用完它就没有引用了,除非是返回函数,再把函数放到模板变量中,这样就会导致闭包中的变量也无法释放。这种引用就是 leak ,随着时间增长,内存占用一直升高,永远不会有降低的可能。而且随着内存增高,GC不停地尝试回收,程序也会变慢! 像读文件撑爆内存这种不算是 leak 。 理论上只要内存够大,操作完变量释放了内容会降下来不算是 leak。 另外在使用队列时也应小心,特别是一边进,一边出的那种要注意进和出的速度,如果出太慢的话,也会撑爆。技术上讲也不算 leak 。跟读文件撑爆很像,理论上当出的操作跟上脚步,内存占用也会降回去,所以队列时最好不要一边进一边出了,控制并发数,一个项就是一进一出,这样就安全。

楼主,除非像是函数,或者变量内部有对闭包变量的引用才会导致闭包变量不会被释放。 普通的变量是不会的,

 var globals = [];
 function foo() {
   var a = 1;
   return function () {
     var b = a + 1;
 	return b;
   }
 }
 globals.push(foo()); //  may cause variable a unable to be GCed.
 globals.push(foo()()); //  may not!

@klesh 标记清除是目前js引擎普遍的gc算法,引用记数已过时,引用记数主要问题在于循环引用会引起内存泄漏。 自豪地采用 CNodeJS ionic

尽早解引用的那部份代码,如果是在一个 function 体内,不设置 = null ,也是安全的。 而示例代码中没有新的 function ,也就是它没有产生“闭包”。 如果 some_operation 里面有闭包,也不会导致当前 i_want_it_temperoray 被引用。 且 some_operation 里面的闭包引用的是属于它的 i_want_it_temperoray 变量,设置当前 i_want_it_temperoray = null 是无法解除 some_operation 内部产生的闭包的引用的。 结论是设置 null 是解决不了任何问题的。也不会有明显的效果。

@zlbbq 嗯,你说的对。但我说的是使用上的问题,而不是引擎上的问题。事实证明 v8 的 GC 非常出色。。。楼主讲的应该是使用的时候会引起的内存回收问题。引擎再先进它也没办法判断使用是否合理。所以在使用上还是要注意,不要产生不必要的引用而导致leak 。无论再怎么先进的回收方法,只要全局变量上有一个无限增长的 Array,那 leak 是必须的。GC再怎么标记,它也不能把我的 ARRAY 给标没了。它不可能知道我这个 ARRAY 是有用还没用的。

@zlbbq 抱歉,看走眼了,楼主确实是说了引用计数。SORRY。。。。

代码改一下吧,不太方便看

好久以前的文章了,怎么被挖坟了OTZ

关于内存泄露,有个有意思的补充给大家:http://info.meteor.com/blog/an-interesting-kind-of-javascript-memory-leak

另外引用计数的确过时啦,现在确实是标记清除了,至少V8现在是

回到顶部