Node.js(译) Overview of Blocking vs Non-Blocking

Overview of Blocking vs Non-Blocking

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

`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来做为后缀。java

Comparing Code

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

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

相关文章
相关标签/搜索