I/O基础知识入门

我不是女神ヾ 2022-11-03 15:27 80阅读 0赞

### 前言 ###

在我们开始学习netty之前，我们非常有必要先来简单的了解一下I/O相关的知识，因为netty所有的努力都是基于操作系统对I/O的不断优化和Java对这些能力的不断支持，所以我们在开始学习netty之前一定要先学习一下I/O相关的基础知识  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center]

### 概念解释 ###

#### I/O ####

I/O ： I/O是Input和Output的缩写，意思就是输入/输出，根据操作对象的不同，可以分为内存I/O、磁盘I/O、网络I/O等，和Unix操作系统和Linux操作系统中，所有的组成元素都是一个文件，文件就是一种流的外在表现形式，对这些数据流的读写操作就是IO操作，从这些流中读出数据，系统调用read函数，往这些流中写入数据，系统调用write函数，一个系统中有很多流，我们在操作的时候通过通过文件描述符（File Descriptor）来进行唯一标识

#### 同步与异步 ####

同步与异步 ：同步和异步是我们在接下来的讨论中经常会碰到的两个词，我们首先把这两个词的意思解释清楚：同步表示的是数据请求方从发起请求到最后完成整个数据的拷贝的过程需要自己来请求方自己来完成；异步表示的是数据请求方发起请求指令后就返回，等被请求方将数据处理好之后再通知到数据的请求方，整个数据等待及处理过程都是被请求一方来完成的

#### 阻塞与非阻塞 ####

阻塞与非阻塞 ：阻塞和非阻塞与同步与异步是从两个不同的角度去描述一件事物，并无直接关联，阻塞指的是当我们的用户线程发起一个数据请求，系统内核中的数据还未准备就绪的时候，如果当前用户线程一直等待系统内核准备完毕再返回则表示是阻塞的，如果当前用户线程立刻返回则表示是非阻塞的

#### 文件描述符 ####

文件描述符（File Descriptor）：文件描述符即fd是一个非负整数，打开现存文件或新建一个文件时，内核将会返回一个文件描述符，读写文件也需要通过fd来指定要读写的文件。

#### 轮询 ####

轮询：轮询的英文翻译是Polling，是日常程序中经常用的一种处理方式，通过不断的循环某一个特定的事件，根据事件的不同返回结果，作出相应的处理逻辑，轮询是一个不间断的周而复始是过程，直到通过某种手段强行将该过程中断，在Java中，所谓的死循环就是一种最简单的轮询方案

### 常见I/O模型 ###

#### 阻塞I/O模型【blocking I/O】 ####

阻塞IO模型是所有的IO模型中最简单的，最容易理解的一种IO模型，整个流程都是采用一个线性的处理方式：请求数据 -> 等待数据准备就绪 -> 等待数据拷贝 -> 数据拷贝完成完成，返回结果，但是这种方式有一个非常大的确定，那就是整个过程是处于阻塞状态的，尤其是如果数据准备过程非常长的话，整个进程的阻塞时间也会非常长，严重影响应用处理效率

##### 处理流程 #####

*  应用进程向系统内核发起请求，调用系统函数recvfrom读取数据
 *  系统内核开始准备数据报，当前应用进程处于阻塞状态
 *  系统将数据从内核空间拷贝到应用空间
 *  数据拷贝完成后，recvfrom函数返回成功。

##### 示意图 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 1]

#### 非阻塞I/O模型【noblocking I/O】 ####

知道了上面的阻塞I/O模型，这个就非常好理解啦，在阻塞I/O模型中，应用最主要的是阻塞在数据等待就绪的过程中，这个过程非常不可控，所以我们在非阻塞I/O模型中将该过程从原来的阻塞改成非阻塞状态，这样在数据未准备就绪之前，请求立即返回EWOULDBLOCK错误码，如果数据已经就绪，就开始进行数据拷贝，待数据全部拷贝完成并返回结果，但是这种方式有一个很大的弊端，那就是需要用户进程不断的去轮询调用recvfrom函数来判断数据是否准备就绪，这个过程对CPU的消耗非常大，非常影响系统性能

##### 处理流程 #####

*  应用进程向系统内核发起请求，调用系统函数recvfrom读取数据。
 *  如果系统内核中没有数据报准备好，系统函数recvfrom即刻返回EWOULDBLOCK错误码，
 *  应用进程通过轮询的方式，不断向系统内核发起recvfrom数据请求
 *  当系统内核中有数据包准备完毕了，则进入数据拷贝阶段
 *  系统内核将数据从内核空间拷贝到用户空间，该阶段处于阻塞状态
 *  数据拷贝完成，应用进程发起的recvfrom函数返回成功

##### 示意图 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 2]

#### I/O多路复用模型【I/O multiplexing】 ####

在非阻塞I/O模型的基础上，我们进行了进一步的优化，将原来的整个过程拆分成了两步，将判断系统内核中的数据是否就绪的过程和出发系统内核数据拷贝的过程拆分开来，通过一个专门的阻塞线程去判断一个或多个fd对应的数据是否就绪，只要有任何一个或多个fd数据准备就绪，马上返回给应用进程，应用进程再调用系统中的recvfrom函数来进行数据拷贝，这个过程第一个阶段使用的就是系统中的 select/poll函数，第二阶段还是使用的原来的recvfrom函数，这个过程可以可以通过一个进程来判断和读取多个fd的数据就绪状态，大大节省了为每一个fd判断数据就绪进行的进程的创建、阻塞、销毁

##### 处理流程 #####

