IO会一直占用CPU吗？一个很好的关于并发/并行系统的问题（转）

这是一个很好的关于并发/并行系统的问题。简单回答就是：IO所需要的CPU资源非常少。大部分工作是分派给DMA（Direct Memory Access）直接内存存取 完成的。

先不谈传统的5大IO模型，先说说并发（Concurrencey）。一个非常不严谨的解释就是同时做A和B两件事。先做一会儿进程A，然后上下文切换，再做一会儿B。过一会儿在切回来继续做A。因此给我们造成一个假象，我们同时在做A和B两件事。这就是著名的进程模型。

这看上去很炫酷，但实际上并没有任何卵用。因为A，B两件事你都得做完不是？不论你是做完A再做B还是来回切换，花得时间应该是一样的。甚至还要更多，因为还要考虑到上下文切换的开销。所以我第一次学到并发进程模型的时候，心里是一万个白眼。（深有同感）

但是，如果计算机内部不止CPU一个部件在工作呢？如果A这件事CPU可以分派给其他部件帮它完成呢？情况是不是就完全不一样了？系统IO正好是这样一个完美的例子。

对于磁盘IO，真实发生的场景可能是这样的：

CPU说：硬盘兄帮我把我要看的小电影拷贝一份到主存，谢谢，亲。
硬盘说：好的！我考完了叫你。
CPU说：么么哒！那我打游戏去啦！
...
CPU打撸啊撸 （100纳秒过去了）
...
硬盘说：小C我考完了。
CPU说：苍老师我来啦！

当然我们也可以到网上下载苍老师的作品，这就是网络IO。但情况基本是一样的，CPU童鞋在等小电影的过程中，打了一局撸啊撸。

所以，正因为这样派发任务，通讯，等待的过程，并发系统才彰显出它的意义。当然实际过程可能比这个复杂一万倍。比如CPU是不会直接和硬盘对话的，他们之间有个中间人，叫DMA（Direct Memory Access）芯片

CPU计算文件地址 ——> 委派DMA读取文件 ——> DMA接管总线 ——> CPU的A进程阻塞，挂起——> CPU切换到B进程 ——> 
DMA读完文件后通知CPU（一个中断异常）——> CPU切换回A进程操作文件

这个过程，对应下图（图源：《UNIX网络编程》），看到application这一列时间线了吗？aio_read操作之后，都是空白，CPU就不管了，可以做其他事去了。

假设原先读取文件CPU需要傻等50纳秒。现在尽管两次上下文切换要各消耗5纳秒。CPU还是赚了40纳秒时间片。一看上面这张图就知道，刚才讲的是传统5大IO模型中的“异步IO”的大致过程。想进一步了解，推荐直接读《UNIX网络编程》第一册套接字，经典哦！
虽然IO不会占用大量的CPU时间，但是非常频繁的IO还是会非常浪费CPU时间的，所以面对大量IO的任务，有时候是需要算法来合并IO，或者通过cache来缓解IO压力的。