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