五种IO模型

参考：

• 【操作系统】IO模型篇之从BIO、NIO、AIO到内核select、epoll剖析
• 【操作系统】高性能网络模式：Reactor 和 Proactor

IO 概要

IO基本概念

对于IO知识，想要真正的去理解它，需要结合多线程、网络、操作系统等多方面的知识，IO最开始的定义就是指计算机的输入流和输出流，在这里主体为计算机本身，当然主体也可以是一个程序。

PS：从外部设备（如U盘、光盘等）中读取数据，这可以被称为输入，而在网络中读取一段数据，这也可以被称为输入。

最初的IO流也只有阻塞式的输入输出，但由于时代的不断进步，技术的不停迭代，慢慢的IO也会被分为很多种，接下来咱们聊聊IO的分类。

IO分类

• 工作层面划分

  • 磁盘IO

  • 网络IO

• 工作模式上划分

  • BIO

  • NIO

  • AIO

• 工作性质上划分

  • 阻塞式IO

  • 非阻塞式IO

• 多线程角度划分

  • 同步IO

  • 异步IO

IO原理

无论是Java还是其他的语言，本质上IO读写操作的原理是类似的，编程语言开发的程序，一般都是工作在用户态空间，但由于IO读写对于计算机而言，属于高危操作，所以OS不可能100%将这些功能开放给用户态的程序使用，所以正常情况下的程序读写操作，本质上都是在调用OS内核提供的函数：read()、 write()。 也就是说，在程序中试图利用IO机制读写数据时，仅仅只是调用了内核提供的接口函数而已，本质上真正的IO操作还是由内核自己去完成的。

IO工作的过程如下：

屏幕截图(2)

1. 首先在网络的网卡上或本地存储设备中准备数据，然后调用read()函数。
2. 调用read()函数后，由内核将网络/本地数据读取到内核缓冲区中。
3. 读取完成后向CPU发送一个中断信号，通知CPU对数据进行后续处理。
4. CPU将内核中的数据写入到对应的程序缓冲区或网络Socket接收缓冲区中。
5. 数据全部写入到缓冲区后，应用程序开始对数据开始实际的处理。

在上述中提到了一个CPU中断信号的概念，这其实属于一种I/O的控制方式，IO控制方式目前主要有三种：忙等待方式、中断驱动方式以及DMA直接存储器方式，不过无论是何种方式，本质上的最终作用是相同的，都是读取数据的目的。

在上述IO工作过程中，其实大体可分为两部分：准备阶段和复制阶段，准备阶段是指数据从网络网卡或本地存储器读取到内核的过程，而复制阶段则是将内核缓冲区中的数据拷贝至用户态的进程缓冲区。常听的BIO、NIO、AIO之间的区别，就在于这两个过程中的操作是同步还是异步的，是阻塞还是非阻塞的。

内核态和用户态

用户态与内核态这两个词汇在前面多次提及到，那它两究竟是什么意思呢？先上图：

1653896065386

Linux为了确保系统足够稳定与安全，因此在运行过程中会将内存划分为内核空间与用户空间，其中运行在用户空间的程序被称为“用户态”程序，同理，运行在“内核态”的程序则被称为“内核态”程序，而普通的程序一般都会运行在用户空间。

那么系统为什么要这样设计呢？因为如果内核与用户空间都为同一块儿，此时假设某个程序执行异常导致崩溃了，最终会导致整个系统也出现崩溃，而划分出两块区域的目的就在于：用户空间中的某个程序崩溃，那自会影响自身，而不会影响系统整体的运行。

同时为了防止普通程序去进行IO、内存动态调整、线程挂起等一些高危操作引发系统崩溃，因此这些高危操作的具体执行，也只能由内核自己来完成，但程序中有时难免需要用到这些功能，因此内核也会提供很多的函数/接口提供给外部调用。

当处于用户态的程序调用某个内核提供的函数时，此时由于用户态自身不具备这些函数的执行权限，因此会发生用户态到内核态的切换，也就是说：当程序调用某个内核提供的函数后，具体的操作会切换成内核自己去执行。

