同步与阻塞，异步与非阻塞的区别

时间 2019-11-12

标签同步阻塞异步区别繁體版

原文原文链接

同步与异步是对应的，它们是线程之间的关系，两个线程之间要么是同步的，要么是异步的。

阻塞与非阻塞是对同一个线程来讲的，在某个时刻，线程要么处于阻塞，要么处于非阻塞。

阻塞是使用同步机制的结果，非阻塞则是使用异步机制的结果。

处理大并发之一对异步非阻塞的理解

在研究nginx和node.js的时候常会遇到异步、非阻塞等，以前本身也常用epoll，对其同步与阻塞，异步与非阻塞有了必定的认识，现对参考资料总结下。node

首先讨论下使用事件驱动，异步编程的优势：linux

充分利用了系统资源，执行代码无须阻塞等待某种操做完成，有限的资源能够用于其余的任务。其很是适合于后端的网络服务编程。nginx

在服务器开发中，并发的请求处理是个大问题，阻塞式的函数会致使资源浪费和时间延迟。经过事件注册、异步函数，开发人员能够提升资源的利用率，性能也会改善。其nginx和node.js处理并发都是采用的事件驱动异步非阻塞模式。其中nginx中处理并发用的是epoll，poll,queue等方式，node.js使用的是libev，它们对大规模的HTTP请求处理的都很好。web

阻塞

《node.js开发指南》是这样定义的：线程在执行中若是遇到（I/O 操做）如磁盘读写或网络通讯，一般要耗费较长的时间，这时操做系统会剥夺这个线程的 CPU 控制权，使其暂停执行，同时将资源让给其余的工做线程，这种线程调度方式称为阻塞。当 I/O 操做完毕时，操做系统将这个线程的阻塞状态解除，恢复其对CPU的控制权，令其继续执行。这种 I/O 模式就是一般的同步式 I/O（Synchronous I/O）或阻塞式 I/O（Blocking I/O）。编程

非阻塞

非阻塞是这样定义的，当线程遇到 I/O 操做时，不会以阻塞的方式等待 I/O 操做的完成或数据的返回，而只是将 I/O 请求发送给操做系统，继续执行下一条语句。当操做系统完成 I/O 操做时，以事件的形式通知执行 I/O 操做的线程，线程会在特定时候处理这个事件。后端

对比阻塞与非阻塞

阻塞模式下，一个线程只能处理一项任务，要想提升吞吐量必须经过多线程。服务器

非阻塞模式下，一个线程永远在执行计算操做，这个线程所使用的 CPU 核心利用率永远是 100%，I/O 以事件的方式通知。网络

在阻塞模式下，多线程每每能提升系统吞吐量，由于一个线程阻塞时还有其余线程在工做，多线程可让 CPU 资源不被阻塞中的线程浪费。多线程

而在非阻塞模式下，线程不会被 I/O 阻塞，永远在利用 CPU。多线程带来的好处仅仅是在多核 CPU 的状况下利用更多的核。并发

来看看《深刻浅出Node.js》对异步I/O的解释，在操做系统中，程序运行的空间分为内核空间和用户空间。咱们经常提起的异步I/O，其实质是用户空间中的程序不用依赖内核空间中的I/O操做实际完成，便可进行后续任务。

I/O的阻塞与非阻塞的解释

阻塞模式的I/O会形成应用程序等待，直到I/O完成。同时操做系统也支持将I/O操做设置为非阻塞模式，这时应用程序的调用将可能在没有拿到真正数据时就当即返回了，为此应用程序须要屡次调用才能确认I/O操做彻底完成。

I/O的同步与异步I/O的同步与异步出如今应用程序中。若是作阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步情况。相反，I/O为非阻塞模式时，应用程序则是异步的。

参照《node.js入门经典》中对同步的解释，同步的代码意味着每一次执行一个操做，在一个操做完成以前，代码的执行会被阻塞，没法移到下一个操做上。也就是说代码的执行会在函数返回前中止。直到函数返回后，代码才会继续执行。

相反，异步就意味着函数的执行无需等待某个操做的结果就能够继续执行，其操做的结果会在事件发生时由回调来处理。

异步I/O优缺点

