同步synchronous IO和异步asynchronous IO阻塞blocking IO和非阻塞non-blockingIO分别是什么到底有什么区别这个问题其实不同的人给出的答案都可能不同比如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 Modelblocking IOnonblocking IOIO multiplexingsignal driven IOasynchronous 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 IOlinux下可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时流程是这个样子从图中可以看出当用户进程发出read操作时如果kernel中的数据还没有准备好那么它并不会block用户进程而是立刻返回一个error。从用户进程角度讲 它发起一个read操作后并不需要等待而是马上就得到了一个结果。用户进程判断结果是一个error时它就知道数据还没有准备好于是它可以再次发送read操作。一旦kernel中的数据准备好了并且又再次收到了用户进程的system call那么它马上就将数据拷贝到了用户内存然后返回。所以用户进程其实是需要不断的主动询问kernel数据好了没有。IO multiplexingIO multiplexing这个词可能有点陌生但是如果我说selectepoll大概就都能明白了。有些地方也称这种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/Olinux下的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 IOnon-blocking IOIO 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:有ABCD四个人在钓鱼A用的是最老式的鱼竿所以呢得一直守着等到鱼上钩了再拉杆B的鱼竿有个功能能够显示是否有鱼上钩所以呢B就和旁边的MM聊天隔会再看看有没有鱼上钩有的话就迅速拉杆C用的鱼竿和B差不多但他想了一个好办法就是同时放好几根鱼竿然后守在旁边一旦有显示说鱼上钩了它就将对应的鱼竿拉起来D是个有钱人干脆雇了一个人帮他钓鱼一旦那个人把鱼钓上来了就给D发个短信。————————————————原文链接https://blog.csdn.net/historyasamirror/article/details/5778378