Linux的五种IO模型？

IO的同步、异步、阻塞、非阻塞

同步、异步

• 同步（synchronous）： A 调用 B, B 立刻处理 A 的请求（即使 C 紧接着调用 B），并把最终结果 返回给 A。
• 异步（asynchronous）：A 调用 B, B 立刻反馈 A, 仅是状态，并非最终结果。B 处理完 A 的请求, 完成后把 最终结果 返回给 A。

关注：<font color='red'>被调用者 B 是否有消息通知（回调函数）机制 把 最终结果 返回给 A。</font>

阻塞、非阻塞

• 阻塞（blocking）：A 调用 B, 在 B 返回结果前，A 会被挂起 （忙等），只有 B 把最终结果 返回给 A, A 才继续处理。
• 非阻塞（non-blocking）：A 调用 B, 在 B 返回结果前，A 不会被挂起 （做其他事情）。

关注：<font color='red'>调用者 A 在等被调用者 B 返回结果前的状态。</font>

IO相关概念

用户空间与内核空间

为保证内核的安全，操心系统将内存空间划分为两部分，一部分为内核内存空间，一部分为用户内存空间。

• 操作系统的核心是内核（kernel），独立于普通的用户进程（application），可以访问受保护的内核内存空间，有访问底层硬件设备（hardware）的所有权限。
• 用户进程（application）只能使用用户内存空间，不能直接操作内核内存空间，没有访问底层硬件设备（hardware）的权限，需要向内核（kernel）发起系统调用（syscall）函数调用，交由内核（kernel）处理。

进程切换

为了控制进程的执行，内核（kernel）必须有能力（通过时钟中断）挂起正在CPU上运行的进程（application），并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。

进程的阻塞

正在运行的用户进程（application），可能因为期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞 （blocking） 状态。

可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。 当进程进入阻塞状态，是不占用CPU资源的。

典型一次IO的两阶段

当一个read操作发生时，涉及到两个系统对象，一个是调用这个IO的process (or thread)，另一个就是系统内核(kernel)，它会经历两个阶段：

• 等待数据准备 (Waiting for the data to be ready)， 即 用户进程（application） 等待 内核（kernel） 操作底层硬件设备（hardware）读取并准备好数据。
• 将数据从内核（kernel）拷贝到用户进程（application）中 (Copying the data from the kernel to the process)

Linux的五种IO模型

在Linux(UNIX)操作系统中，共有五种IO模型，分别是：

• 阻塞IO模型（Blocking I/O）
• 非阻塞IO模型（non-blocking I/O）
• IO复用模型（I/O multiplexing）
• 信号驱动IO模型（signal-driven I/O）
• 异步IO模型（Asynchronous I/O）

阻塞IO模型（Blocking I/O）

Linux操作系统中，这就是一种最简单的IO模型，即阻塞IO。 阻塞 I/O 是最简单的 I/O 模型，一般表现为进程或线程等待某个条件，如果条件不满足，则一直等下去。条件满足，则进行下一步操作。 用户进程（application）通过系统调用 recvfrom 接收数据，但由于内核（kernel）还未准备好数据报，用户进程（application）就会阻塞（blocking）住，直到内核（kernel）准备好数据，并完成数据复制工作，用户进程（application）才能结束阻塞状态。

• 用户进程（application） 在两阶段都是阻塞 （blocking） 状态。
• 内核（kernel）在两阶段都是同步（synchronous）状态。

非阻塞IO模型（non-blocking I/O）

用户进程（application）通过 recvfrom 调用不停的去和内核（kernel）交互，直到内核（kernel）准备好数据。如果没有准备好，内核会返回error，用户进程在得到error后，过一段时间再发送recvfrom请求。在两次发送请求的时间段，进程（application）可以先做别的事情。

• 用户进程（application） 在第一阶段是非阻塞 （non-blocking） 状态, 在第二阶段是阻塞 （blocking） 状态。
• 内核（kernel）在两阶段都是同步（synchronous）状态。

IO复用模型（I/O multiplexing）

多了一个select函数，多个用户进程（application）的IO可以注册到同一个select上，当用户进程（application）调用该select，select会监听所有注册好的IO，如果所有被监听的IO需要的数据都没有准备好时，select调用进程会阻塞。当任意一个IO所需的数据准备好之后，select调用就会返回，然后进程在通过recvfrom来进行数据拷贝。

