1.掌握五种I/O模型的关键钥匙

Unix系统下的五种基本I/O模型大家应该都有所耳闻，分为：

• blocking I/O（同步阻塞IO,BIO）
  
• nonblocking I/O(同步非阻塞IO，NIO)
  
• I/O multiplexing (I/O多路复用)
  
• signal driven I/O（信号驱动I/O）
  
• asynchronous I/O（异步I/O，AIO）
  

每种I/O的特性如何，尤其是同步/非同步、阻塞/非阻塞的区别，其实很多人并不能准确地进行区分。

所以，我们先把最核心的“钥匙”告诉大家，带着这把“钥匙”再来看I/O模型的关键问题，就能手到擒来了。

当一次网络IO发生时，主要涉及到三个对象：

• 发起此次IO操作的Process或者Application
  
• 系统内核kernel。用户进程无法直接操作I/O设备，必须通过系统内核kernel与I/O设备交互。
  
• I/O设备，包括网络、磁盘等。本文主要针对网络。
  

真正的I/O过程，主要分为两个阶段：

• 等待数据准备阶段。
  
• 数据拷贝阶段。数据准备完毕，从内核kernel拷贝到进程process中
  

以一个socket上的输入操作为例。

第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。

第二步就是把数据从内核缓冲区复制到用户态缓冲区。

这里，我们先记住这 两个阶段，掌握所有I/O模型区别的“关键钥匙”就在它们身上。

2.五种I/O模型详解

2.1 同步阻塞I/O, BIO

我们一般使用最多的，最基础的I/O模型就是同步阻塞I/O。

典型应用：

阻塞socket、Java BIO

我们来解读一下BIO的过程：

• 应用进程向内核发起 I/O 请求，发起调用的线程 一直阻塞，等待内核返回结果。
  
• 数据准备完毕，从内核kernel拷贝到用户态内存（仍旧阻塞），然后kernel返回结果，用户进程process结束阻塞，重新运行。

“关键钥匙”分析：

BIO的特点就是在IO执行的 两个阶段 都被 阻塞 了。

所以，我们日常使用BIO模型的时候，提高性能的方式，就是采用 多线程。

在一般的场景中，多线程模型下的BIO是成本较低、收益较高的方式。但是，如果在高并发的场景下，过多的创建线程，会严重占据系统资源，降低系统对外界响应效率。

那是不是可以考虑使用“线程池”或者“连接池”呢？

一定程度上可以。“池化”的目的在于减少创建和销毁线程的频率，让空闲的线程重新承担新的执行任务，维持一个合理的线程数量，可以很好的降低系统开销。

但是，“池化”技术只能一定程度上缓解了频繁调用IO接口带来的资源占用。如果“池”上限100，而我们需要1000的IO，那并不能解决性能问题，这是由于BIO模型本身的限制决定的。

所以，需要非阻塞I/O来尝试解决这个问题。

2.2 同步非阻塞I/O, NIO

BIO的阻塞问题，让我们考虑使用非阻塞的NIO模型。

典型应用：

socket的非阻塞模式

应用进程向内核发起 I/O 请求后，如果kernel中的数据还没有准备好，不再会“阻塞”等待结果，而是会立即返回。

从用户进程角度讲 ，它发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。

用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它开始发起轮训操作。

直到kernel中的数据准备好了，一旦用户再轮训过来，就马上将数据拷贝到了用户内存，然后返回。

所以，在非阻塞式IO中，用户进程其实是需要不断地主动询问kernel数据准备好了没有。

“关键钥匙”分析：

非阻塞NIO模型相比于BIO的显著差异在于，在“数据等待”阶段，不再“阻塞”，立即返回。

但是在“数据拷贝”阶段，仍然是“阻塞”的。

虽然非阻塞模型避免了“数据等待”阶段的阻塞，但是，采用轮询方式，会导致系统上下文切换开销很大，会大幅度推高CPU 占用率。

因此，单独使用非阻塞 I/O 模型的效率并不高。而且随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。

我们可以看到，轮训的目的只是检测“数据是否已经就绪”，而操作系统提供了更为高效的检测接口，

例如select()多路复用模式，可以一次检测多个连接是否活跃。

2.3 多路复用IO

多路复用实现了一个线程处理多个 I/O 句柄的操作，有些地方也称这种IO方式为事件驱动IO(event driven IO)。

• 多路 指的是多个数据通道
  
• 复用 指的是使用一个或多个固定线程来处理每一个 Socket。

典型应用：

select、poll、epoll三种方案

Java NIO

多个的进程的IO可以注册到一个复用器（selector）上，然后用一个进程调用select，select会监听所有注册进来的IO。

如果selector所有监听的IO在内核缓冲区都没有可读数据，select调用进程会被阻塞；同时，kernel会“监视”所有select负责的socket，如果任何一个socket中的数据准备好了，select就会返回；

然后select调用进程可以自己或通知另外的进程（注册进程）来再次发起读取IO，然后process将数据从kernel拷贝到用户进程，读取内核中准备好的数据。

可以看到，多个进程注册IO后，只有一个select调用进程被阻塞。

