IO - 同步，异步，阻塞，非阻塞

当你发现本身最受欢迎的一篇blog其实大错特错时，这绝对不是一件让人愉悦的事。
《 IO - 同步，异步，阻塞，非阻塞 》是我在开始学习epoll和libevent的时候写的，主要的思路来自于文中的那篇link 。写完以后发现不少人都很喜欢，我仍是很是开心的，也说明这个问题确实困扰了不少人。随着学习的深刻，渐渐的感受原来的理解有些误差，可是仍是没引发本身的重视，觉着都是一些小错误，无伤大雅。直到有位博友问了一个问题，我从新查阅了一些更权威的资料，才发现原来的文章中有很大的理论错误。我不知道有多少人已经看过这篇blog并受到了个人误导，鄙人在此表示抱歉。俺之后写技术blog会更加严谨的。
一度想把原文删了，最后仍是没舍得。毕竟每篇blog都花费了很多心血，另外放在那里也能够引觉得戒。因此这里新补一篇。算是亡羊补牢吧。

言归正传。
同步（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。

 

咱们首先要肯定一下咱们讨论的上下文(context)，那就是Linux的network IO。对于一个网络IO来讲（以read做为例子），其执行过程一般能够分为两个阶段。第一阶段，等待数据从网络中到达，并被拷贝到内核中某个缓冲区(Waiting for the data to be ready)。第二阶段，把数据从内核态的缓冲区拷贝到用户态的应用进程缓冲区来(Copying the data from the kernel to the process)。

再说一下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数据好了没有。

       默认建立的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的NIO并不是Java的NIO（New IO）库

      用户须要不断地调用read，尝试读取socket中的数据，直到读取成功后，才继续处理接收的数据。
整个IO请求的过程当中，虽然用户线程每次发起IO请求后能够当即返回，可是为了等到数据，
仍须要不断地轮询、重复请求，消耗了大量的CPU的资源。
通常不多直接使用这种模型，而是在其余IO模型中使用非阻塞IO这一特性。

 

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的优点并非对于单个链接能处理得更快，而是在于能处理更多的链接。）使用select之后最大的优点是用户能够

在一个线程内同时处理多个socket的IO请求。便可达到在同一个线程内同时处理多个IO请求的目的

在IO multiplexing Model中，实际中，对于每个socket，通常都设置成为non-blocking，可是，如上图所示，整个用户的process实际上是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

 

此模型用到select和poll函数，这两个函数也会使进程阻塞，
用户首先将须要进行IO操做的socket添加到select中，
而后阻塞等待select系统调用返回，select先阻塞，有活动套接字才返回，
可是和阻塞I/O不一样的是，这两个函数能够同时阻塞多个I/O操做，并且能够同时对多个读操做，
多个写操做的I/O函数进行检测，直到有数据可读或可写（就是监听多个socket）。select被调用后，
进程会被阻塞，内核监视全部select负责的socket，
当有任何一个socket的数据准备好了，select就会返回套接字可读，咱们就能够调用recvfrom处理数据。
正由于阻塞I/O只能阻塞一个I/O操做，而I/O复用模型可以阻塞多个I/O操做，因此才叫作多路复用。

 

IO多路复用模型是创建在内核提供的多路分离函数select基础之上的，使用select函数能够
避免同步非阻塞IO模型中轮询等待的问题。
为了不这里cpu的空转，咱们不让这个线程亲自去检查流中是否有事件，
而是引进了一个代理(一开始是select,后来是poll)，这个代理很牛，
它能够同时观察许多流的I/O事件，若是没有事件，代理就阻塞，线程就不会挨个挨个去轮询了，
  可是依然有个问题，咱们从select那里仅仅知道了，有I/O事件发生了，
却并不知道是哪那几个流（可能有一个，多个，甚至所有），
咱们只能无差异轮询全部流，找出能读出数据，或者写入数据的流，
对他们进行操做。因此select具备O(n)的无差异轮询复杂度，
同时处理的流越多，无差异轮询时间就越长。

epoll能够理解为event poll，不一样于忙轮询和无差异轮询，
epoll会把哪一个流发生了怎样的I/O事件通知咱们。
因此咱们说epoll其实是事件驱动（每一个事件关联上fd）的，此时咱们对这些流的操做都是有意义的。
（复杂度下降到了O(1)）
能够看到，select和epoll最大的区别就是：select只是告诉你必定数目的流有事件了，
至于哪一个流有事件，还得你一个一个地去轮询，而epoll会把发生的事件告诉你，
经过发生的事件，就天然而然定位到哪一个流了。不能不说epoll跟select相比，是质的飞跃，我以为这也是一种牺牲空间，
换取时间的思想，

 

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发个短信。

 

I/O多路复用中的select、poll、epoll的区别

epoll跟select都能提供多路I/O复用的解决方案。在如今的Linux内核里都可以支持，其中epoll是Linux所特有，而select则是POSIX所规定，通常操做系统（包括Windows–Windows也兼容POSIX的较老标准）均有实现。

select：select本质上是经过设置或者检查存放fd标志位的数据结构来进行下一步处理。单个进程可监视的fd数量被限制、对socket进行扫描时是采用轮询的方法致使效率较低。

poll：poll本质上和select没有区别，但没有最大链接数的限制由于它是基于链表来存储的。

epoll： epoll使用“事件”的就绪通知方式，经过epoll_ctl注册fd，一旦该fd就绪，内核就会采用相似callback的回调机制来激活该fd，epoll_wait即可以收到通知。由于epoll没有最大并发链接的限制、只有活跃可用的FD才会调用callback函数使得效率提高、使用mmap内存映射减小复制开销。