网络中的数据（阻塞篇）IO的阻塞与非阻塞，同步与异步，IO复用

系统管理员 2021-01-26 04:40 714阅读 0赞

首先引入大佬们对此的理解

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70][]

另一种理解

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70 1][]

首先是对阻塞和非阻塞的理解，阻塞是指专心只做当前一件事，及时是等待好久一段时间去拿到结果，这段时间什么也不能做，而且等待的这段时间对最终结果毫无影响，等到拿到了结果，才能去做下一件事，而非阻塞，就灵活多了，你可以在等待的时间里去做其他事，但是你需要在一定间隔内去咨询结果 是否出来。

第一个例子和第二个例子的场景1,2,3无论是阻塞还是非阻塞都需要不断轮询，及时你是隔一段时间去问出结果了没还是你委托第三方去问出结果了没，这属于同步，因为，只有一个线程在执行你的事情，而异步就属于，你在你的线程里开辟了另外一条线程去执行事件a，当事件a完成后会通知你结果（类似回调函数），而你在你的线程里只需要下达命令执行事件a，然后就可以干其他事了，等a有了结果会通知你的。

需要注意一点的是，即使委托了第三方，第三方也是阻塞的，因为第三方会一直等待结果，不过因为第三方和你不属于同一线程，不会影响你做其他事情。

看完了生动的例子，看一下官方点的总结

Buffer:

》 是一块连续的内存块。

》 是 NIO 数据读或写的中转地。

Channel:

》 数据的源头或者数据的目的地

》 用于向 buffer 提供数据或者读取 buffer 数据 ,buffer 对象的唯一接口。

》 异步 I/O 支持

Buffer作为IO流中数据的缓冲区，而Channel则作为socket的IO流与Buffer的传输通道。客户端socket与服务端socket之间的IO传输不直接把数据交给CPU使用，

而是先经过Channel通道把数据保存到Buffer，然后CPU直接从Buffer区读写数据，一次可以读写更多的内容。

使用Buffer提高IO效率的原因（这里与IO流里面的BufferedXXStream、BufferedReader、BufferedWriter提高性能的原理一样）：IO的耗时主要花在数据传输的路上，普通的IO是一个字节一个字节地传输，

而采用了Buffer的话，通过Buffer封装的方法（比如一次读一行，则以行为单位传输而不是一个字节一次进行传输）就可以实现“一大块字节”的传输。比如：IO就是送快递，普通IO是一个快递跑一趟，采用了Buffer的IO就是一车跑一趟。很明显，buffer效率更高，花在传输路上

的时间大大缩短。

IO--multiplexing多路复用

如果一个I/O流进来，我们就开启一个进程处理这个I/O流。那么假设现在有一百万个I/O流进来，那我们就需要开启一百万个进程一一对应处理这些I/O流（——这就是传统意义下的**多进程并发处理**）。思考一下，一百万个进程，你的CPU占有率会多高，这个实现方式及其的不合理。所以人们提出了I/O多路复用这个模型，**一个线程，通过记录I/O流的状态来同时管理多个I/O，可以提高服务器的吞吐能力**。

可以用第一个场景去理解，这个黄牛专心抢票，可以同时帮多个人抢票，所以一个线程可以管理同一类IO，也可以说同一类IO可以复用同一个线程（个人理解）

![11319096-c3fd7c0bf3904dfa.png][]

我们来分析一下上面这张图

1.  当进程调用select，进程就会被阻塞
2.  此时内核会监视所有select负责的的socket，当socket的数据准备好后，就立即返回。
3.  进程再调用read操作，数据就会从内核拷贝到进程。

**select函数的调用过程**

**（fd\_set描述文件的结构体）**

a. 从用户空间将fd\_set**拷贝**到内核空间  
b. 注册回调函数  
c. 调用其对应的poll方法  
d. poll方法会返回一个描述读写是否就绪的mask掩码，根据这个mask掩码给fd\_set赋值。  
e. 如果遍历完所有的fd都没有返回一个可读写的mask掩码，就会让select的进程进入休眠模式，直到发现可读写的资源后，重新唤醒等待队列上休眠的进程。如果在规定时间内都没有唤醒休眠进程，那么进程会被唤醒重新获得CPU，再去遍历一次fd。  
f. 将fd\_set从内核空间**拷贝**到用户空间

