博客

同步阻塞与异步非阻塞

  • Post author:
  • Post category:其他




syncBlocking & asyncNonblocking

转载：https://www.zhihu.com/question/19732473/answer/23434554

作者：严肃

“阻塞”与”非阻塞”与”同步”与“异步”不能简单的从字面理解，提供一个从分布式系统角度的回答。


1.同步与异步


同步和异步关注的是

消息通信机制

(synchronous communication/ asynchronous communication)

所谓同步，就是在发出一个

调用

时，在没有得到结果之前，该

调用

就不返回。但是一旦调用返回，就得到返回值了。

换句话说，就是由

调用者

主动等待这个

调用

的结果。

而异步则是相反，


调用*在发出之后，这个调用就直接返回了，所以没有返回结果

。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在

调用*发出后，

被调用者

通过状态、通知来通知调用者，或通过回调函数处理这个调用。

典型的异步编程模型比如Node.js

举个通俗的例子：

你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下”，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。

而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过“回电”这种方式来回调。


2.阻塞与非阻塞

阻塞和非阻塞关注的是

程序在等待调用结果（消息，返回值）时的状态.

阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。

非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

还是上面的例子，

你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了， 当然你也要偶尔过几分钟check一下老板有没有返回结果。

在这里阻塞与非阻塞与是否同步异步无关。跟老板通过什么方式回答你结果无关。

如果是关心阻塞 IO/ 异步 IO, 参考 Unix Network Programming

View Book

–

还是2014年写的以解释概念为主，主要是同步异步 阻塞和非阻塞会被用在不同层面上，可能会有不准确的地方，并没有针对 阻塞 IO/ 异步 IO 等进行讨论，大家可以后续看看这两个回答：


怎样理解阻塞非阻塞与同步异步的区别？


怎样理解阻塞非阻塞与同步异步的区别？

作者：Shihui wang

  1. 阻塞非阻塞表示下面 买书过程中

    可能出现的状态

    ，是从

    我

    这个单进程角度来看待这个买书这个问题。
  2. 同步异步表示一种

    协作方式

    ，是从全局更高的角度 “

    进程之间 合作的方式”

    来看待买书这个业务。两个进程之间如果商量采用异步方式处理买书这一业务，就不存在阻塞这种状态。

同步异步： 某业务需要甲乙甚至多方合作的时候，

  1. 总是按照“甲方请求一次，乙方应答一次”这样的有序序列处理业务，只有当“一次请求一次应答”的过程结束才可以发生下一次的“一次请求一次应答”，那么就说他们采用的是同步。（

    同步IO中

    ，

    对同一个描述符的操作必须是有序的

    ）
  2. 如果甲方只要有需要，就会发送请求，不管上次请求有没有得到乙方应答。而乙方只要甲方有请求就会接受，不是等这次请求处理完毕再接受甲方新请求。这样请求应答分开的序列，就可以认为是异步。异步情况下，请求和应答不需要一致进行，可能甲方后请求的业务，却先得到乙方的应答。同步是线性的，而异步可以认为是并发的。（

    异步IO中，异步IO可以允许多方同时对同一个描述符发送IO请求，或者一次发多个请求，当然有机制保证如何区分这些请求，

    ）

举个例子：

  1. 我去买一本书，立即买到了，或者没有就走了，这就是非阻塞；（编程中设置IO成非阻塞，返回后再去检查描述符，或者等待通知，然后再去读取。相当于老板告诉我可以先忙点别的，过一会再来问问，或者老板通知我。但期间这个窗口(文件描述符)别人是用不了的）(”

    立即买到了”在IO中也需要等待，不能算非阻塞IO

    )
  2. 如果恰好书店没有，我就等一直等到书店有了这本书买到了才走，这就是阻塞；而排在我后面的人呢只有我买到了书后才能再买书了。
  3. 如果书店恰好没有，我就告诉书店老板，书来了告诉我一声让我来取或者直接送到我家，然后我就走了，去做别的事了，这就是异步。这时候如果很多人来买书，都是老板登记一下完事。 (

    从IO角度来说，“告诉我来取”，这个近似于信号驱动IO，不能算异步IO。必须书送到我家才算是异步，如果不送到我家，我想看这本书之前，终究还是需要我跑一趟

    )
  4. 前面两种情况，非阻塞和阻塞都可以称为同步。