1653896687354

但用户态与内核态切换时，由于需要处理操作句柄、保存现场、执行系统调用、恢复现场等等过程，因此状态切换其实也是一个开销较大的动作，因此在设计程序时，要尽量减少会发生状态切换的事项，比如Java中，解决线程安全能用ReetrantLock的情况下则尽量不使用Synchronized。

最后对于用户态和内核态的区别，用大白话来说就是：类似于做程序开发时，普通用户和管理员的区别，为了防止普通用户到处乱点，从而导致系统无法正常运转，因此有些权限只能开放给管理员身份执行，例如删库~

五个IO模型

Linux的五种IO模型浅析（从性能上来说，它们属于依次递进的关系，但越靠后的IO模型实现也越为复杂）

• BIO，同步阻塞模型 (Blocking-IO)
• NIO，同步非阻塞模型 (Non-Blocking-IO)
• 多路复用模型
• 信号驱动模型（事件驱动模型）
• AIO，异步非阻塞模型 (Asynchronous-Non-Blocking-IO)

BIO，同步阻塞模型 (Blocking-IO)

特征：多线程、同步、阻塞

这也是最初的IO模型，也就是当调用内核的read()函数后，内核在执行数据准备、复制阶段的IO操作时，应用线程都是阻塞的，所以本次IO操作则被称为同步阻塞式IO，如下：

1653897115346

流程

• 阶段一：

  • 用户进程尝试读取数据（比如网卡数据）

  • 此时数据尚未到达，内核需要等待数据

  • 此时用户进程也处于阻塞状态

• 阶段二：

  • 数据到达并拷贝到内核缓冲区，代表已就绪

  • 将内核数据拷贝到用户缓冲区

  • 拷贝过程中，用户进程依然阻塞等待

  • 拷贝完成，用户进程解除阻塞，处理数据

1653897270074

当程序中需要进行IO操作时，会先调用内核提供的read()函数，但在之前分析过IO的工作原理，IO会经过“设备→内核缓冲区→程序缓冲区”这个过程，该过程必然是耗时的，在同步阻塞模型中，程序中的线程发起IO调用后，会一直挂起等待，直至数据成功拷贝至程序缓冲区才会继续往下执行。

简单了解了BIO的含义后，那此刻思考一个问题：当本次IO操作还在执行时，又出现多个IO调用，比如多个网络数据到来，此刻该如何处理呢？

很简单，采用多线程实现，包括最初的IO模型也的确是这样实现的，也就是当出现一个新的IO调用时，服务器就会多一条线程去处理，因此会出现如下情况：

image-20230401212536418

在BIO这种模型中，为了支持并发请求，通常情况下会采用“请求：线程”1:1的模型，那此时会带来很大的弊端：

1. 并发过高时会导致创建大量线程，而线程资源是有限的，超出后会导致系统崩溃。
2. 并发过高时，就算创建的线程数未达系统瓶颈，但由于线程数过多也会造成频繁的上下文切换。

image-20230401212851013

在Tomcat中，存在一个处理请求的线程池，该线程池声明了核心线程数以及最大线程数，当并发请求数超出配置的最大线程数时，会将客户端的请求加入请求队列中等待，防止并发过高造成创建大量线程，从而引发系统崩溃。

弊端

弊端很明显, 当有大量的客户端并发时服务端会压力剧增, 同时线程利用率很低。

image-20230426140036779

NIO，同步非阻塞模型 (Non-Blocking-IO)

特征：多线程、异步、非阻塞

从字面意思上来说就是:调用read()函数的线程并不会阻塞，而是可以正常运行，如下：

1653897490116

当应用程序中发起IO调用后，内核并不阻塞当前线程，而是立马返回一个“数据未就绪”的信息给应用程序，而应用程序这边则一直反复轮询去问内核：数据有没有准备好？直到最终数据准备好了之后，内核返回“数据已就绪”状态，紧接着再由进程去处理数据…