**缺点**：两次拷贝耗时、轮询所有fd耗时，支持的文件描述符太小  
**优点**：跨平台支持

**poll函数的调用过程和select完全一致**

**优点**：连接数（也就是文件描述符）没有限制（链表存储）  
**缺点**：大量拷贝，水平触发（当报告了fd没有被处理，会重复报告，很耗性能）

**epoll的函数调用流程**

a. 当调用epoll\_wait函数的时候，系统会创建一个epoll对象，每个对象有一个evenpoll类型的结构体与之对应，结构体成员结构如下。

> **rbn,代表将要通过epoll\_ctl向epoll对象中添加的事件**。这些事情都是挂载在红黑树中。  
> **rdlist，里面存放的是将要发生的事件**

b. 文件的fd状态发生改变，就会触发fd上的回调函数  
c. 回调函数将相应的fd加入到rdlist，导致rdlist不空，进程被唤醒，epoll\_wait继续执行。  
d. 有一个事件转移函数——ep\_events\_transfer，它会将rdlist的数据拷贝到txlist上，并将rdlist的数据清空。  
e. **ep\_send\_events函数**，它扫描txlist的每个数据，调用关联fd对应的poll方法去取fd中较新的事件，将取得的事件和对应的fd发送到用户空间。如果fd是LT模式的话，会被txlist的该数据重新放回rdlist，等待下一次继续触发调用

epoll的优点

1.  没有最大并发连接的限制
2.  只有活跃可用的fd才会调用callback函数
3.  内存拷贝是利用mmap()文件映射内存的方式加速与内核空间的消息传递，减少复制开销。（内核与用户空间共享一块内存）

只有存在大量的空闲连接和不活跃的连接的时候，使用epoll的效率才会比select/poll高

**事件多路分离器(Event Demultiplexer)**

一般地,I/O多路复用机制都依赖于一个事件多路分离器(Event Demultiplexer)。分离器对象可将来自事件源的I/O事件分离出来，并分发到对应的read/write事件处理器(Event Handler)。开发人员预先注册需要处理的事件及其事件处理器（或回调函数）；

事件分离器负责将请求事件传递给事件处理器。两个与事件分离器有关的模式是Reactor和Proactor。Reactor模式采用同步IO，而Proactor采用异步IO。

首先来看看Reactor模式，Reactor模式应用于同步I/O的场景。我们分别以读操作和写操作为例来看看Reactor中的具体步骤：

读取操作：

1. 应用程序注册读就绪事件和相关联的事件处理器

2. 事件分离器等待事件的发生

3. 当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器

4. 事件处理器首先执行实际的读取操作，然后根据读取到的内容进行进一步的处理

写入操作类似于读取操作，只不过第一步注册的是写就绪事件。

下面我们来看看Proactor模式中读取操作和写入操作的过程：

读取操作：

1. 应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键。

2. 事件分离器等待读取操作完成事件

3. 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作（异步IO都是操作系统负责将数据读写到应用传递进来的缓冲区供应用程序操作，操作系统扮演了重要角色），并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点，Proactor中，应用程序需要传递缓存区。

4. 事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作。

Proactor中写入操作和读取操作，只不过感兴趣的事件是写入完成事件。

**从上面可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的IO设备.**

**         综上所述，同步和异步是相对于应用和内核的交互方式而言的，同步 需要主动去询问，而异步的时候内核在IO事件发生的时候通知应用程序，而阻塞和非阻塞仅仅是系统在调用系统调用的时候函数的实现方式而已**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70]: /images/1611635999409.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTQzNjM0_size_16_color_FFFFFF_t_70 1]: /images/1611635988018.png
[11319096-c3fd7c0bf3904dfa.png]: /images/1611635975359.png