IO模型、阻塞IO和非阻塞IO、同步IO和异步IO

最新推荐文章于 2024-08-05 22:47:24 发布

GoodLinGL

最新推荐文章于 2024-08-05 22:47:24 发布

阅读量183

点赞数

分类专栏：操作系统文章标签：内核设计模式多线程 IO

原文链接：https://blog.csdn.net/qq_34638435/article/details/81878301

版权

操作系统专栏收录该内容

16 篇文章 2 订阅

订阅专栏

IO

1. IO
2. 5种IO模型
3. 两种高性能IO设计模式

1. IO

在这里插入图片描述
IO (Input/Output，输入/输出)即数据的读取（接收）或写入（发送）操作，通常用户进程中的一个完整IO分为两阶段：用户进程空间<–>内核空间、内核空间<–>设备空间（磁盘、网络等）。IO有内存IO、网络IO和磁盘IO三种，通常我们说的IO指的是后两者。

LINUX中进程无法直接操作I/O设备，其必须通过系统调用请求kernel来协助完成I/O动作；内核会为每个I/O设备维护一个缓冲区。

对于一个输入操作来说，进程IO系统调用后，内核会先看缓冲区中有没有相应的缓存数据，没有的话再到设备中读取，因为设备IO一般速度较慢，需要等待；内核缓冲区有数据则直接复制到进程空间。

所以，对于一个网络输入操作通常包括两个不同阶段：

（1）等待网络数据到达网卡→读取到内核缓冲区，数据准备好；

（2）从内核缓冲区复制数据到进程空间。

2. 5种IO模型

5种IO模型分别是阻塞IO模型、非阻塞IO模型、IO复用模型、信号驱动的IO模型、异步IO模型；前4种为同步IO操作，只有异步IO模型是异步IO操作。

2.1 阻塞IO模型

即在读写数据过程中会发生阻塞现象。
在这里插入图片描述
当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。

典型的阻塞IO模型的例子为：

data = socket.read();

如果数据没有就绪，就会一直阻塞在read方法。

特点：

进程阻塞挂起不消耗CPU资源，及时响应每个操作；
实现难度低、开发应用较容易；
适用并发量小的网络应用开发；
不适用并发量大的应用：因为一个请求IO会阻塞进程，所以，得为每请求分配一个处理进程（线程）以及时响应，系统开销大。

2.2 非阻塞IO模型

在这里插入图片描述

当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。

典型的非阻塞IO模型一般如下：


 while(true){ 
            data = socket.read(); 
            if(data!= error){ 
                处理数据 
                break; 
            } 
        }

但是对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。

特点：

进程轮询（重复）调用，消耗CPU的资源；
实现难度低、开发应用相对阻塞IO模式较难；
适用并发量较小、且不需要及时响应的网络应用开发；

2.3 多路复用IO模型

在这里插入图片描述
在多路复用IO模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。

在Java NIO中，多个的进程的IO可以注册到一个复用器（select）上，然后用一个进程调用该select， select会监听所有注册进来的IO；通过selector.select()去查询每个通道是否有到达事件，如果没有事件，则一直阻塞在那里，因此这种方式会导致用户线程的阻塞。如果select没有监听的IO在内核缓冲区都没有可读数据，select调用进程会被阻塞；而当任一IO在内核缓冲区中有可数据时，select调用就会返回。
而后select调用进程可以自己或通知另外的进程（注册进程）来再次发起读取IO，读取内核中准备好的数据。
可以看到，多个进程注册IO后，只有另一个select调用进程被阻塞。

虽然可以采用 多线程+ 阻塞IO 达到类似的效果，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用，并且尤其是对于长连接来说，线程的资源一直不会释放，如果后面陆续有很多连接的话，就会造成性能上的瓶颈。

而多路复用IO模式，通过一个线程就可以管理多个socket，只有当socket真正有读写事件发生才会占用资源来进行实际的读写操作。因此，多路复用IO比较适合连接数比较多的情况。

另外多路复用IO为何比非阻塞IO模型的效率高是因为在非阻塞IO中，不断地询问socket状态是通过用户线程去进行的，而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。

不过要注意的是，多路复用IO模型是通过轮询的方式来检测是否有事件到达，并且对到达的事件逐一进行响应。因此对于多路复用IO模型来说，一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询。

