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

之前一直对阻塞非阻塞与同步异步这两对概念理解不深，总是把它们搞混。看了网上一些相关的解释之后，发现大家站在不同的角度得出了不同的理解，这个问题没有确切的答案，只能根据场景不同做出解释。

进程间的通信

进程间的通信时通过 send() 和 receive() 两种基本操作完成的。具体如何实现这两种基础操作，存在着不同的设计。
消息的传递有可能是阻塞的或非阻塞的，也被称为同步或异步的：

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

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

也就是说， 从进程级通信的维度讨论时， 阻塞和同步（非阻塞和异步）就是一对同义词， 且需要针对发送方和接收方作区分对待。

UNIX环境下的网络IO

《UNIX网络编程：卷一》第六章——I/O复用。书中向我们提及了5种类UNIX下可用的I/O模型

1. 阻塞式I/O
2. 非阻塞式I/O
3. I/O复用（select，poll，epoll...）
4. 信号驱动式I/O（SIGIO）
5. 异步I/O（POSIX的aio_系列函数）

阻塞式I/O模型

对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的进程(或者线程)，另一个就是系统内核。当一个read操作发生时，它会经历两个阶段：

（1）等待数据准备好；
（2）将数据从内核拷贝到进程中。

在UNIX中，默认情况下所有套接字都是阻塞的，一个典型的读操作流程如下图所示：

 

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除阻塞的状态，重新运行起来。

所以，阻塞式 IO的特点就是在IO执行的两个阶段都被block了。
 

非阻塞式I/O

UNIX 下，可以通过设置socket使其变为非阻塞式。当对一个非阻塞式socket执行读操作时，流程如下图所示：

 

从图中可以看出，当用户进程发出read操作时，如果内核中的数据还没有准备好，那么它并不会阻塞用户进程，而是立刻返回一个错误。从用户进程角度讲 ，它发起一个 read 操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个错误时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦内核中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，用户进程其实是需要不断的主动询问内核数据好了没有。

I/O多路复用

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

当用户进程调用了select，那么整个进程会被阻塞，而同时，内核会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和阻塞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，但是，如上图所示，整个用户的进程其实是一直被block的。只不过进程是被select这个函数block，而不是被socket IO给block。

信号驱动式I/O

用的很少，流程如下图所示：

 

异步I/O

这类函数的工作机制是告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到用户空间）完成后通知我们。如图：

 

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

对比

现在回过头来回答最初的那几个问题：阻塞 vs 非阻塞的区别在哪，同步 vs 异步的区别在哪？
阻塞 vs 非阻塞。前面的介绍中其实已经很明确的说明了这两者的区别。调用阻塞IO会一直block住对应的进程直到操作完成，而非阻塞 IO在内核还准备数据的情况下会立刻返回。

再看POSIX对这两个术语的定义：

• 同步I/O操作：导致请求进程阻塞，直到I/O操作完成；

• 异步I/O操作：不导致请求进程阻塞。

同步 vs 异步的区别就在于同步 做”IO operation”的时候会将进程阻塞。按照这个定义，之前所述的b阻塞，非阻塞 IO，IO 多路服用都属于同步 IO。有人可能会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，就是例子中的recvfrom这个system call。非阻塞 IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被阻塞了，在这段时间内，进程是被阻塞的。

而asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

 

进程间合作

阻塞非阻塞： 请求不能立即得到应答，需要等待，那就是阻塞；否则可以理解为非阻塞。

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

1. 总是按照“甲方请求一次，乙方应答一次”这样的有序序列处理业务，只有当“一次请求一次应答”的过程结束才可以发生下一次的“一次请求一次应答”，那么就说他们采用的是同步。（同步IO中，对同一个描述符的操作必须是有序的）
2. 如果甲方只要有需要，就会发送请求，不管上次请求有没有得到乙方应答。而乙方只要甲方有请求就会接受，不是等这次请求处理完毕再接受甲方新请求。这样请求应答分开的序列，就可以认为是异步。异步情况下，请求和应答不需要一致进行，可能甲方后请求的业务，却先得到乙方的应答。同步是线性的，而异步可以认为是并发的。（异步IO中，异步IO可以允许多方同时对同一个描述符发送IO请求，或者一次发多个请求，当然有机制保证如何区分这些请求，）

参考整理自：

1. https://www.zhihu.com/question/19732473/answer/26101328
2. https://blog.csdn.net/historyasamirror/article/details/5778378 
3. https://www.zhihu.com/question/19732473/answer/14413599