阻塞、非阻塞与异步、同步（转载+整理）

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

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

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

 

 

 

 

 

 

IO -
同步，异步，阻塞，非阻塞（亡羊补牢篇）
当你发现自己最受欢迎的一篇blog其实大错特错时，这绝对不是一件让人愉悦的事。
《IO - 同步，异步，阻塞，非阻塞》是我在开始学习epoll和libevent的时候写的，主要的思路来自于文中的那篇link。写完之后发现很多人都很喜欢，我还是非常开心的，也说明这个问题确实困扰了很多人。随着学习的深入，渐渐的感觉原来的理解有些偏差，但是还是没引起自己的重视，觉着都是一些小错误，无伤大雅。直到有位博友问了一个问题，我重新查阅了一些更权威的资料，才发现原来的文章中有很大的理论错误。我不知道有多少人已经看过这篇blog并受到了我的误导，鄙人在此表示抱歉。俺以后写技术blog会更加严谨的。
一度想把原文删了，最后还是没舍得。毕竟每篇blog都花费了不少心血，另外放在那里也可以引以为戒。所以这里新补一篇。算是亡羊补牢吧。
言归正传。
同步（synchronous） IO和异步（asynchronous）
IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分别是什么，到底有什么区别？这个问题其实不同的人给出的答案都可能不同，比如wiki，就认为asynchronousIO和non-blocking
IO是一个东西。这其实是因为不同的人的知识背景不同，并且在讨论这个问题的时候上下文(context)也不相同。所以，为了更好的回答这个问题，我先限定一下本文的上下文。
本文讨论的背景是Linux环境下的network
IO。
本文最重要的参考文献是Richard Stevens的“UNIX® Network ProgrammingVolume 1, Third Edition: The Sockets Networking
”，6.2节“I/OModels ”，Stevens在这节中详细说明了各种IO的特点和区别，如果英文够好的话，推荐直接阅读。Stevens的文风是有名的深入浅出，所以不用担心看不懂。本文中的流程图也是截取自参考文献。
 
Stevens在文章中一共比较了五种IOModel：

    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 theprocess)
记住这两点很重要，因为这些IO
Model的区别就是在两个阶段上各有不同的情况。
 
blockingIO
在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：
当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network
io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段都被block了。
 
non-blockingIO
linux下，可以通过设置socket使其变为non-blocking。当对一个non-blockingsocket执行读操作时，流程是这个样子：
从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system
call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，用户进程其实是需要不断的主动询问kernel数据好了没有。
 
