《大前端进阶 Node.js》系列 异步非阻塞（同步/异步/阻塞/非阻塞/read/select/epoll）

前言

Coding 应当是一辈子的事业，而不只仅是 30 岁的青春饭
本文已收录 GitHub https://github.com/ponkans/F2E，欢迎 Star，持续更新

面试官问：阻塞是用来形容什么的？

若是你还要再三思考这个问题（面试官此时内心绝壁在想，这 tm 还要思考，还跟我谈什么 Node 异步非阻塞！），请好好看下面的文章。

---

每篇文章都但愿你能收获到东西，这篇是讲 Node 异步非阻塞的原理，看完但愿你有这些收获：

• 阻塞、非阻塞本质与区别
• 同步、异步本质与区别
• Node 异步非阻塞本质

PS：底层基础决定上层建筑，请小伙伴们重视基础哦~

---

异步非阻塞

在提到 Node 的时候，异步非阻塞是一个常常被说起的话题，与之伴随的还有事件、回调、消息等等一系列词语。

看这些概念就像追一个渣女，你好像以为本身很懂她，但有时候你又会以为一无所知。

本文将带你们层层剖析，自底向上的深刻理解这些概念，让你看清这个渣女的真面目。

阻塞非阻塞

不少人会把非阻塞和异步混淆，这两个概念自己也确实有类似之处，但本质上确定是不同的，否则就不会被分红两个名词了。

咱们先要思考的是阻塞是用来形容什么的？答案天然是进程。进程的五大状态：建立、就绪、运行、阻塞、终止。因此咱们讲的阻塞非阻塞，必定是指进程。

明确了这一点以后，咱们再来看这个概念，当一个进程在发起一个调用的时候，若是这个进程从运行态变成阻塞态，那就说明这是一次阻塞调用，反之就是非阻塞。

同步与异步

咱们先搞清楚同步异步形容的是啥？咱们常说的是某某方法是个异步方法，或者是某某调用是一种异步调用。可见同步异步形容的是某个调用的特性。

何为同步？就是在发出一个功能调用时，在没有获得结果以前，该调用就不会返回。按照这个定义，其实绝大多数函数都是同步调用。

异步的概念和同步相对。当一个异步功能调用发出后，调用者不能马上获得结果。当该异步功能完成后，经过状态、通知或回调来通知调用者。

这里有两个重要的点：

• 第一是能够在获得结果前就直接返回，无需调用阻塞线程等待。
• 第二就是可以在结束前主动的去通知主线程，并执行回调。

对于上述解释，可能有的小伙伴仍是会有点迷茫，难以理清楚两者关系。别着急，往下看。

响水壶

关于上面的概念，网上有一个很经典的响水壶解释，怪怪在这里引伸给你们，并谈谈本身的理解。

---

隔壁王大爷（不是隔壁老王，hhhhh~~）有个水壶，王大爷常常用它来烧开水。

王大爷把水壶放到火上烧，而后啥也不干在那等，直到水开了王大爷再去搞别的事情。（同步阻塞）

王大爷以为本身有点憨，不打算等了。把水壶放上去以后大爷就是去看电视，是否是来瞅一眼有没有开（同步非阻塞）

王大爷去买了个响水壶，他把响水壶放在火上，而后也是等着水开，水开的时候水壶会发出声响（异步阻塞）

王大爷又以为本身有点憨，他把响水壶放在火上而后去看电视，这时他不用是否是来瞅一眼，由于水开的时候水壶会发出声音通知大爷。（异步非阻塞）

上面四个栗子里，阻塞非阻塞说明的是大爷的状态，同步非同步说明的是水壶的调用姿式。水壶能在烧好的时候主动响起，就等同于咱们异步的定义，能在结束时通知主线程而且回调。因此异步通常配合非阻塞，才能发挥其做用。

阻塞 IO 与 非阻塞 IO

有了上面王大爷的启发，你们对一些基本的概念或许有了认知，那咱们来进一步讨论下非阻塞 IO 与异步 IO。

阻塞 IO

阻塞 IO 如同其名字，主线程会在调用 IO 方法时进入阻塞态，直到 IO 结果返回，再继续运行，至关于须要整个操做所有结束了，调用才会返回。

首先要知道读一个磁盘的开销，读磁盘涉及到磁盘寻道，在对应扇区读取数据，而后把数据放在内存等一系列操做。因此阻塞 IO 必然是会被取代的，具体能够看下面这张图。

阻塞IO

非阻塞 IO