使用同步IO，它的优势是可使程序调试方便，可是它的缺点也是明显的，程序的执行过程当中若是入到一些耗时的IO操做，程序的执行都要等待该IO的完成，在这个等待的过程当中，程序没法充分利用CPU，致使了CPU的闲置，为了充分利用CPU，和IO并行操做，经常使用的方法有2中：

（1）多线程单进程

多线程的设计之处就是为了在共享的程序空间中，实现并行处理任务，从而达到充分利用CPU的效果。

多线程缺点：

其1、执行时（线程切换）上下文交换的开销较大，一个线程大约须要2M的内存空间，占用资源较大。

其2、状态同步（锁）的问题，它也使得程序的编写和调用复杂化。

（2）单线程多进程

为了不多线程形成的使用不便问题，有的语言选择了单线程保持调用简单化，采用启动多进程的方式来达到充分利用CPU和提高整体的并行处理能力。它的缺点在于业务逻辑复杂时（涉及多个I/O调用），由于业务逻辑不能分布到多个进程之间，事务处理时长要远远大于多线程模式。

异步I/O与轮询技术

当进行非阻塞I/O调用时，要读到完整的数据，应用程序须要进行屡次轮询，才能确保读取数据完成，以进行下一步的操做。轮询技术的缺点在于应用程序要主动调用，会形成占用较多CPU时间片，性能较为低下。现存的轮询技术有如下这些： read、select、poll、epoll、pselect、kqueue

read是性能最低的一种，它经过重复调用来检查I/O的状态来完成完整数据读取。

select是一种改进方案，经过对文件描述符上的事件状态来进行判断。

操做系统还提供了poll、epoll等多路复用技术来提升性能。

轮询技术知足了异步I/O确保获取完整数据的保证。可是对于应用程序而言，它仍然只能算时一种同步，由于应用程序仍然须要主动去判断I/O的状态，依旧花费了不少CPU时间来等待。上一种方法重复调用read进行轮询直到最终成功，用户程序会占用较多CPU，性能较为低下。而实际上操做系统提供了select方法来代替这种重复read轮询进行状态判断。select内部经过检查文件描述符上的事件状态来进行判断数据是否彻底读取。可是对于应用程序而言它仍然只能算是一种同步，由于应用程序仍然须要主动去判断I/O的状态，依旧花费了不少CPU时间等待，select也是一种轮询。

理想的异步I/O模型

理想的异步I/O应该是应用程序发起异步调用，而不须要进行轮询，进而处理下一个任务，只需在I/O完成后经过信号或是回调将数据传递给应用程序便可。

暂时就整理这么多吧，感受好多看过的东西都忘记了，回头会写一篇关于epoll使用的详细例子，该例子支持2W并发是经过的。哎，今天状态很差，写的很差，本打算本身多加点什么的，结果都是参考别人的，若有错误请你们指正，谢谢。

参考资料：

《node.js入门经典》 George Ornbo 著傅强陈宗赋译人民邮电出版社

《深刻浅出node.js》

《node.js开发指南》 BYVoid 人民邮电出版社

如是转载，请指明原出处：http://blog.csdn.net/feitianxuxue，谢谢合做！

同步（synchronous） IO和异步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分别是什么，到底有什么区别？这个问题其实不一样的人给出的答案均可能不一样，好比wiki，就认为asynchronous IO和non-blocking IO是一个东西。这实际上是由于不一样的人的知识背景不一样，而且在讨论这个问题的时候上下文(context)也不相同。因此，为了更好的回答这个问题，我先限定一下本文的上下文。
本文讨论的背景是Linux环境下的network IO。
本文最重要的参考文献是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2节“I/O Models ”，Stevens在这节中详细说明了各类IO的特色和区别，若是英文够好的话，推荐直接阅读。Stevens的文风是有名的深刻浅出，因此不用担忧看不懂。本文中的流程图也是截取自参考文献。

Stevens在文章中一共比较了五种IO Model：
    blocking IO
    nonblocking IO
    IO multiplexing
    signal driven IO
    asynchronous IO
因为signal driven IO在实际中并不经常使用，因此我这只说起剩下的四种IO Model。

再说一下IO发生时涉及的对象和步骤。
对于一个network IO (这里咱们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，另外一个就是系统内核(kernel)。当一个read操做发生时，它会经历两个阶段：
1 等待数据准备 (Waiting for the data to be ready)
2 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)
记住这两点很重要，由于这些IO Model的区别就是在两个阶段上各有不一样的状况。