IOmultiplexing
IOmultiplexing这个词可能有点陌生，但是如果我说select，epoll，大概就都能明白了。有些地方也称这种IO方式为eventdriven
IO。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：
当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blockingIO的图其实并没有太大的不同，事实上，还更差一些。因为这里需要使用两个systemcall
(select 和recvfrom)，而blocking IO只调用了一个systemcall
(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。
 
AsynchronousI/O
linux下的asynchronous IO其实用得很少。先看一下它的流程：
用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous
read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。
 
 
到目前为止，已经将四个IO
Model都介绍完了。现在回过头来回答最初的那几个问题：blocking和non-blocking的区别在哪，synchronous
IO和asynchronousIO的区别在哪。
先回答最简单的这个：blocking vs non-blocking。前面的介绍中其实已经很明确的说明了这两者的区别。调用blocking
IO会一直block住对应的进程直到操作完成，而non-blocking
IO在kernel还准备数据的情况下会立刻返回。
在说明synchronousIO和asynchronous
IO的区别之前，需要先给出两者的定义。Stevens给出的定义（其实是POSIX的定义）是这样子的：

    A synchronous I/O operation causes the requesting processto be blocked until that
I/O operation completes;

    An asynchronous I/O operation does not cause the requestingprocess to be blocked;
两者的区别就在于synchronousIO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking
IO，non-blocking IO，IO multiplexing都属于synchronous
IO。有人可能会说，non-blockingIO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IOoperation”是指真实的IO操作，就是例子中的recvfrom这个systemcall。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发个短信。
 

 

 

IO-
同步，异步，阻塞，非阻塞
本文在理论上存在重大错误，个人对所有受到此文误导的朋友表示道歉。新做一篇“IO
- 同步，异步，阻塞，非阻塞（亡羊补牢篇） ”，希望能够得到谅解。
 
 
同步（synchronous） IO和异步（asynchronous）
IO，阻塞（blocking） IO和非阻塞（non-blocking）IO，我相信这几个词困扰过很多人，更痛苦的是，如果你查阅过文献资料，你会发现不同的资料中的解释是不一样的，例如在wiki中，异步和非阻塞被当成了一个概念。
出现这种情况的原因，我认为很大程度上是因为IO这个概念本身就很宽泛，它其实包含了好几个层面。比如说，你可以把它看做是一个物理上的设备，也可以看做是
OS抽象出来的一个软件，还可以看做是平时写程序用的read(),write()函数，不同的层面对于这几个词的理解也是不一样的。

先看一个较低的层次。如果从CPU的角度看，其实大部分的IO都是异步的：因为CPU启动这个IO操作后，就去干其它的事情了，一直到产生一个中断，告诉它IO完成了。
“Mostphysical I/O is asynchronous—the CPU starts the transfer and goes off to dosomething else until the interrupt arrives. User programs are much easier towrite if the I/O operations are blocking—after a read system call
the programis automatically suspended until the data are available in the buffer. It is upto the operating system to make operations that are actually interrupt-drivenlook blocking to the user programs.”
（引自 Modern Operating Systems, 2ed）

不过，本文并不想探究那么底层的东东。作为程序员，更多的还是从应用层面来考虑。所以，以下重点介绍的是应用程序中能够采用的四种IO机制。
（说明，下文中图片引用自http://www.ibm.com/developerworks/cn/linux/l-async/）
首先，从最常用到的，也是最容易理解的同步阻塞IO说起。

在这个模型中，应用程序（application）为了执行这个read操作，会调用相应的一个system
call，将系统控制权交给kernel，然后就进行等待（这其实就是被阻塞了）。kernel开始执行这个system
call，执行完毕后会向应用程序返回响应，应用程序得到响应后，就不再阻塞，并进行后面的工作。

例如，“在调用 read
系统调用时，应用程序会阻塞并对内核进行上下文切换。然后会触发读操作，当响应返回时（从我们正在从中读取的设备中返回），数据就被移动到用户空间的缓冲区中。然后应用程序就会解除阻塞（read
调用返回）。”

 举一个浅显的例子，就好比你去一个银行柜台存钱。首先，你会将存钱的单子填好，然后交给柜员。这里，你就好比是application，单子就是调用的
system call，柜员就是kernel。提交好单子后，你就坐在柜台前等，相当于开始进行等待。柜员办好以后会给你一个回执，表示办好了，这就是
response。然后你就可以拿着回执干其它的事了。注意，这个时候，如果你办完之后马上去查账，存的钱已经打到你的账户上了。后面你会发现，这点很重要。

接下来谈同步非阻塞IO。
先看这个图，

在linux下，应用程序可以通过设置文件描述符的属性O_NONBLOCK，I/O操作可以立即返回，但是并不保证I/O操作成功。
也就是说，当应用程序设置了O_NONBLOCK之后，执行write操作，调用相应的system
call，这个systemcall会从内核中立即返回。但是在这个返回的时间点，数据可能还没有被真正的写入到指定的地方。也就是说，kernel只是很快的返回了这个
system call（这样，应用程序不会被这个IO操作blocking），但是这个system
call具体要执行的事情（写数据）可能并没有完成。而对于应用程序，虽然这个IO操作很快就返回了，但是它并不知道这个IO操作是否真的成功了，如果想知道，需要应用程序主动地去问kernel。

这次不是去银行存钱，而是去银行汇款。同样的，你也需要填写汇款单然后交给柜员，柜员进行一些简单的手续处理就能够给你回执。但是，你拿到回执并不意味着钱已经打到了对方的账上。事实上，一般汇款的周期大概是24个小时，如果你要以存钱的模式来汇款的话，意味着你需要在银行等24个小时，这显然是不现实的。所以，同步非阻塞IO在实际生活中也是有它的意义的。

再来谈谈异步阻塞IO。
在linux中，常常通过select/poll来实现这种机制。
以图为例，
和之前一样，应用程序要执行read操作，因此调用一个systemcall，这个systemcall被传递给了kernel。但在应用程序这边，它调用systemcall之后，并不等待kernel返回response，这一点是和前面两种机制不一样的地方。这也是为什么它被称为异步的原因。但是为什么称其为阻塞呢？这是因为虽然应用程序是一个异步的方式，但是select()函数会将应用程序阻塞住，一直等到这个system
call有结果返回了，再通知应用程序。也就是说，“在这种模型中，配置的是非阻塞I/O，然后使用阻塞
select 系统调用来确定一个 I/O
描述符何时有操作。”
所以，从IO操作的实际效果来看，异步阻塞IO和第一种同步阻塞IO是一样的，应用程序都是一直等到IO操作成功之后（数据已经被写入或者读取），才开始进行下面的工作。异步阻塞IO的好处在于一个select函数可以为多个描述符提供通知，提高了并发性。

关于提高并发性这点，我们还以银行为例说明。比如说一个银行柜台，现在有10个人想存钱。按照现在银行的做法，一个个排队。第一个人先填存款单，然后提交，然后柜员处理，然后给回执，成功后再轮到下一个人。大家应该都在银行排过对，这样的流程是很痛苦的。如果按照异步阻塞的机制，10个人都填好存款单，然后都提交给柜台，提交完之后所有的10个人就在银行大厅等待。这时候会专门有个人，他会了解存款单处理的情况，一旦有存款单处理完毕，他会将回执交给相应的正在大厅等待的人，这个拿到回执的人就可以去干其他的事情了。而前面提到的这个专人，就对应于select函数。

最后，谈谈异步非阻塞IO。
这个概念相对前面两个反而更容易理解一些。
如图所示，应用程序提交read请求的system
call，然后，kernel开始处理相应的IO操作，而同时，应用程序并不等kernel返回响应，就会开始执行其他的处理操作（应用程序没有被IO操作所阻塞）。当kernel执行完毕，返回read的响应，就会产生一个信号或执行一个基于线程的回调函数来完成这次
I/O 处理过程。

比如银行存钱。现在某银行新开通了一项存钱业务。用户之需要将存款单交给柜台，然后无需等待就可以离开了。柜台办好以后会给用户发送一条短信，告知交易成功。这样用户不需要在柜台前进行长时间的等待，同时，也能够得到确切的消息知道交易完成。

从前面的介绍中可以看出，所谓的同步和异步，在这里指的是application和kernel之间的交互方式。如果application不需要等待
kernel的回应，那么它就是异步的。如果application提交完IO请求后，需要等待“回执”，那么它就是同步的。
而阻塞和非阻塞，指的是application是否等待IO操作的完成。如果application必须等到IO操作实际完成以后再执行下面的操作，那么它是阻塞的。反之，如果不等待IO操作的完成就开始执行其它操作，那么它是非阻塞的。

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

我喜欢用自己的语言通过联系现实生活中的一些现象解释一些概念,当我能做到这一点时,说明我已经理解了这个概念.今天要解释的概念是:同步/异步与阻塞/非阻塞的区别.

这两组概念常常让人迷惑,因为它们都是涉及到IO处理,同时又有着一些相类似的地方.

首先来解释同步和异步的概念,这两个概念与消息的通知机制有关.

举个例子,比如我去银行办理业务,可能选择排队等候,也可能取一个小纸条上面有我的号码,等到排到我这一号时由柜台的人通知我轮到我去办理业务了.

前者(排队等候)就是同步等待消息,而后者(等待别人通知)就是异步等待消息.在异步消息处理中,等待消息者(在这个例子中就是等待办理业务的人)往往注册一个回调机制,在所等待的事件被触发时由触发机制(在这里是柜台的人)通过某种机制(在这里是写在小纸条上的号码)找到等待该事件的人.

而在实际的程序中,同步消息处理就好比简单的read/write操作,它们需要等待这两个操作成功才能返回;而异步处理机制就是类似于select/poll之类的多路复用IO操作,当所关注的消息被触发时,由消息触发机制通知触发对消息的处理.

其次再来解释一下阻塞和非阻塞,这两个概念与程序等待消息(无所谓同步或者异步)时的状态有关.

继续上面的那个例子,不论是排队还是使用号码等待通知,如果在这个等待的过程中,等待者除了等待消息之外不能做其它的事情,那么该机制就是阻塞的,表现在程序中,也就是该程序一直阻塞在该函数调用处不能继续往下执行.相反,有的人喜欢在银行办理这些业务的时候一边打打电话发发短信一边等待,这样的状态就是非阻塞的,因为他(等待者)没有阻塞在这个消息通知上,而是一边做自己的事情一边等待.但是需要注意了,第一种同步非阻塞形式实际上是效率低下的,想象一下你一边打着电话一边还需要抬头看到底队伍排到你了没有,如果把打电话和观察排队的位置看成是程序的两个操作的话,这个程序需要在这两种不同的行为之间来回的切换,效率可想而知是低下的;而后者,异步非阻塞形式却没有这样的问题,因为打电话是你(等待者)的事情,而通知你则是柜台(消息触发机制)的事情,程序没有在两种不同的操作中来回切换.

很多人会把同步和阻塞混淆,我想是因为很多时候同步操作会以阻塞的形式表现出来,比如很多人会写阻塞的read/write操作,但是别忘了可以对fd设置O_NONBLOCK标志位,这样就可以将同步操作变成非阻塞的了;同样的,很多人也会把异步和非阻塞混淆,因为异步操作一般都不会在真正的IO操作处被阻塞,比如如果用select函数,当select返回可读时再去read一般都不会被阻塞,就好比当你的号码排到时一般都是在你之前已经没有人了,所以你再去柜台办理业务就不会被阻塞.

可见,同步/异步与阻塞/非阻塞是两组不同的概念,它们可以共存组合,也可以参见这里:
http://www.ibm.com/developerworks/cn/linux/l-async/
----------------------------------------- 分割线 ------------------------------------------------------
昨晚写完这篇文章之后,今早来看了看反馈,同时再自己阅读了几遍,发现还是有一些地方解释的不够清楚,在这里继续补充完善一下我的说法,但愿没有越说越糊涂.

同步和异步:上面提到过,同步和异步仅仅是关于所关注的消息如何通知的机制,而不是处理消息的机制.也就是说,同步的情况下,是由处理消息者自己去等待消息是否被触发,而异步的情况下是由触发机制来通知处理消息者,所以在异步机制中,处理消息者和触发机制之间就需要一个连接的桥梁,在我们举的例子中这个桥梁就是小纸条上面的号码,而在select/poll等IO多路复用机制中就是fd,当消息被触发时,触发机制通过fd找到处理该fd的处理函数.

请注意理解消息通知和处理消息这两个概念,这是理解这个问题的关键所在.还是回到上面的例子,轮到你办理业务这个就是你关注的消息,而去办理业务就是对这个消息的处理,两者是有区别的.而在真实的IO操作时,所关注的消息就是该fd是否可读写,而对消息的处理就是对这个fd进行读写.同步/异步仅仅关注的是如何通知消息,它们对如何处理消息并不关心,好比说,银行的人仅仅通知你轮到你办理业务了,而如何办理业务他们是不知道的.

而很多人之所以把同步和阻塞混淆,我想也是因为没有区分这两个概念,比如阻塞的read/write操作中,其实是把消息通知和处理消息结合在了一起,在这里所关注的消息就是fd是否可读/写,而处理消息则是对fd读/写.当我们将这个fd设置为非阻塞的时候,read/write操作就不会在等待消息通知这里阻塞,如果fd不可读/写则操作立即返回.

很多人又会问了,异步操作不会是阻塞的吧?已经通知了有消息可以处理了就一定不是阻塞的了吧?

其实异步操作是可以被阻塞住的,只不过通常不是在处理消息时阻塞,而是在等待消息被触发时被阻塞.比如select函数,假如传入的最后一个timeout参数为NULL,那么如果所关注的事件没有一个被触发,程序就会一直阻塞在这个select调用处.而如果使用异步非阻塞的情况,比如aio_*组的操作,当我发起一个aio_read操作时,函数会马上返回不会被阻塞,当所关注的事件被触发时会调用之前注册的回调函数进行处理,具体可以参见我上面的连接给出的那篇文章.回到上面的例子中,如果在银行等待办理业务的人采用的是异步的方式去等待消息被触发,也就是领了一张小纸条,假如在这段时间里他不能离开银行做其它的事情,那么很显然,这个人被阻塞在了这个等待的操作上面;但是呢,这个人突然发觉自己烟瘾犯了,需要出去抽根烟,于是他告诉大堂经理说,排到我这个号码的时候麻烦到外面通知我一下(注册一个回调函数),那么他就没有被阻塞在这个等待的操作上面,自然这个就是异步+非阻塞的方式了.