具体流程如下：

• 阶段一：

  • 用户进程尝试读取数据（比如网卡数据）

  • 此时数据尚未到达，内核需要等待数据

  • 返回异常给用户进程

  • 用户进程拿到error后，再次尝试读取

  • 循环往复，直到数据就绪

• 阶段二：

  • 将内核数据拷贝到用户缓冲区

  • 拷贝过程中，用户进程依然阻塞等待

  • 拷贝完成，用户进程解除阻塞，处理数据

  • 可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

其实相对来说，这个过程虽然没有阻塞发起IO调用的线程，但实际上也会让调用方不断去轮询发起“数据是否准备好”的信号，这也并非真正意义上的非阻塞。

通过如上的例子，应该能明显感受到这种所谓的NIO相对来说较为鸡肋，因此目前大多数的NIO技术并非采用这种多线程的模型，而是基于单线程的多路复用模型实现的，Java中支持的NIO模型亦是如此。

多路复用模型

特征：单线程、同步、阻塞

I/O 多路复用技术会用一个系统调用函数来监听我们所有关心的连接，也就说可以在一个监控线程里面监控很多的连接。

在理解多路复用模型之前，我们先分析一下上述的NIO模型到底存在什么问题呢？很简单，由于线程在不断的轮询查看数据是否准备就绪，造成CPU开销较大。既然说是由于大量无效的轮询造成CPU占用过高，那么等内核中的数据准备好了之后，再去询问数据是否就绪是不是就可以了？答案是Yes。

那又该如何实现这个功能呢？此时大名鼎鼎的多路复用模型登场了，该模型是基于文件描述符File Descriptor实现的，在Linux中提供了 select、poll、epoll 等一系列函数实现该模型，结构如下：

image-20230401213439953

在多路复用模型中，内核仅有一条线程负责处理所有连接，所有网络请求/连接（Socket）都会利用通道Channel注册到选择器上，然后监听器负责监听所有的连接，过程如下：

• 阶段一：

  • 用户进程调用select，指定要监听的FD集合

  • 核监听FD对应的多个socket

  • 任意一个或多个socket数据就绪则返回readable

  • 此过程中用户进程阻塞

• 阶段二：

  • 用户进程找到就绪的socket

  • 依次调用recvfrom读取数据

  • 内核将数据拷贝到用户空间

  • 用户进程处理数据

1653898691736

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

• select
• poll
• epoll

详见参考：

【操作系统】全面解析IO 多路复用：select、poll、epoll

img

信号驱动模型（事件驱动模式）

特征：单线程、准备异步但处理不异步、准备不阻塞但处理阻塞

信号驱动IO模型(Signal-Driven-IO)是一种偏异步IO的模型，在该模型中引入了信号驱动的概念，在用户进程中首先会创建一个SIGIO信号处理程序，然后基于信号的模型进行处理。

具体流程如下：

• 阶段一：

  • 用户进程调用sigaction，注册信号处理函数

  • 内核返回成功，开始监听FD

  • 用户进程不阻塞等待，可以执行其它业务

  • 当内核数据就绪后，回调用户进程的SIGIO处理函数

• 阶段二：

  • 收到SIGIO回调信号

  • 调用recvfrom，读取

  • 内核将数据拷贝到用户空间

  • 用户进程处理数据

img

在该模型中，首先用户进程中会创建一个Sigio信号处理程序，然后会系统调用sigaction信号处理函数，紧接着内核会直接让用户进程中的线程返回，用户进程可在这期间干别的工作，当内核中的数据准备好之后，内核会生成一个Sigio信号，通知对应的用户进程数据已准备就绪，然后由用户进程在触发一个recvfrom的系统调用，从内核中将数据拷贝出来进行处理。

信号驱动模型相较于之前的模型而言，从一定意义上实现了异步，也就是数据的准备阶段是异步非阻塞执行的，但数据的复制阶段却依旧是同步阻塞执行的。