blocking IO
在linux中，默认状况下全部的socket都是blocking，一个典型的读操做流程大概是这样：

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来讲，不少时候数据在一开始尚未到达（好比，尚未收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，而后kernel返回结果，用户进程才解除block的状态，从新运行起来。
因此，blocking IO的特色就是在IO执行的两个阶段都被block了。

non-blocking IO

linux下，能够经过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操做时，流程是这个样子：

从图中能够看出，当用户进程发出read操做时，若是kernel中的数据尚未准备好，那么它并不会block用户进程，而是马上返回一个error。从用户进程角度讲，它发起一个read操做后，并不须要等待，而是立刻就获得了一个结果。用户进程判断结果是一个error时，它就知道数据尚未准备好，因而它能够再次发送read操做。一旦kernel中的数据准备好了，而且又再次收到了用户进程的system call，那么它立刻就将数据拷贝到了用户内存，而后返回。
因此，用户进程实际上是须要不断的主动询问kernel数据好了没有。

IO multiplexing

IO multiplexing这个词可能有点陌生，可是若是我说select，epoll，大概就都能明白了。有些地方也称这种IO方式为event driven IO。咱们都知道，select/epoll的好处就在于单个process就能够同时处理多个网络链接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的全部socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”全部select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操做，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并无太大的不一样，事实上，还更差一些。由于这里须要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom)。可是，用select的优点在于它能够同时处理多个connection。（多说一句。因此，若是处理的链接数不是很高的话，使用select/epoll的web server不必定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优点并非对于单个链接能处理得更快，而是在于能处理更多的链接。）
在IO multiplexing Model中，实际中，对于每个socket，通常都设置成为non-blocking，可是，如上图所示，整个用户的process实际上是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

Asynchronous I/O

linux下的asynchronous IO其实用得不多。先看一下它的流程：

用户进程发起read操做以后，马上就能够开始去作其它的事。而另外一方面，从kernel的角度，当它受到一个asynchronous read以后，首先它会马上返回，因此不会对用户进程产生任何block。而后，kernel会等待数据准备完成，而后将数据拷贝到用户内存，当这一切都完成以后，kernel会给用户进程发送一个signal，告诉它read操做完成了。

到目前为止，已经将四个IO Model都介绍完了。如今回过头来回答最初的那几个问题：blocking和non-blocking的区别在哪，synchronous IO和asynchronous IO的区别在哪。
先回答最简单的这个：blocking vs non-blocking。前面的介绍中其实已经很明确的说明了这二者的区别。调用blocking IO会一直block住对应的进程直到操做完成，而non-blocking IO在kernel还准备数据的状况下会马上返回。

在说明synchronous IO和asynchronous IO的区别以前，须要先给出二者的定义。Stevens给出的定义（实际上是POSIX的定义）是这样子的：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
二者的区别就在于synchronous IO作”IO operation”的时候会将process阻塞。按照这个定义，以前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。有人可能会说，non-blocking IO并无被block啊。这里有个很是“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操做，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，若是kernel的数据没有准备好，这时候不会block进程。可是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。而asynchronous IO则不同，当进程发起IO 操做以后，就直接返回不再理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程当中，进程彻底没有被block。

各个IO Model的比较如图所示：

通过上面的介绍，会发现non-blocking IO和asynchronous IO的区别仍是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，可是它仍然要求进程去主动的check，而且当数据准备完成之后，也须要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而asynchronous IO则彻底不一样。它就像是用户进程将整个IO操做交给了他人（kernel）完成，而后他人作完后发信号通知。在此期间，用户进程不须要去检查IO操做的状态，也不须要主动的去拷贝数据。最后，再举几个不是很恰当的例子来讲明这四个IO Model:有A，B，C，D四我的在钓鱼：A用的是最老式的鱼竿，因此呢，得一直守着，等到鱼上钩了再拉杆；B的鱼竿有个功能，可以显示是否有鱼上钩，因此呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；C用的鱼竿和B差很少，但他想了一个好办法，就是同时放好几根鱼竿，而后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；D是个有钱人，干脆雇了一我的帮他钓鱼，一旦那我的把鱼钓上来了，就给D发个短信。