• 用户进程（application） 在两阶段都是阻塞 （blocking） 状态。
• 内核（kernel）在两阶段都是同步（synchronous）状态。
• 与 阻塞IO模型（Blocking I/O） 的区别在于 它将两阶段 切为两个步骤函数，提高了处理的吞吐率。

信号驱动IO模型（signal-driven I/O）

用户进程（application）预先向内核注册一个信号处理函数，然后用户进程返回，并且不阻塞，当内核（kernel）数据准备就绪时会发送一个信号给进程，用户进程便在信号处理函数中开始把数据拷贝的用户空间中。

• 用户进程（application） 在第一阶段是非阻塞 （non-blocking） 状态, 在第二阶段是阻塞 （blocking） 状态。
• 内核（kernel）在第一阶段都是异步（asynchronous） 状态, 在第二阶段是同步（synchronous）状态。
• 与 非阻塞IO模型（non-blocking I/O） 的区别在于 它提供了消息通知机制，不需要用户进程（application） 定时去检查。

异步IO模型（Asynchronous I/O）

用户进程（application）发起aio_read操作之后，给内核（kernel）传递描述符、缓冲区指针、缓冲区大小等，告诉内核当整个操作完成时，如何通知进程，然后就立刻去做其他事情了。当内核（kernel）收到aio_read后，会立刻返回，然后内核开始等待数据准备，数据准备好以后，直接把数据拷贝到用户空间，然后再通知进程（application）本次IO已经完成。

• 用户进程（application） 在整体阶段是非阻塞 （non-blocking） 状态。
• 内核（kernel）在整体阶段是异步（asynchronous）状态。

横向对比

钓鱼例子：

• 阻塞IO模型（Blocking I/O）：

我们坐在鱼竿面前，这个过程中我们什么也不做，双手一直把着鱼竿，就静静的等着鱼儿咬钩(第一阶段我是阻塞的，鱼竿是同步的)。一旦手上感受到鱼的力道，就把鱼钓起来放入鱼篓（第二阶段我是阻塞的，鱼竿是同步的）中。然后再钓下一条鱼。

• 非阻塞IO模型（non-blocking I/O）：

我们钓鱼的时候，在等待鱼儿咬钩的过程中，我们可以做点别的事情，比如玩一把王者荣耀、看一集《延禧攻略》等等。但是，我们要时不时的去看一下鱼竿，一旦发现有鱼儿上钩了(第一阶段我是非阻塞的，鱼竿是同步的)，就把鱼钓起来放入鱼篓（第二阶段我是阻塞的，鱼竿是同步的）中。然后再钓下一条鱼。

• IO复用模型（I/O multiplexing）

我们钓鱼的时候，为了保证可以最短的时间钓到最多的鱼，我们同一时间摆放多个鱼竿，同时钓鱼。然后哪个鱼竿有鱼儿咬钩了(第一阶段我是阻塞的，鱼竿是同步的)，我们就把哪个鱼竿上面的鱼钓起来放入鱼篓（第二阶段我是阻塞的，鱼竿是同步的）中。然后再钓下一条鱼。

• 信号驱动IO模型（signal-driven I/O）

我们钓鱼的时候，为了避免自己一遍一遍的去查看鱼竿，我们可以给鱼竿安装一个报警器。当有鱼儿咬钩的时候立刻报警(第一阶段我是非阻塞的，鱼竿是异步的)。然后我们再收到报警后，去把鱼钓起来放入鱼篓（第二阶段我是阻塞的，鱼竿是同步的）中。然后再钓下一条鱼。

• 异步IO模型（Asynchronous I/O）

我们钓鱼的时候，采用一种高科技钓鱼竿，即全自动钓鱼竿。可以自动感应鱼上钩，自动收竿，更厉害的可以自动把鱼放进鱼篓里。然后，通知我们鱼已经钓到了，他就继续去钓下一条鱼去了。(两阶段我是非阻塞的，鱼竿是异步的)

最后我们总结：

by 斯武丶风晴 https://my.oschina.net/langxSpirit