Node.js[译] Overview of Blocking vs Non-Blocking

Overview of Blocking vs Non-Blocking

这篇文章主要内容为node.js中阻塞和非阻塞的区别。其中,eventlooplibuv会被引用到,不过并不需要你之前就了解过这些知识。我们假设本文的读者至少对Javascriptnode.js回调设计模式要有基本的理解和掌握。

`I/O`在本文中主要指的是由`libuv`提供支持的与磁盘和网络发生的交互。

Blocking

阻塞指的是node.js中额外的javascript操作必须等待一个非node.js的操作完成才能执行。这种现象发生的原因是当一个阻塞操作发生时,eventloop无法继续执行javascript代码。
Node.js中,如Javascript所表现出的低性能是由于CPU密集计算而不是等待一个非Javascript操作,比如I/O,这并不是通常来说的阻塞操作。Node.js标准库中使用了libuv的同步方法才是普遍意义上的阻塞操作。本地模块也会有阻塞方法。
所有Node.js标准库中的I/O都提供了异步的版本,来实现非阻塞,并且接受回调函数。一些方法还提供了同步的版本,并以Sync来作为后缀。

Comparing Code

阻塞方法以同步的方式执行,非阻塞方法以异步的方式执行。
我们以File System这个模块举个例子,这是一个同步的文件读取操作:

const fs = require('fs');
const data = fs.readFileSync('/file.md'); // 在这里发生阻塞直到文件读取完毕

下面是一个异步的文件读取操作:

const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
    if (err) throw err;
});

第一个例子和第二个例子比较起来很相似,但是却由于第二行阻塞了其它javascript代码的执行直到文件读取完为止显现出自己的缺点所在。请记住,在同步执行的版本里,如果一个error被抛出的话,需要我们去捕获它,否则程序将会crash掉。在异步执行的版本里,则是取决于我们自己是否来抛出这个异常。

让我们继续在前面的例子上延伸,下面是同步的版本:

const fs = require('fs');
const data = fs.readFileSync('/file.md'); // 在这里发生阻塞直到文件读取完毕
console.log(data);
/* moreWork(); 在console.log之后执行。*/

下面是一个异步的文件读取操作:

const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
    if (err) throw err;
    console.log(data);
});
/* moreWork(); 在console.log之前执行 */

在上面的第一个例子中,console.log将会在moreWork方法之前执行,而在第二个例子中,fs.readFile是一个非阻塞的操作,所以代码可以在读取文件操作时继续执行到moreWork方法。执行moreWork方法而不必等到文件读取完毕的这种能力是允许更高吞吐量的一个关键设计选择。

Concurrency and Throughput

Node.js中的JavasScript执行是单线程的,因此并发是指事件循环在完成其他工作后执行JavaScript回调函数的能力。任何将要以并行的方式运行的代码必须允许javascript操作的事件循环继续运行,如I/O,正在发生。
举个栗子,我们考虑以下这种情况,发送到WEB服务器的每个请求需要50ms来完成,其中45ms是可以异步执行的数据库I/O操作。对服务器来说使用非阻塞异步操作的话可以在每个请求身上节约45ms来处理其他的请求。仅仅将阻塞操作替换成了非阻塞操作就可以产生如此巨大的区别。
eventloop不像其他语言中可以有额外的线程来处理并行任务。

Dangers of Mixing Blocking and Non-Blocking Code

I/O中需要避免一些操作模式。请看以下栗子:

const fs = require("fs");
fs.readFile('/file.md', (err, data) => {
    if (err) throw err;
    console.log(data);
});
fs.unlinkSync('/file.md');

在上面的代码中,fs.unlinkSync()有可能在fs.readF ile()之前就执行了,这就会导致一个严重的问题,在读取文件前就从内存中删除了该文件。一个更好的方式是将删除操作非阻塞化,并且保证正确的执行顺序,如下所示:

const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
  if (err) throw err;
  console.log(data);
  fs.unlink('/file.md', (err) => {
    if (err) throw err;
  });
});

上面的代码通过在fs.readFilecallback中加入fs.unlink的代码来保证操作的正确顺序。

Additional Resources

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342

推荐阅读更多精彩内容