在IO编程一节中，我们已经知道，CPU的速度远远快于磁盘、网络等IO。在一个线程中，CPU执行代码的速度极快，然而，一旦遇到IO操作，如读写文件、发送网络数据时，就需要等待IO操作完成，才能继续进行下一步操作。这种情况称为同步IO。 在IO操作的过程中，当前线程被挂起，而其他需要CPU执行的代码就无法被当前线程执行了。 因为一个IO操作就阻塞了当前线程，导致其他代码无法执行，所以我们必须使用多线程或者多进程来并发执行代码，为多个用户服务。每个用户都会分配一个线程，如果遇到IO导致线程被挂起，其他用户的线程不受影响。 多线程和多进程的模型虽然解决了并发问题，但是系统不能无上限地增加线程。由于系统切换线程的开销也很大，所以，一旦线程数量过多，CPU的时间就花在线程切换上了，真正运行代码的时间就少了，结果导致性能严重下降。 由于我们要解决的问题是CPU高速执行能力和IO设备的龟速严重不匹配，多线程和多进程只是解决这一问题的一种方法。 另一种解决IO问题的方法是异步IO。当代码需要执行一个耗时的IO操作时，它只发出IO指令，并不等待IO结果，然后就去执行其他代码了。一段时间后，当IO返回结果时，再通知CPU进行处理。 可以想象如果按普通顺序写出的代码实际上是没法完成异步IO的： ~~~ do_some_code() f = open('/path/to/file', 'r') r = f.read() # <== 线程停在此处等待IO操作结果 # IO操作完成后线程才能继续执行: do_some_code(r) ~~~ 所以，同步IO模型的代码是无法实现异步IO模型的。 异步IO模型需要一个消息循环，在消息循环中，主线程不断地重复“读取消息-处理消息”这一过程： ~~~ loop = get_event_loop() while True: event = loop.get_event() process_event(event) ~~~ 消息模型其实早在应用在桌面应用程序中了。一个GUI程序的主线程就负责不停地读取消息并处理消息。所有的键盘、鼠标等消息都被发送到GUI程序的消息队列中，然后由GUI程序的主线程处理。 由于GUI线程处理键盘、鼠标等消息的速度非常快，所以用户感觉不到延迟。某些时候，GUI线程在一个消息处理的过程中遇到问题导致一次消息处理时间过长，此时，用户会感觉到整个GUI程序停止响应了，敲键盘、点鼠标都没有反应。这种情况说明在消息模型中，处理一个消息必须非常迅速，否则，主线程将无法及时处理消息队列中的其他消息，导致程序看上去停止响应。 消息模型是如何解决同步IO必须等待IO操作这一问题的呢？当遇到IO操作时，代码只负责发出IO请求，不等待IO结果，然后直接结束本轮消息处理，进入下一轮消息处理过程。当IO操作完成后，将收到一条“IO完成”的消息，处理该消息时就可以直接获取IO操作结果。 在“发出IO请求”到收到“IO完成”的这段时间里，同步IO模型下，主线程只能挂起，但异步IO模型下，主线程并没有休息，而是在消息循环中继续处理其他消息。这样，在异步IO模型下，一个线程就可以同时处理多个IO请求，并且没有切换线程的操作。对于大多数IO密集型的应用程序，使用异步IO将大大提升系统的多任务处理能力。 >[info]评论中网友的辅助理解部分： I/O模型,同步异步,阻塞非阻塞是些概念困扰了我很长时间. 能上图就好了,一图胜千言. 图在UNIX网络编程 第三版 卷1 中文盗版 第六章 图6-6 5种I/O模型的比较 UNIX有5种I/O模型,阻塞会发生在两个阶段上: 1.阻塞式I/O 等待数据时阻塞 数据从内核复制到用户空间时阻塞 2.非阻塞式I/O 等待数据不阻塞,但是轮询会占用cpu资源 数据从内核复制到用户空间时阻塞 3.I/O复用 考虑到轮询占用cpu资源的问题,阻塞在选择器上,减轻处理器负担 将数据从内核复制到用户空间时阻塞 4.信号驱动式I/O 等待数据不阻塞,数据准备好时通知接收数据,将数据从内核复制到用户空间时阻塞 以上四种或多或少均有阻塞现象存在,它们都是同步I/O模型 5.异步I/O 等待数据时不阻塞 将数据从内核复制到用户空间时也不阻塞. 数据到了用户空间以后才发信号,就像你在网上下了订单,快递员拿着你的快件站在你家门口才通知你开门签收的样子. 而在网上下了订单,货物到了离你家最近的自提点,商城通知你去自提点取提货.你专门抽出时间去提货.这是4.信号驱动式I/O.因为在来回自提点的路上你其实是阻塞的.