*  应用进程想系统内核发起请求，调用系统函数select/poll侦测一个或者多个文件描述符（fd）对应的数据是否准备就绪，当没有任何一个fd对应数据处于就绪状态，则select/poll函数一直处于阻塞状态进行数据等待，当有一个或多个fd对应数据准备就绪后，select/poll函数返回可读状态的fd
 *  应用进程根据系统函数select/poll返回的处于可读状态的fd，有针对性的发起系统函数recvfrom调用请求数据
 *  系统内核接收到应用进程数据请求，开始进行数据拷贝，将数据从内核空间拷贝到应用空间
 *  数据拷贝完成，应用进程发起的recvfrom函数返回成功，应用进程开始下一步的数据处理

##### 示意图 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 3]

#### 信号驱动I/O模型【signal blocking I/O】 ####

I/O多路复用模型解决了一个线程同时监控多个fd的问题，但是select是采用轮询的方式来监控多个fd的，通过不断的轮询fd的可读状态来知道是否就可读的数据，因为大部分情况下的轮询都是无效的，所以在这样的基础上有进一步的做了改进，信号驱动I/O模型就产生啦。信号驱动I/O模型通过调用系统中的sigaction函数建立一个SIGIO的信号联系，当内核数据准备好之后再通过SIGIO信号通知用户进程准备好后的可读状态，当应用进程捕获到可读状态的信号后，再向系统内核调用recvfrom函数发起读取数据的请求，因为信号驱动I/O模型下应用线程在发出信号监控后即可返回，不会阻塞，同时也可以监控多个fd的可读状态。

##### 处理流程 #####

*  应用进程建立SIGIO的信号处理程序，调用系统函数sigaction，向系统内核进行注册，注册完成即返回注册结果
 *  当系统内核中对应的数据报准备就绪后，系统内核会发出应用进程注册的SIGIO信号量，应用进程捕获系统内核发出的SIGIO信号量
 *  应用进程通过调用系统函数recvfrom发起向系统内核的数据请求，系统内核接受到请求后开始将数据从内核空间向应用空间拷贝，该过程进程阻塞
 *  数据拷贝完成，应用进程发起的recvfrom函数返回成功，应用进程开始下一步的数据处理

##### 示意图 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 4]

#### 异步I/O模型【asynchronous I/O】 ####

前面的四种同步I/O模型中，不管是哪一种方式，数据在通过内核空间向应用空间拷贝的这个过程中，用户进程都是阻塞的，产生这个问题的根源是由于触发数据从内核空间向应用空间拷贝的这个行为是应用进程来发起，所以应用进程在整个过程中一定是阻塞的，在这样的基础上，在系统的不断发展过程中，系统层面逐渐具备了直接通过系统内核来触发数据从内核空间向应用空间拷贝的能力，这样，异步I/O模型就应运而生啦。异步I/O的整个思路是将数据拷贝的这整个事情交给系统来做，而不是应用进程，应用进程只是作为整个事情的发起人和最终结果的处理人，对整个过程完全不进行参与，保证了应用进程在整个处理过程的非阻塞。

##### 处理流程 #####

*  应用进程通过调用系统函数aio\_read，向系统内核发起数据请求通知并注册指定信号量，该事件处理完成立即返回
 *  系统内核收到数据请求调用，开始数据的准备以及后续的数据拷贝，当数据准备就绪后，系统内核发出数据拷贝命令，将数据从内核空间向应用空间拷贝，
 *  数据拷贝完成，系统内核发出aio\_read中指定的信号量，应用进程捕获到指定的信号量并进行下一步的数据处理流程

##### 示意图 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 5]

### 总结 ###

#### 阻塞与非阻塞和异步的关系 ####

阻塞与非阻塞都是针对于同步I/O来说的，因为只有在同步I/O需要数据请求发主动去发起数据请求并等待数据准备就绪的这个过程中才会出现阻塞或者非阻塞的情况，而异步I/O发起请求只是通知系统进行数据的准备及处理，然后等待系统的回调，并没有实际参与到这个数据处理过程中，所以不存在阻塞或者非阻塞的情况。

#### 处理效率比较 ####

单纯从理论上来讲的话，不同I/O模型的处理效率是这样排序的：阻塞I/O < 非阻塞I/O < I/O多路复用 < 信号驱动I/O < 异步I/O ，但是在实际环境中，由于异步I/O整体的复杂性和它所带来的效率提高的比例，造成了我们在实际工作中用到的异步I/O并不多，netty在前期支持了异步I/O这种模型，也就是netty中的AIO，但是在后续的更新中逐渐的淘汰了，据说是由于在实际应用场景中发现对处理效率的提高非常有限。

#### 信号驱动I/O模型和异步I/O模型的区别 ####

同步的信号驱动I/O模型和异步I/O模型在整体的设计过程中有很多的相似之处，它们都是通过向系统内核注册信号量的方式来等待系统内核的处理通知的，但是这个里面有一个最大的区别是：数据的拷贝命令的发起人是不同的，信号驱动I/O模型是应用进程收到SIGIO信号后再调用函数recvfrom去触发系统内核中的数据拷贝过程，而且这个拷贝过程中应用进程是阻塞的，但是异步I/O的出发系统内核中的数据拷贝过程是有系统内核直接发起，这个过程对于应用进程来说是无感知的，直到数据拷贝完成才会通过信号量的方式来通知系统进程，这个拷贝的过程对于应用进程来说完全是无阻塞的

#### 不同I/O模型流程比较 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 6]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center]: /images/20221023/7be0e1a28b8d4615890f9cb27219cecf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221023/c798650add7941c08175f25898f1c351.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221023/597593804a4e4ef78f3804f1e76895d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221023/15cb160e56fd4e748e41ca970ddf68dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221023/027dc6b6b7aa424fb8ce0038e7646006.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221023/cd8fb85a6b374e9b92130c806e19f38c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nemVoYWkyMjM0_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221023/f9e05decf08f4f7eaeee72853f8effc2.png