反映在编程方面就是 用户进程 调用 系统调用。(用户进程对应我，内核 对应 书店老板，书对应数据资源data ， 买书就是一个系统调用了，

其中内核拷贝数据到进程这个过程近似于老板送书到我手中

）。


B. 在同步异步IO概念中，

同步异步的不同在于，针对同一个描述符上的IO操作，从

IO操作发起

到

得到 IO结果

这个过程而言，总是按照“发起请求，得到结果”这个有序序列进行的，这样便有了最小的等待这种情况：读取时，确知IO有数据，但需要等待内核拷贝数据到进程空间。这个最小情况的等待，同步IO都有。

unix网络编程中将IO模型分为5类：阻塞IO，非阻塞IO，IO复用，信号驱动，异步IO。

  1. 阻塞IO就是那种recv, read，一直等，等到有了数据才返回；
  2. 非阻塞IO就是立即返回，设置描述符为非阻塞，但是要进程自己一直检查是否可读；
  3. IO复用其实也是阻塞的，不过可以用来等很多描述符，比起阻塞有了进步，可以算有点异步了，但需要阻塞着检查是否可读。

    对同一个描述符的IO操作也是有序的。
  4. 信号驱动采用信号机制等待，有了更多的进步，不用监视描述符了，而且不用阻塞着等待数据到来，被动等待信号通知，由信号处理程序处理。

    但对同一个描述符的IO操作还是有序的。
  5. 异步IO，发送IO请求后，不用等了，也不再需要发送IO请求获取结果了。等到通知后，其实是系统帮你把数据读取好了的，

    你等到的通知也不再是要求你去读写IO了，而是告诉你IO请求过程已经结束了

    。你要做的就是可以处理数据了。且同一个描述符上可能同时存在很多请求。(对应上面那个买书例子中，就是送书到我家，我直接看书就行了，不需要再去跑一趟了)。


其中IO服用和信号驱动，在处理业务逻辑上可以说有异步，但在IO操作层面上来说还是同步的

。

======================================================================

作者：萧萧



IO 概念区分

四个相关概念：

  • 同步（Synchronous）
  • 异步( Asynchronous)
  • 阻塞( Blocking )
  • 非阻塞( Nonblocking)

这四个概念的含义以及相互之间的区别与联系，并不如很多网络博客所写的那么简单, 通过举一些什么商店购物， 买书买报的例子就能讲清楚。



进程间通信的同步/异步， 阻塞/非阻塞

首先强调一点， 网络上很多博文关于同步/异步， 阻塞非阻塞区别的解释其实都经不起推敲。 例如在

严肃

的这一高赞回答中 ， 有如下解释（不准确）：

  • 同步/异步关注的是消息通信机制 (synchronous communication/ asynchronous communication) 。

  • 所谓同步，就是在发出一个调用时，在没有得到结果之前， 该调用就不返回。

  • 异步则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果

  • 阻塞/非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.

  • 阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。

  • 非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

粗一看， 好像

同步/ 非同步

，

阻塞/非阻塞

是两种维度的概念， 可以分别对待， 但是稍微推敲一下就会发现上述的解释存在不妥之处。

  • 如果**“同步”

    是发起了一个调用后， 没有得到结果之前不返回， 那它毫无疑问就是被

    “阻塞”**了（即调用进程处于 “waiting” 状态）。
  • 如果**“异步”

    调用发出了以后就直接返回了， 毫无疑问， 这个进程没有被

    “阻塞”**。

所以， 上述的解释是不准确的。 让我们看一下《操作系统概念（第九版）》中有关进程间通信的部分是如何解释的：

翻译一下就是：

进程间的通信是通过 send() 和 receive() 两种基本操作完成的。具体如何实现这两种基础操作，存在着不同的设计。 消息的传递有可能是

阻塞的

或

非阻塞的

– 也被称为

同步

或

异步

的：

  • 阻塞式发送（blocking send）. 发送方进程会被一直阻塞， 直到消息被接受方进程收到。
  • 非阻塞式发送（nonblocking send）。 发送方进程调用 send() 后， 立即就可以其他操作。
  • 阻塞式接收（blocking receive） 接收方调用 receive() 后一直阻塞， 直到消息到达可用。
  • 非阻塞式接受（nonblocking receive） 接收方调用 receive() 函数后， 要么得到一个有效的结果， 要么得到一个空值， 即不会被阻塞。


上述不同类型的发送方式和不同类型的接收方式，可以自由组合。

  • 也就是说， 从进程级通信的维度讨论时， 阻塞和同步（非阻塞和异步）就是一对同义词， 且需要针对

    发送方

    和

    接收方

    作区分对待。

———- 下面对理解同步异步，阻塞非阻塞所需的知识点进行详细叙述———————


先修知识

  • 用户空间和内核空间

  • 进程切换

    • 系统调用（system call）
    • 中断（interrupt）

  • 进程的阻塞


用户空间和内核空间

操作系统为了支持多个应用同时运行，需要保证不同进程之间相对独立（一个进程的崩溃不会影响其他的进程 ， 恶意进程不能直接读取和修改其他进程运行时的代码和数据）。 因此操作系统内核

需要拥有高于普通进程的权限

， 以此来调度和管理用户的应用程序。

于是内存空间被划分为两部分，一部分为内核空间，一部分为用户空间，内核空间存储的代码和数据具有更高级别的权限。内存访问的

相关硬件

在程序执行期间会进行访问控制（ Access Control），使得用户空间的程序不能直接读写内核空间的内存。

  • 有《微机原理》 课程基础同学可以 Google 搜索 DPL, CPL 这两个关键字了解硬件层面的内存访问权限控制细节


进程切换

上图展示了进程切换中几个最重要的步骤：

  1. 当一个程序正在执行的过程中， 中断（interrupt） 或 系统调用（system call） 发生可以使得 CPU 的控制权会从当前进程转移到操作系统内核。
  2. 操作系统内核负责保存进程 i 在 CPU 中的上下文（程序计数器， 寄存器）到 PCBi （操作系统分配给进程的一个内存块）中。
  3. 从 PCBj 取出进程 j 的CPU 上下文， 将 CPU 控制权转移给进程 j ， 开始执行进程 j 的指令。

几个底层概念的通俗（不严谨）解释：

  • 中断（interrupt）

    • CPU 微处理器有一个中断信号位， 在每个CPU时钟周期的末尾, CPU会去检测那个中断信号位是否有中断信号到达， 如果有， 则会根据中断优先级决定是否要暂停当前执行的指令， 转而去执行处理中断的指令。 （其实就是 CPU 层级的 while 轮询）

  • 时钟中断( Clock Interrupt )

    • 一个硬件时钟会每隔一段（很短）的时间就产生一个中断信号发送给 CPU，CPU 在响应这个中断时， 就会去执行操作系统内核的指令， 继而将 CPU 的控制权转移给了操作系统内核， 可以由操作系统内核决定下一个要被执行的指令。

  • 系统调用（system call）

    • system call 是操作系统提供给应用程序的接口。 用户通过调用 systemcall 来完成那些需要操作系统内核进行的操作， 例如硬盘， 网络接口设备的读写等。

从上述描述中， 可以看出来， 操作系统在进行进切换时，需要进行一系列的内存读写操作， 这带来了一定的开销：

  • 对于一个运行着 UNIX 系统的现代 PC 来说， 进程切换通常至少需要花费 300 us 的时间


进程阻塞

作者：萧萧

上图展示了一个进程的不同状态：

  • New. 进程正在被创建.
  • Running. 进程的指令正在被执行
  • Waiting. 进程正在等待一些事件的发生（例如 I/O 的完成或者收到某个信号）
  • Ready. 进程在等待被操作系统调度
  • Terminated. 进程执行完毕（可能是被强行终止的）

我们所说的 “阻塞”是指进程在

发起了一个系统调用

（System Call） 后， 由于该系统调用的操作不能立即完成，需要等待一段时间，于是内核将进程挂起为**等待 （waiting）**状态， 以确保它不会被调度执行， 占用 CPU 资源。

  • 友情提示：

    在任意时刻， 一个 CPU 核心上（processor）只可能运行一个进程

    。



I/O System Call 的阻塞/非阻塞， 同步/异步

这里再重新审视

阻塞/非阻塞 IO

这个概念， 其实

阻塞和非阻塞

描述的是进程的一个操作是否会使得进程转变为“等待”的状态， 但是为什么我们总是把它和 IO 连在一起讨论呢？

原因是，

阻塞

这个词是与系统调用 System Call 紧紧联系在一起的， 因为要让一个进程进入 等待（waiting） 的状态, 要么是它主动调用 wait() 或 sleep() 等挂起自己的操作， 另一种就是它调用 System Call, 而 System Call 因为涉及到了 I/O 操作， 不能立即完成， 于是内核就会先将该进程置为等待状态， 调度其他进程的运行， 等到 它所请求的 I/O 操作完成了以后， 再将其状态更改回 ready 。

操作系统内核在执行 System Call 时， CPU 需要与 IO 设备完成一系列物理通信上的交互， 其实再一次会涉及到阻塞和非阻塞的问题， 例如， 操作系统发起了一个读硬盘的请求后， 其实是向硬盘设备通过总线发出了一个请求，它即可以阻塞式地等待IO 设备的返回结果，也可以非阻塞式的继续其他的操作。 在现代计算机中，这些物理通信操作基本都是异步完成的， 即发出请求后， 等待 I/O 设备的中断信号后， 再来读取相应的设备缓冲区。 但是，大部分操作系统默认为用户级应用程序提供的都是阻塞式的系统调用 （blocking systemcall）接口， 因为阻塞式的调用，使得应用级代码的编写更容易（代码的执行顺序和编写顺序是一致的）。

但同样， 现在的大部分操作系统也会提供非阻塞I/O 系统调用接口（Nonblocking I/O system call）。 一个非阻塞调用不会挂起调用程序， 而是会立即返回一个值， 表示有多少bytes 的数据被成功读取（或写入）。

非阻塞I/O 系统调用( nonblocking system call )的另一个替代品是

异步I/O系统调用 （asychronous system call）

。 与非阻塞 I/O 系统调用类似，asychronous system call 也是会立即返回， 不会等待 I/O 操作的完成， 应用程序可以继续执行其他的操作， 等到 I/O 操作完成了以后，操作系统会通知调用进程（设置一个用户空间特殊的变量值 或者 触发一个 signal 或者 产生一个软中断 或者 调用应用程序的回调函数）。

此处，

非阻塞I/O 系统调用( nonblocking system call )

和 **异步I/O系统调用 （asychronous system call）**的区别是：

  • 一个

    非阻塞I/O 系统调用 read()

    操作立即返回的是任何可以立即拿到的数据， 可以是完整的结果， 也可以是不完整的结果， 还可以是一个空值。
  • 而

    异步I/O系统调用

    read（）结果必须是完整的， 但是这个操作完成的通知可以延迟到将来的一个时间点。

下图展示了同步I/O 与 异步 I/O 的区别 （非阻塞 IO 在下图中没有绘出）.

img

作者：萧萧

注意， 上面提到的

非阻塞I/O 系统调用( nonblocking system call )

和

异步I/O系统调用

都是非阻塞式的行为（non-blocking behavior）。 他们的差异仅仅是返回结果的方式和内容不同。



非阻塞 I/O 如何帮助服务器提高吞吐量

考虑一个

单进程

服务器程序， 收到一个 Socket 连接请求后， 读取请求中的文件名，然后读请求的文件名内容，将文件内容返回给客户端。 那么一个请求的处理流程会如下图所示。

img

  • R 表示读操作
  • W 表示写操作
  • C 表示关闭操作

在这个过程中， 我们可以看到， CPU 和 硬盘IO 的资源大部分时间都是闲置的。 此时， 我们会希望在等待 I/O 的过程中继续处理新的请求。

方案一： 多进程

  • 每到达一个请求， 我们为这个请求新创建一个进程来处理。 这样， 一个进程在等待 IO 时， 其他的进程可以被调度执行， 更加充分地利用 CPU 等资源。
  • 问题： 每新创建一个进程都会消耗一定的内存空间， 且进程切换也会有时间消耗， 高并发时， 大量进程来回切换的时间开销会变得明显起来。

方案二：多线程

  • 和多进程方案类似，为每一个请求新建一个线程进行处理，这样做的重要区别是， 所有的线程都共享同一个进程空间
  • 问题： 需要考虑是否需要为特定的逻辑使用锁。

引申问题： 一个进程中的某一个线程发起了 system call 后， 是否造成整个进程的阻塞？ 如果会， 那么多线程方案与单进程方案相比就没有明显的改善。

  • 解决办法1：内核支持的线程（kenerl supported threads）

    • 操作系统内核能够感知到线程， 每一个线程都会有一个内核调用栈（kenerl stack） 和 保存CPU 寄存器下文的 table 。

img

在这种方案中， 如果 CPU 是多核的， 不同的线程还可以运行在不同的 CPU processor 上。 既实现了IO 并发， 也实现了 CPU 并发。

问题： 内核支持线程可移植性差， 其实现对于不同的操作系统而言有所差别。

  • 解决办法2： 用户支持的线程（user supported threads）

    • 内核感知不到用户线程， 每一个用户的进程拥有一个调度器， 该调度器可以感知到线程发起的系统调用， 当一个线程产生系统调用时， 不阻塞整个进程， 切换到其他线程继续运行。 当 I/O 调用完成以后， 能够重新唤醒被阻塞的线程。

    • 实现细节：

      • 应用程序基于线程库 thread libray 编写
      • 线程库中包含 “虚假的” read(), write(), accept()等系统调用。
      • 线程库中的 read(), write(), accept() 的底层实现为非阻塞系统调用（Non-blocking system call）， 调用后，由于可以立即返回， 则将特定的线程状态标记为 waiting, 调度其他的可执行线程。 内核完成了 IO 操作后， 调用线程库的回调函数， 将原来处于 waiting 状态的线程标记为 runnable.

img

从上面的过程可以看出，用户级支持线程（User-Supported Threads）的解决方案基于非阻塞IO系统调用( non-blocking system call) ， 且是一种基于操作系统内核事件通知（event-driven）的解决方案， 该方案可以降低系统处理并发请求时的进程切换开销。 基于这个方案， 可以引申到更为宽泛的 event-driven progreamming 话题上。 但是这里就不作赘述了。



总结：

  1. 阻塞/非阻塞， 同步/异步的概念要注意讨论的上下文：
  • 在进程通信层面， 阻塞/非阻塞， 同步/异步基本是同义词， 但是需要注意区分讨论的对象是发送方还是接收方。
  • 发送方阻塞/非阻塞（同步/异步）和接收方的阻塞/非阻塞（同步/异步） 是互不影响的。
  • 在 IO 系统调用层面（ IO system call ）层面，

    非阻塞 IO 系统调用

    和

    异步 IO 系统调用

    存在着一定的差别， 它们都不会阻塞进程， 但是返回结果的方式和内容有所差别， 但是都属于非阻塞系统调用（ non-blocing system call ）
  1. 非阻塞系统调用（non-blocking I/O system call 与 asynchronous I/O system call） 的存在可以用来实现线程级别的 I/O 并发， 与通过多进程实现的 I/O 并发相比可以减少内存消耗以及进程切换的开销。

作者：野人

#比喻2

#链接：https://www.zhihu.com/question/19732473/answer/23434554

老张爱喝茶，废话不说，煮开水。出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。

1 老张把水壶放到火上，立等水开。（同步阻塞）老张觉得自己有点傻

2 老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。

3 老张把响水壶放到火上，立等水开。（异步阻塞）老张觉得这样傻等意义不大4 老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）老张觉得自己聪明了。

所谓同步异步，只是对于水壶而言。

普通水壶，同步；响水壶，异步。虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。同步只能让调用者去轮询自己（情况2中），造成老张效率的低下。

所谓阻塞非阻塞，仅仅对于老张而言。

立等的老张，阻塞；看电视的老张，非阻塞。情况1和情况3中老张就是阻塞的，媳妇喊他都不知道。虽然3中响水壶是异步的，可对于立等的老张没有太大的意义。

所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。

#比喻3

#

http://maples7.com/2016/08/24/understand-sync-async-and-blocking-non-blocking/


假设小明需要在网上下载一个软件：

如果小明点击下载按钮之后，就一直干瞪着进度条不做其他任何事情直到软件下载完成，这是同步阻塞；

如果小明点击下载按钮之后，就一直干瞪着进度条不做其他任何事情直到软件下载完成，但是软件下载完成其实是会「叮」的一声通知的（但小明依然那样干等着），这是异步阻塞；（不常见）

如果小明点击下载按钮之后，就去做其他事情了，不过他总需要时不时瞄一眼屏幕看软件是不是下载完成了，这是同步非阻塞；

如果小明点击下载按钮之后，就去做其他事情了，软件下载完之后「叮」的一声通知小明，小明再回来继续处理下载完的软件，这是异步非阻塞。

相信看完以上两个个案例之后，这几个概念已经能够分辨得很清楚了。

总的来说，同步和异步关注的是任务完成消息通知的机制，而阻塞和非阻塞关注的是等待任务完成时请求者的状态。

（A）同步和异步，是针对调用结果是如何返回给调用者来说的，即调用的结果是调用者主动去获取的（比如一直等待recvfrom或者设置超时等待select），则为同步，而调用结果是被调用者在完成之后通知调用者的，则为异步（比如windows的IOCP）。

（B）阻塞和非阻塞，是针对调用者所在线程是否在调用之后主动挂起来说的，即如果在线程中调用者发出调用之后，再被调用这返回之前，该线程主动挂起，则为阻塞，若线程不主动挂起，而继续向下执行，则为非阻塞。

这样，在网络IO中，同步异步，阻塞非阻塞，就可以形成2×2 = 4种情况:

（1）同步阻塞： 调用者发出某调用之后（比如调用了read函数），如果函数不能立即返回，则挂起所在线程，等待结果；

（2）同步非阻塞：调用者发出调用之后（比如read），如果当时有数据可读，则读取并返回，如果没有数据可读，则线程继续向下执行。在实际使用时，read调用会在一个循环中，这样就可以不断的读取数据（尽管可能某次read操作并不能获得任何数据）；

（3）异步阻塞：调用者发出调用之后（如async_recv），线程挂起，被调用的读操作由系统（或者库）来进行，等待有结果之后，系统（或者库）通过某种机制来通知调用者（在调用者获得结果之前，调用者所在线程一直阻塞，这个看起来和同步阻塞很像，但可以这样理解，同步阻塞相当于调用者A调用了一个函数F，F是在调用者A所在的线程中完成的，而异步阻塞相当于调用者A发出对F的调用，然后A所在线程挂起，而实际F是在另一个线程中完成，然后另一个线程通知给A所在的线程，更准确的是将两个线程分别换成用户进程和内核）；

（4）异步非阻塞：调用者发出调用之后（如async_recv），线程继续进行别的操作，被调用的读操作由系统（或者库）来进行，等待有结果之后，系统（或者库）通过某种机制（一般为调用调用者设置的回调函数）来通知调用者