纵观上述的所有IO模型：BIO、NIO、多路复用、信号驱动，本质上从内核缓冲区拷贝数据到程序缓冲区的过程都是阻塞的，如果想要做到真正意义上的异步非阻塞IO，那么就牵扯到了AIO模型。

AIO，异步非阻塞模型 (Asynchronous-Non-Blocking-IO)

特征：单线程、异步、不阻塞

该模型是真正意义上的异步非阻塞式IO，代表数据准备与复制阶段都是异步非阻塞的。

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

img

在AIO模型中，同样会基于信号驱动实现，在最开始会先调用aio_read、sigaction函数，然后用户进程中会创建出一个信号处理程序，同时用户进程可立马返回执行其他操作，在数据写入到内核、且从内核拷贝到用户缓冲区后，内核会通知对应的用户进程对数据进行处理。

在AIO模型中，真正意义上的实现了异步非阻塞，从始至终用户进程只需要发起一次系统调用，后续的所有IO操作由内核完成，最后在数据拷贝至程序缓冲区后，通知用户进程处理即可。

五种IO模型小结

最后用一幅图，来说明他们之间的区别

屏幕截图(2)

总体上是：多线程到单线程、同步到异步，阻塞非阻塞

（同步和阻塞不完全相等，异步和非阻塞也是。网络IO这里，阻塞主要指当前线程的等待阶段）

• BIO，同步阻塞模型 (Blocking-IO)
  • 多线程、同步、阻塞
• NIO，同步非阻塞模型 (Non-Blocking-IO)
  • 多线程、准备异步但处理不异步、准备不阻塞但处理阻塞
• 多路复用模型
  • 单线程、同步、阻塞
• 信号驱动模型（事件驱动模型）
  • 单线程、准备异步但处理不异步、准备不阻塞但处理阻塞
• AIO，异步非阻塞模型 (Asynchronous-Non-Blocking-IO)
  • 单线程、均异步、均不阻塞

I/O 多路复用：select、poll、epoll

详见参考：

• 【操作系统】全面解析IO 多路复用：select、poll、epoll

最基本的socket模型

要想客户端和服务器能在网络中通信，那必须得使用 Socket 编程，它是进程间通信里比较特别的方式，特别之处在于它是可以跨主机间通信。

select

select是Linux最早是由的I/O多路复用技术：

简单说，就是我们把需要处理的数据封装成FD，然后在用户态时创建一个fd的集合（这个集合的大小是要监听的那个FD的最大值+1，但是大小整体是有限制的 ），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据。

比如要监听的数据，是1,2,5三个数据，此时会执行select函数，然后将整个fd发给内核态，内核态会去遍历用户态传递过来的数据，如果发现这里边都数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看谁准备好了，然后再将处理掉没有准备好的数据，最后再将这个FD集合写回到用户态中去，此时用户态就知道了，奥，有人准备好了，但是对于用户态而言，并不知道谁处理好了，所以吧 用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求，我们会发现，这种模式下他虽然比阻塞IO和非阻塞IO好，但是依然有些麻烦的事情， 比如说频繁的传递fd集合，频繁的去遍历FD等问题

所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。

select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024，只能监听 0~1023 的文件描述符。

poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。

epoll

先复习下 epoll 的用法。如下的代码中，先用e poll_create 创建一个 epol l对象 epfd，再通过 epoll_ctl 将需要监视的 socket 添加到epfd中，最后调用 epoll_wait 等待数据。

epoll 通过两个方面，很好解决了 select/poll 的问题。

我们来梳理一下这张图

1. 服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据。

   • 红黑树（为空）：rb_root 用来去记录需要被监听的FD

   • 链表（为空）：list_head，用来存放已经就绪的FD

2. 创建好了之后，会去调用epoll_ctl函数，此函数会会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)。

3. 当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接时间，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出。

从下图你可以看到 epoll 相关的接口作用：

iocp (windows)