非阻塞 IO 的特色与阻塞相对，在操做系统发起 IO 调用以后，能够先不带数据直接返回，这样主线程不会被阻塞，而后操做系统来处理读磁盘这一系列操做，而不须要主进程被阻塞，这就是咱们所说的非阻塞 IO 了。

---

这里能够顺便提一下，如今大多数 IO 设备都支持DMA(Direct Memory Access，直接存储器访问)，DMA 的意义在于能够解放 IO 时处理器的压力，CPU 只须要 DMA 控制器初始化，并向 I/O 接口发出操做命令，I/O 接口提出 DMA 请求，而后在存储器和外部设备之间直接进行数据传送，在传送过程当中不须要中央处理器的参与，这段时间 CPU 能够去执行别的任务。

---

回到咱们的非阻塞 IO，他的好处显而易见，进程不用等待函数返回，能够作作别的事情。

但也有一个明显的缺陷，咱们想要读取的时候在函数返回时并无就位。我的的理解是，若是你接下来的操做立刻就强依赖 IO 的数据，那阻塞与否并没有区别。

若是你接下来的操做并不是强依赖，那能够先把非强依赖的程序执行了，再去看 IO 有没有好，这样 cpu 等待 IO 这段时间就能够被利用起来。非阻塞 IO 大体过程以下图。

PS：这里的阻塞和非阻塞和以前的观点一致，看的是发起调用的进程有没有阻塞。

非阻塞IO

轮询技术演进

上面讲到了一个关键的点，非阻塞 IO 的时候，咱们想要读取的时候在函数返回时并无就位。

就像那个烧水的大爷，在他没有响水壶的时候，他虽然一边烧水一边看电视，但他是否是也要去看一下水到底有没有开。

我这里也同样，咱们没法预知数据何时好，因此咱们也要去主动的探查 IO 数据是否就位，由于是咱们主动的探查，那能够肯定的就是，轮询技术并不是异步，他并非一个响水壶。

---

这里须要帮你们梳理清楚一个细节，可能你们常常能听到不少 IO 相关的名词，好比 recv，select, epoll, kqueue 等等，但对他们可能没有很直观的认知。咱们要读取一个文件，是分为两步的。

首先是去读取文件，而后是获取读取的结果。

读取文件须要调用的是 recv，recv 能够根据参数来决定是否阻塞，咱们所讨论的非阻塞 IO，只是在读取这一步，而 select、epoll 都是第二步（获取结果）作的事情，他们是阻塞的方法。你们切莫把两个步奏混为一谈。

结下来咱们来捋一下咱们的轮询技术。

初代：read

read 是最原始的轮询方式，read 自己就是读取文件的方法，在 C++的调用里面，若是设置了 NONBLCOK 属性，那就会当即返回，但返回的值是-1。

简单写了个 C 的 read 供你们参考，加深下理解。先是阻塞 read。

阻塞IO

那么以后咱们须要这个 IO 结果的时候咋办呢？只能不断的调用 read 方法，直到他的返回不是-1 为止，而后从传入的一个 char[] 中拿文件数据，代码大体以下图。

非阻塞IO

流程大体以下图，虽然在发起 IO 的时候非阻塞了，但其弊端显而易见，他须要在获取的时候不断的去轮询，这里会很耗费 cpu，若是这是一个多核机器可能还好，若是是单核，那一个 cpu 被这些没有意义的轮询耗在这里，就很憨（怕不是个铁憨憨吧）。

非阻塞IO

进阶：select

以前咱们讲了 read，read 的弊端是很明显的，须要不断轮询，除此以外咱们只能监听一个文件，好比我须要读两个文件，那意味着我会调用两次 read 方法，这个时候我想获取结果的话就须要先轮询一个，等那个返回了，再轮询另外一个。

你可能会说，我在一个 while(True)里面写两个不断调用 read 的代码不就好了。

那咱们若是要读 10 个文件？100 个文件？你要写 100 个吗？答案确定是 NO。针对不断的空轮询问题，和多文件监听问题，操做系统给出了更优的解决方案，select 调用。

咱们在发起 read 操做以后，能拿到一个 fd（文件描述符），对文件描述符不理解的小伙伴能够去翻一下怪怪以前写的《大前端进阶 Node.js》系列 多进程模型底层实现，里面有详细描述。

若是咱们发起 100 次 read 调用，那就会有 100 个 fd，select 能够批量监听文件描述符，咱们在调用 select 方法的时候，当前进程进入阻塞状态（注意，以前讲的非阻塞 IO 是 read 调用，select 是阻塞调用）。

