IO模型-NIO-BIO

最新推荐文章于 2024-04-29 19:18:22 发布

朝上

最新推荐文章于 2024-04-29 19:18:22 发布

阅读量580

点赞数

分类专栏： javaSE 文章标签： javase

本文链接：https://blog.csdn.net/m0_51051154/article/details/122354627

版权

javaSE 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

IO模型

Network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，以下简称用户态，另一个就是系统内核(kernel)，以下简称内核态。

现代操作系统都包括内核空间（Kernel Space）和用户空间（User Space），内核空间主要存放内核代码和数据，是供系统进程使用的空间；而用户空间主要存放的是用户代码和数据，是供用户进程使用的空间。

当一个read操作发生时，它会经历两个阶段：
1）等待数据准备 (Waiting for the data to be ready)
2）将数据从内核拷贝到进程中(Copying the data from the kernel to the process)

一.阻塞IO Blocking IO

在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yPBhF0Rj-1641479992034)(img/Blocking IO.jpg)]

解析图片：

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了。

二.非阻塞IO non-Blocking IO

Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-og6Tc1cE-1641479992035)(img/non-Blocking IO.jpg)]

解析图片：

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error错误码EWOULDBLOCK。从用户进程角度讲，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有。

总结：

非阻塞IO是在应用调用recvfrom读取数据时，如果该缓冲区没有数据的话，就会直接返回一个EWOULDBLOCK错误，不会让应用一直等待中。在没有数据的时候会即刻返回错误标识，那也意味着如果应用要读取数据就需要不断的调用recvfrom请求，直到读取到它数据要的数据为止。

三.多路复用IO multiplexing IO

multiplexing IO这个词可能有点陌生，但是如果我说select/epoll，大概就都能明白了。有些地方也称这种IO方式为事件驱动IO(event driven IO)。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

它的流程如图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-md90CBPL-1641479992035)(img/multiplexing IO.jpg)]

解析图片：

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking IO只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个connection。（多说一句：所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
**所以，在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。**只不过process是被select这个函数block，而不是被socket IO给block。

总结：

复用IO的基本思路就是通过select或poll、epoll 来监控多fd ，来达到不必为每个fd创建一个对应的监控线程，从而减少线程资源创建的目的。

四.信号驱动IO signal driven IO

首先开启套接口信号驱动IO功能，并通过系统调用sigaction执行一个信号处理函数，此时请求即刻返回，当数据准备就绪时，就生成对应进程的SIGIO信号，通过信号回调通知应用线程调用recvfrom来读取数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-72mD4p0c-1641479992036)(img/signal driven IO.jpg)]

解析图片：

信号驱动IO不是用循环请求询问的方式去监控数据就绪状态，而是在调用sigaction时候建立一个SIGIO的信号联系，当内核数据准备好之后再通过SIGIO信号通知线程数据准备好后的可读状态，当线程收到可读状态的信号后，此时再向内核发起recvfrom读取数据的请求，因为信号驱动IO的模型下应用线程在发出信号监控后即可返回，不会阻塞，所以这样的方式下，一个应用线程也可以同时监控多个fd。

总结：

IO复用模型里面的select虽然可以监控多个fd了，但select其实现的本质上还是通过不断的轮询fd来监控数据状态，因为大部分轮询请求其实都是无效的，所以信号驱动IO意在通过这种建立信号关联的方式，实现了发出请求后只需要等待数据就绪的通知即可，这样就可以避免大量无效的数据状态轮询操作。

五.异步IO Asynchronous IO

Linux下的asynchronous IO其实用得不多，从内核2.6版本才开始引入。

先看一下它的流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qJ38AKxN-1641479992036)(img/Asynchronous IO.jpg)]

解析图片：

用户进程发起aio_read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

总结：

异步IO的优化思路是解决了应用程序需要先后发送询问请求、发送接收数据请求两个阶段的模式，在异步IO的模式下，只需要向内核发送一次请求就可以完成状态询问和数据拷贝的所有操作。