典型应用：select、poll、epoll三种方案，nginx都可以选择使用这三个方案；Java NIO;

特点：

专一进程解决多个进程IO的阻塞问题，性能好；Reactor模式;
实现、开发应用难度较大；
适用高并发服务应用开发：一个进程（线程）响应多个请求；

select、poll、epoll：
Linux中IO复用的实现方式主要有select、poll和epoll：

Select：作用是每次轮询一遍保存好的套接字集合看是否有事件发生（读、写、异常），监听的最大连接数不能多于FD_SIZE；
Poll：原理和Select相似，没有数量限制，原因是它是基于链表来存储的。但IO数量大扫描线性性能下降，当连接的客户端多的时候会产生很大的延迟，因为是每次都轮询的，这个缺点和select一样；
Epoll ：对于一个服务器要是聊天的人一多就会出现严重延迟是绝对不可以的，也就是一个个轮询的方式是费时费力的，那么我们会想办法解决这个问题。epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd）的，不阻塞，mmap实现内核与用户空间的消息传递，数量很大，Linux2.6后内核支持；因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。

详细说明：
于select()函数
这个函数的作用是每次轮询一遍保存好的套接字集合看是否有事件发生（读、写、异常）。
但是因为select每次可以传入的文件描述符集大小只有1024位，所以说这个函数能监听的大小只有1024，至于为什么是1024呢，我们来看看源码对fd_set的定义：

typedef long int __fd_mask;
#define __FD_SETSIZE 1024
#define _NFDBITS (8*(int)sizeof(__fd_mask))

这个是fd_set内的成员，上面有所需宏定义

__fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];

得到的结论是，成员为：long int fds_bits[1024 / __NFDBITS]，long int字节数为x
则该变量字节数为 x*1024/x，即不管64位机还是32位机都是1024位。所以说最多保存1024个文件描述符。

poll函数与select函数的不同则是他不是用这样的压位的方式来保存文件描述符，它采用的结构体如下：

    struct pollfd{
    int fd;///文件描述符
    short int events;///轮询时关心的事件种类，种类在下面给源码
    short int revents;///实际发生的事件
};

事件的定义

#define POLLIN        0x001        /* 有数据要读 */
#define POLLPRI        0x002        /*有紧急数据要读  */
#define POLLOUT        0x004        /*现在写入不会阻塞 */
#define POLLRDNORM    0x040        /* 可以读正常数据*/
#define POLLRDBAND        0x080        /* 可以读取优先数据 */
#define POLLWRNORM    0x100        /* 现在写入不会阻塞  */
#define POLLWRBAND    0x200        /* 可以写入优先数据  */
    /* These are extensions for Linux.  */
#define POLLMSG    0x400    
#define POLLREMOVE    0x1000
#define POLLRDHUP    0x2000这三个是linux的扩展，有兴趣自己去查，注释是源码里的说明
#define POLLERR        0x008        /*错误条件  */
#define POLLHUP        0x010        /* 挂起  */
#define POLLNVAL    0x020        /* 无效轮询请求  */

看了这些宏定义，接下来就是他的用法：
我关心这个对象的读取状态那么 client.events = POLLIN;
我关系读和写的话client.events = POLLIN | POLLOUT;
判断可读 client.revents & POLLIN 为true就是可读；

之前select用的是一个fd_set 这个poll函数则是传入一个pollfd 指针(即可以是数组)进去：

int poll(struct pollfd *fds, unsigned int nfds, int timeout);

第一个刚刚说明过，第二个是最大文件描述符大小+1，第三个是毫秒等待；
这个函数返回：大于零即是发生的事件个数，为零则是超时，-1异常；

这个函数的用法理解了select的用法其实是一样的，当连接的客户端多的时候会产生很大的延迟，因为是每次都轮询的，这个缺点和select一样；select就是将你关心的文件描述符集以及想得到的(读、写、异常)结果集以及等待事件给他，返回给你发生事件的文件描述符的个数，以及(读、写、异常)结果集给你来判断要对该客户端执行何种操作。

2.4 信号驱动IO模型

