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

Overview of Blocking vs Non-Blocking

这篇文章主要内容为

node.js

中阻塞和非阻塞的区别。其中，

eventloop

和

libuv

会被引用到，不过并不需要你之前就了解过这些知识。我们假设本文的读者至少对

Javascript

和

node.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.readFile

的

callback

中加入

fs.unlink

的代码来保证操作的正确顺序。

Additional Resources

libuv

About Node.js