当监听的这一批文件描述符里，有属于某个文件描述符的 IO 操做结束的时候，操做系统会发起中断，中断程序作的事情很简单，唤醒阻塞的进程。

这个时候意味着某个文件描述符的数据已经就绪了，但问题是哪个呢？母鸡。咋办呢？轮询。把全部监听的 fd 扫一遍，取出就绪的文件描述符，读取响应数据。

这样的话，以前两个问题就获得了解决，轮询消耗 cpu 问题经过阻塞进程，中断唤醒来解决，多文件监听问题经过 select 的多句柄监听特性来搞定。

大体流程以下图。

演进：epoll

select 解决了大多数的问题，但却带来了新的问题，如上面描述的同样，进程在被唤醒的时候一脸迷茫，是谁唤醒的我？？他要一个一个看。

若是文件过多，这种遍历对性能的影响是很大的，因此 select 设计之初便规定监听的文件描述符是有上限的，通常是 1024 个。

为了解决 select 留下的坑，诞生了咱们如今用的最普遍的 epoll。

epoll 最关键的优化点在于，引入了一个介于进程和 fd 之间的东西：eventpoll。

在有 IO 结束的时候，中断程序不是直接唤醒进程，而是会先把 IO 就绪的文件描述符放在 eventpoll 里面，后续在进程被唤醒后，不须要轮询整个 fd 列表，只须要在 eventpoll 里面拿就绪的文件描述符便可。

以上就是目前主流轮询技术的演进过程了~

下期预告，Node 之异步非阻塞 IO（下）

以前讲过，read 提供了非阻塞的 IO 调用方式，但系统在须要数据的时候，须要主动去获取，而不是异步的被通知，epoll 再美好，终究不是一个响水壶。

那是否是没有响水壶的存在呢？倒也不是，Linux 提供了 AIO 模式，是基于信号和回调的原生异步接口，但不幸的是这玩意只有 Linux 有，并且存在必定的缺陷（这里不展开讲了，有兴趣能够留言，日后安排一期来说）。

本文一开始就说了，异步非阻塞是 Node 的特性，它骗人？不，咱们上面讨论的各类观点都是基于单进程来讨论的，若是利用其多进程，虽然操做系统层面不支持响水壶，Node 能够本身来作一个。

eventloop + 线程池

如我上面的小标题，实现异步非阻塞 IO 的原理就是 eventloop+线程池。Node 在不一样的平台会对应不一样的系统调用，但不管如何，基本的架构大同小异。

具体的 Node 异步非阻塞 IO 架构，敬请期待怪怪的《大前端进阶 Node.js》系列 异步非阻塞（下）。

总结

本文已收录 GitHub https://github.com/ponkans/F2E，欢迎 Star，持续更新

这篇是基础，必要要先掌握，后面的理解起来才会有如鱼得水的感受~

这篇文章里，怪怪主要帮你们捋清了不少容易混淆的概念，并从操做系统的角度介绍了咱们目前 IO 的情况。总结下就是：

• 阻塞非阻塞看进程状态。
• 异步非异步看调用的特性。
• read 是同步非阻塞，能够看做是非阻塞 IO，但获取结果数据的方法是一种同步阻塞的方法，经常使用的就是上面讲的 epoll。

PS：看过网上部分文章，都没讲在点上，理解这个东西须要从最初，最本质去理解它，你才会真正的懂这个架构！

那 Node 如何异步非阻塞？eventLoop 究竟是个啥？留到本系列（下）来说。

近期原创传送门,biubiubiu：

• 《吐血整理》系列 大厂前端组件库工具集合（PC 端、移动端、JS、CSS 等）
• 《大前端进阶 Node.js》系列 P6 必备脚手架/CI 构建能力（上）
• 《大前端 基础组件》系列 80 行实现一个网页水印 npm 包
• 《大前端进阶 安全》系列 HTTPS 详解》

---

喜欢的小伙伴加个关注，点个赞哦，感恩💕😊

联系我 / 公众号

微信搜索【接水怪】或扫描下面二维码回复”加群“，我会拉你进技术交流群。讲真的，在这个群，哪怕您不说话，光看聊天记录也是一种成长。（阿里技术专家、敖丙做者、Java3y、蘑菇街资深前端、蚂蚁金服安全专家、各路大牛都在）。

接水怪也会按期原创，按期跟小伙伴进行经验交流或帮忙看简历。加关注，不迷路，有机会一块儿跑个步🏃 ↓↓↓