在信号驱动IO模型中，当用户线程发起一个IO请求操作，会给对应的socket注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号之后，便在信号函数中调用IO读写操作来进行实际的IO请求操作。

特点：回调机制，实现、开发应用难度大；

2.5 异步IO模型

当进程发起一个IO操作，进程返回（不阻塞），但也不能返回结果；内核把整个IO处理完后，会通知进程结果。如果IO操作成功则进程直接获取到数据。

在这里插入图片描述

也就说在异步IO模型中，IO操作的两个阶段都不会阻塞用户线程，这两个阶段都是由内核自动完成，然后发送一个信号告知用户线程操作已完成。用户线程中不需要再次调用IO函数进行具体的读写。这点是和信号驱动模型有所不同的，在信号驱动模型中，当用户线程接收到信号表示数据已经就绪，然后需要用户线程调用IO函数进行实际的读写操作；而在异步IO模型中，收到信号表示IO操作已经完成，不需要再在用户线程中调用iO函数进行实际的读写操作。

特点：

不阻塞，数据一步到位；Proactor模式；
需要操作系统的底层支持，LINUX 2.5 版本内核首现，2.6 版本产品的内核标准特性；
实现、开发应用难度大；
非常适合高性能高并发应用；

前面四种IO模型实际上都属于同步IO，只有最后一种是真正的异步IO，因为无论是多路复用IO还是信号驱动模型，IO操作的第2个阶段都会引起用户线程阻塞，也就是内核进行数据拷贝的过程都会让用户线程阻塞。

3. 两种高性能IO设计模式

在传统的网络服务设计模式中，有两种比较经典的模式：一种是 多线程，一种是线程池。对于多线程模式，也就说来了client，服务器就会新建一个线程来处理该client的读写事件，如下图所示：

这种模式虽然处理起来简单方便，但是由于服务器为每个client的连接都采用一个线程去处理，使得资源占用非常大。因此，当连接数量达到上限时，再有用户请求连接，直接会导致资源瓶颈，严重的可能会直接导致服务器崩溃。

因此，为了解决这种一个线程对应一个客户端模式带来的问题，提出了采用线程池的方式，也就说创建一个固定大小的线程池，来一个客户端，就从线程池取一个空闲线程来处理，当客户端处理完读写操作之后，就交出对线程的占用。因此这样就避免为每一个客户端都要创建线程带来的资源浪费，使得线程可以重用。

但是线程池也有它的弊端，如果连接大多是长连接，因此可能会导致在一段时间内，线程池中的线程都被占用，那么当再有用户请求连接时，由于没有可用的空闲线程来处理，就会导致客户端连接失败，从而影响用户体验。因此，线程池比较适合大量的短连接应用。

因此便出现了下面的两种高性能IO设计模式：Reactor和Proactor。

在Reactor模式中，会先对每个client注册感兴趣的事件，然后有一个线程专门去轮询每个client是否有事件发生，当有事件发生时，便顺序处理每个事件，当所有事件处理完之后，便再转去继续轮询，如下图所示：
在这里插入图片描述
从这里可以看出，上面的五种IO模型中的多路复用IO就是采用Reactor模式。注意，上面的图中展示的是顺序处理每个事件，当然为了提高事件处理速度，可以通过多线程或者线程池的方式来处理事件。

在Proactor模式中，当检测到有事件发生时，会新起一个异步操作，然后交由内核线程去处理，当内核线程完成IO操作之后，发送一个通知告知操作已完成，可以得知，异步IO模型采用的就是Proactor模式。

GoodLinGL

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
IO模型、阻塞IO和非阻塞IO、同步IO和异步IO

IO1. IO2. 5种IO模型2.1 阻塞IO模型2.2 非阻塞IO模型2.3 多路复用IO模型信号驱动IO模型异步IO模型两种高性能IO设计模式1. IOIO (Input/Output，输入/输出)即数据的读取（接收）或写入（发送）操作，通常用户进程中的一个完整IO分为两阶段：用户进程空间<–>内核空间、内核空间<–>设备空间（磁盘、网络等）。IO有内存IO、网络IO和磁盘IO三种，通常我们说的IO指的是后两者。LINUX中进程无法直接操作I/O设备，其必须通过系统调用
复制链接

扫一扫

专栏目录