IO-同步，异步，阻塞，非阻塞，阅读摘要

http://www.cnblogs.com/Fly-Wind/p/io.html

http://blog.csdn.net/historyasamirror/article/details/5778378

经过上面的介绍，会发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而asynchronous IO则完全不同。它就像是用户进程将整个IO操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据。

总算是把block和同步异步这两个概念理清楚了，读完之后个人的一点总结：判断是否是block的依据是用户进程是否block在等待数据阶段，判断是同步还是异步的依据是把数据从内核态复制到用户态是内核主动还是用户进程主动。

先给楼主点个赞，辛苦了。对于同步的异步理解起来还是比较容易，就和使用js里面的AJAX时是一个道理，但是对于阻塞和非阻塞理解起来稍微有点困难，我看了几遍结合自己的理解说一下，所谓的阻塞和非阻塞是操作系统中的一个定义，如果是阻塞式的IO，那么操作系统会将这个IO操作所在的进程或者线程进行阻塞，夺去它的CPU执行权，而非阻塞式的IO由于在读的过程中一直有信息反馈，所以我需要用一个轮询去判断是否真的读取完毕，所以操作系统不会夺去它的CPU执行权。从另一个角度来说的话阻塞式IO可能会造成频繁的上下文切换，而非阻塞式IO会占用CPU时间过长，是一种CPu的浪费。

To 楼主：select/epoll是不好和多线程简单比较优势的。这个里面有很多原因。多线程编码复杂，debug相对比较困难。linux历史上线程的性能不是太好（相对其他OS上的线程）。为了降低多线程编码维护的复杂度，linux里是鼓励多用IO multiplexing的。可以看看X server（使用的IO multiplexing）的性能如何。

回复hit_fantasy： 个人理解，希望对你有帮助（当然可能有误）：异步有一个很明显的特征，就是内核向用户层发送读成功的“消息”（用户进程只有一个启动io系统调用，之后去忙其他事情，内核完成拷贝后通过消息向该进程说“搞定了”）。而非异步的操作，需要程序自己通过系统调用去告诉内核接下来做什么（1.select 获取可读的fd，2,read 将数据从内核层拷贝到用户层）