BIO NIO AIO之间的区别与联系

前言

1. 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）

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

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

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

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

以一个socket上的输入操作为例:
第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。
第二步就是把数据从内核缓冲区复制到用户态缓冲区。

五种I/O模型

1.同步阻塞I/O, BIO

1. 我们一般使用最多的，最基础的I/O模型就是同步阻塞I/O。
   典型应用：阻塞socket、Java BIO
   

2. BIO的过程：

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

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

3. 为了提高性能，常见的优化方式就是采用多线程
   在一般的场景中，多线程模型下的BIO是成本较低、收益较高的方式。但是，如果在高并发的场景下，过多的创建线程，会严重占据系统资源，降低系统对外界响应效率。“池化”的目的在于减少创建和销毁线程的频率，让空闲的线程重新承担新的执行任务，维持一个合理的线程数量，可以很好的降低系统开销。但是，“池化”技术只能一定程度上缓解了频繁调用IO接口带来的资源占用。如果“池”上限100，而我们需要1000的IO，那并不能解决性能问题，这是由于BIO模型本身的限制决定的。

2.同步非阻塞I/O, NIO

典型应用：socket的非阻塞模式

1. 过程
   应用进程向内核发起 I/O 请求后，如果kernel中的数据还没有准备好，不再会“阻塞”等待结果，而是会立即返回。从用户进程角度讲 ，它发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它开始发起轮训操作。直到kernel中的数据准备好了，一旦用户再轮训过来，就马上将数据拷贝到了用户内存，然后返回。所以，在非阻塞式IO中，用户进程其实是需要不断地主动询问kernel数据准备好了没有。

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

2. 虽然非阻塞模型避免了“数据等待”阶段的阻塞，但是，采用轮询方式，会导致系统上下文切换开销很大，会大幅度推高CPU 占用率。因此，单独使用非阻塞 I/O 模型的效率并不高。而且随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。我们可以看到，轮训的目的只是检测“数据是否已经就绪”，而操作系统提供了更为高效的检测接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。

3.多路复用IO

1. 多路复用实现了一个线程处理多个 I/O 句柄的操作，有些地方也称这种IO方式为事件驱动IO(event driven IO)。多路指的是多个数据通道，复用指的是使用一个或多个固定线程来处理每一个 Socket。
   典型应用：select、poll、epoll三种方案
   Java NIO
   

2. 过程
   多个的进程的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的“数据拷贝”阶段，也是“阻塞”。

3. 注意
   如果处理的IO数不多的情况下，使用多路复用IO的web server不一定比使用 池化+BIO 的web server性能更好，可能延迟还更大。
   考虑极端情况下，只有一个IO，多路复用需要 2 次系统调用（select + recvfrom），而BIO只需要 1 次系统调用（recvfrom）。
   所以，多路复用IO的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

4.信号驱动I/O

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

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

信号驱动I/O在"数据等待"阶段“非阻塞”。当数据准备完成后，信号通知process，process开始“数据拷贝”阶段，这里仍然是“阻塞”的。

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

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

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

  但是，对于 TCP 而言，信号驱动的 I/O 方式不太好用。因为导致信号通知的情况有非常多种，每一个来进行判别会消耗很大资源。
  所以信号驱动I/O模式用得非常少。而且尤其需要注意，在“数据拷贝”阶段，它仍然是“阻塞”的。

5.异步I/O，AIO

1. 真正的异步I/O，就是AIO。
   典型应用：JAVA7 AIO、高性能服务器
   

2. 过程
   用户进程发起I/O请求后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它收到一个请求之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它I/O操作完成了。AIO最重要的一点是 从内核缓冲区拷贝数据到用户态缓冲区的过程也是由系统异步完成，应用进程只需要在指定的数组中引用数据即可。

3. AIO 与信号驱动 I/O 的主要区别：
   信号驱动 I/O 由内核通知何时可以开始一个 I/O 操作，而异步 I/O 由内核通知 I/O 操作何时已经完成。

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

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

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

1.阻塞I/O 与 非阻塞I/O

结合I/O模型来说，阻塞I/O会一直block对应的进程直到操作完成，而非阻塞 IO在kernel 在"等待数据准备"阶段会立刻返回。
所以一般认为，阻塞I/O只有BIO，另外四个模型都是属于非阻塞I/O。

2.同步I/O 与 异步I/O

1. 同步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信号通知请求进程，请求进程再把数据从内核读入到用户空间，这一步也是阻塞的。

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

Netty采用了哪种I/O模型?

1. Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 JDK NIO 框架的多路复用器 Selector。
   一个多路复用器 Selector 可以同时轮询多个 Channel，采用 epoll 模式后，只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。
2. Netty为什么不采用AIO？
   因为 AIO 的目的是希望 I/O 线程不阻塞主线程，属于异步 I/O，由内核通知 I/O 操作何时完成。AIO 适用于连接数多的且需要长时间连接的场景。
3. 对于AIO来说，目前操作系统支持程度有限且实现起来复杂。
   Netty也尝试过AIO，但是效果不是很理想，最终废弃了。