Unix5种IO模型

Posted 2021-04-25 架构师成长

unix提供了5种IO模型

1、阻塞IO

2、非阻塞IO

3、IO多路复用

4、信号量

5、异步IO

1. 阻塞IO

recvfrom函数为系统调用函数，从图中可以看出，从进行系统调用到拷贝数据到应用进程缓冲区完成，整段时间都是被阻塞的，在这个过程中要么正确到达，要么系统调用被打断；直到数据报被拷贝到用户进程后，用户才解除阻塞状态，这里的用户进程是自己进行阻塞，拷贝也是有用户进行完成。在等待数据待处理数据的两个阶段，整个进程都是被阻塞的，不能处理别的网络IO，调用应用程序处于一种不在消费CPU而只是简单等待响应的状态。

2. 非阻塞IO

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，，那么他并不会block用户进程，而是立马返回一个error，从用户角度来讲，他发起一个read操作后，并不需要等待，而是马上等到一个结果，用户进程判断是一个error时，他就知道数据换没有准备好，于是它再次发送read操作，一旦kermel中的数据准备好了，并且再次收到了用户进程的read，那么他此时就会将数据拷贝到用户内存，然后返回。所以用户的第一个阶段不是阻塞的，需要不断的主动问kernel数据好了没；第二阶段依然总体是阻塞的。

3. IO多路复用（NIO）

select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。java 中Selector。当有fd读写事件时，整个线程会阻塞，当有多个线程同时有读写事件时，fd读写过程是阻塞的。AIO读写过程是独立线程，可以解决这个问题。

IO复用和同步阻塞本质一样，不过利用了新的select系统调用，由内核来负责本来是请求进程该做的轮询操作，看似非阻塞IO还多了一个系统调用开销，不过因为支持多路IO才算提高了效率。也就是一个可以监听多个。它的基本原理就是select /epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户线程调用select，那么整个进程会被阻塞，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回，这个时候用户进程在调用read操作，将数据kernel拷贝到用户进程。

4. 信号驱动IO：

首先开启套接字的信号驱动式IO功能，并且通过sigaction(信号处理程序) 系统调用安装一个信号处理函数 ，该函数调用将立即返回，当前进程没有被阻塞 ，继续工作；当数据报准备好的时候，内核为该进程产生SIGIO 的信号，随后既可以在信号处理函数中调用recvfrom 读取数据报，并且通知主循环数据已经准备好等待处理；也可以直接通知主循环让它读取数据报；(其实就是一个待读取的通知和待处理的通知)，基本不会用到。

5. 异步IO（AIO）

多线程和多进程的模型虽然解决了并发的问题，但是系统不能无限的增加线程，由于系统的切换线程的开销恒大，所以，一旦线程数量过多，CPU的时间就花在线程的切换上，正真运行代码的时间就会减少，结果导致性能严重下降。由于我们要解决的问题是CPU高速执行能力和IO设备的龟速严重不匹配，多线程和多进程只是解决这一个问题的一种方法。另一种解决IO问题的方法是异步IO，当代码需要执行一个耗时的IO操作时，他只发出IO指令，并不等待IO结果然后就去执行其他代码，一段时间后，当IO返回结果时，再通知CPU进行处理调用aio_read函数，给内核传递描述符，缓冲区指针，缓冲区大小，和文件偏移量，并且告诉内核当整个操作完成时如何通知我们，该函数调用后，立即返回，不会被阻塞。

另一方面：从kernel的角度，当他收到一个aio_read之后，首先它立即返回，所以不会对用户进程产生block，然后kernel会等待数据准备完成，然后将数据拷贝到用户内存（copy由内核完成），当着一切完成后，kernel会给用户进程发送一个singal或者执行下一个基于线程回调函数来完成此次IO处理过程，告诉他read操作完成。

异步IO的拷贝是有内核完成， 其他几种IO都是由用户进程完成。