多路复用解决了同步阻塞 I/O 和同步非阻塞 I/O 的问题，是一种非常高效的 I/O 模型。我们可以直观看到，这个模型的好处在于单个process就可以同时处理多个网络连接的IO。

“关键钥匙”分析：

多路复用I/O，select阶段，对于多路socket的“数据等待”阶段而言，是“非阻塞”。

对单个socket的“数据拷贝”阶段，也是“阻塞”。

这里需要特别注意！！！！

其实如果处理的IO数不多的情况下，使用多路复用IO的web server不一定比使用 池化+BIO 的web server性能更好，可能延迟还更大。

考虑极端情况下，只有一个IO，多路复用需要 2 次系统调用（select + recvfrom），而BIO只需要 1 次系统调用（recvfrom）。

所以，多路复用IO的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

2.4 信号驱动I/O

在使用信号驱动 I/O 时，当数据准备就绪后，内核通过发送一个 SIGIO 信号通知应用进程，应用进程就可以开始读取数据了。

信号驱动I/O模型的最大特点，就是不需要process进程不断轮训内核是否已经准备就绪。

“关键钥匙”分析：

信号驱动I/O在"数据等待"阶段“非阻塞”。

当数据准备完成后，信号通知process，process开始“数据拷贝”阶段，这里仍然是“阻塞”的。

信号驱动 I/O 有几个缺陷：

1）在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

2）信号驱动 I/O 尽管对于处理 UDP 套接字来说有用，信号通知意味着到达一个数据报，或者返回一个异步错误。

但是，对于 TCP 而言，信号驱动的 I/O 方式不太好用。因为导致信号通知的情况有非常多种，每一个来进行判别会消耗很大资源。

所以信号驱动I/O模式用得非常少。

而且尤其需要注意，在“数据拷贝”阶段，它仍然是“阻塞”的。

2.5 异步I/O，AIO

真正的异步I/O，就是AIO。

典型应用：

JAVA7 AIO、高性能服务器

根据前面四个模型的分析，相信大家已经能明显看懂这个模型的运行方式了。

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

AIO最重要的一点是 从内核缓冲区拷贝数据到用户态缓冲区的过程也是由系统异步完成，应用进程只需要在指定的数组中引用数据即可。

AIO 与信号驱动 I/O 的主要区别：

信号驱动 I/O 由内核通知何时可以开始一个 I/O 操作，而异步 I/O 由内核通知 I/O 操作何时已经完成。

“关键钥匙”分析：

"数据等待"阶段，非阻塞

"数据拷贝”阶段，非阻塞

AIO是真正的异步模型，它不会对请求进程产生任何的阻塞。

3. 同步=阻塞？异步=非阻塞？

日常使用过程中，我们往往把 同步I/O 等同于 阻塞I/O，异步I/O 等同于 非阻塞I/O。

实际上，严格意义来说，这两组概念还是有很大的区别的。

3.1 阻塞I/O 与 非阻塞I/O

阻塞与非阻塞的区别比较明显，也很好理解。

结合I/O模型来说，阻塞I/O会一直block对应的进程直到操作完成，而非阻塞 IO在kernel 在"等待数据准备"阶段会立刻返回。

所以我们一般认为，阻塞I/O只有BIO，另外四个模型都是属于非阻塞I/O。

3.2 同步I/O 与 异步I/O

先来看看 同步I/O 和 异步I/O 的定义是什么，根据POSIX的定义：

• 同步I/O : A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
  
• 异步I/O : An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于同步I/O做 "IO operation”的时候会将process阻塞。

那么按照这个定义，我们看看前面每个模型的“关键钥匙”分析部分，可以明显看到，BIO，NIO，IO多路复用、信号驱动IO 四种模型都属于 同步IO。

因为它们在IO的第二阶段，真正执行“数据拷贝”的阶段，都是“阻塞”的。以NIO为例，在执行recvfrom这个系统调用的时候，如果kernel的数据没有准备好，这时候不会block进程。但是当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了。

同理，信号驱动IO，当内核中IO数据就绪时以SIGIO信号通知请求进程，请求进程再把数据从内核读入到用户空间，这一步也是阻塞的。

所以，真正的异步I/O只有一个，就是AIO。当进程发起IO操作之后，就直接返回再也不管了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被阻塞。如定义所说，不会因为IO操作阻塞。

4. Netty采用了哪种I/O模型呢？

Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 JDK NIO 框架的多路复用器 Selector。

一个多路复用器 Selector 可以同时轮询多个 Channel，采用 epoll 模式后，只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。

更具体的实现方式和模型，我们下一期再展开说明。

对了，一定有同学想问，Netty为什么不采用AIO呢？

因为 AIO 的目的是希望 I/O 线程不阻塞主线程，属于异步 I/O，由内核通知 I/O 操作何时完成。AIO 适用于连接数多的且需要长时间连接的场景。

对于AIO来说，目前操作系统支持程度有限且实现起来复杂。

Netty也尝试过AIO，但是效果不是很理想，最终废弃了。

参考书目：

《UNIX Network Programming(Volume1,3rd)》