目录
- 前言
- 五种I/O模型
- 1.同步阻塞I/O, BIO
- 2.同步非阻塞I/O, NIO
- 3.多路复用IO
- 4.信号驱动I/O
- 5.异步I/O，AIO
- 同步=阻塞？异步=非阻塞？
- 1.阻塞I/O 与 非阻塞I/O
- 2.同步I/O 与 异步I/O
- Netty采用了哪种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）
- 当一次网络IO发生时，主要涉及到三个对象：
- 发起此次IO操作的Process或者Application
- 系统内核kernel。用户进程无法直接操作I/O设备，必须通过系统内核kernel与I/O设备交互。
- I/O设备，包括网络、磁盘等。本文主要针对网络。
- 真正的I/O过程，主要分为两个阶段：
- 等待数据准备阶段。
- 数据拷贝阶段。数据准备完毕，从内核kernel拷贝到进程process中
以一个socket上的输入操作为例:
第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。
第二步就是把数据从内核缓冲区复制到用户态缓冲区。
五种I/O模型
1.同步阻塞I/O, BIO
-
我们一般使用最多的，最基础的I/O模型就是同步阻塞I/O。
典型应用：阻塞socket、Java BIO
-
BIO的过程：
- 应用进程向内核发起 I/O 请求，发起调用的线程 一直阻塞，等待内核返回结果。
- 数据准备完毕，从内核kernel拷贝到用户态内存（仍旧阻塞），然后kernel返回结果，用户进程process结束阻塞，重新运行。
BIO的特点就是在IO执行的 两个阶段 都被 阻塞
- 为了提高性能，常见的优化方式就是采用多线程
在一般的场景中，多线程模型下的BIO是成本较低、收益较高的方式。但是，如果在高并发的场景下，过多的创建线程，会严重占据系统资源，降低系统对外界响应效率。“池化”的目的在于减少创建和销毁线程的频率，让空闲的线程重新承担新的执行任务，维持一个合理的线程数量，可以很好的降低系统开销。但是，“池化”技术只能一定程度上缓解了频繁调用IO接口带来的资源占用。如果“池”上限100，而我们需要1000的IO，那并不能解决性能问题，这是由于BIO模型本身的限制决定的。
2.同步非阻塞I/O, NIO
典型应用：socket的非阻塞模式
- 过程
应用进程向内核发起 I/O 请求后，如果kernel中的数据还没有准备好，不再会“阻塞”等待结果，而是会立即返回。从用户进程角度讲 ，它发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它开始发起轮训操作。直到kernel中的数据准备好了，一旦用户再轮训过来，就马上将数据拷贝到了用户内存，然后返回。所以，在非阻塞式IO中，用户进程其实是需要不断地主动询问kernel数据准备好了没有。
非阻塞NIO模型相比于BIO的显著差异在于，在“数据等待”阶段，不再“阻塞”，立即返回。但是在“数据拷贝”阶段，仍然是“阻塞”的。
- 虽然非阻塞模型避免了“数据等待”阶段的阻塞，但是，采用轮询方式，会导致系统上下文切换开销很大，会大幅度推高CPU 占用率。因此，单独使用非阻塞 I/O 模型的效率并不高。而且随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。我们可以看到，轮训的目的只是检测“数据是否已经就绪”，而操作系统提供了更为高效的检测接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。
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的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。
4.信号驱动I/O
- 在使用信号驱动 I/O 时，当数据准备就绪后，内核通过发送一个 SIGIO 信号通知应用进程，应用进程就可以开始读取数据了。
- 信号驱动I/O模型的最大特点就是不需要process进程不断轮训内核是否已经准备就绪。
信号驱动I/O在"数据等待"阶段“非阻塞”。当数据准备完成后，信号通知process，process开始“数据拷贝”阶段，这里仍然是“阻塞”的。
- 信号驱动 I/O 有几个缺陷：
-
在大量 IO 操作时可能会因为信号队列溢出导致没法通知。
-
信号驱动 I/O 尽管对于处理 UDP 套接字来说有用，信号通知意味着到达一个数据报，或者返回一个异步错误。
但是，对于 TCP 而言，信号驱动的 I/O 方式不太好用。因为导致信号通知的情况有非常多种，每一个来进行判别会消耗很大资源。
所以信号驱动I/O模式用得非常少。而且尤其需要注意，在“数据拷贝”阶段，它仍然是“阻塞”的。
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是真正的异步模型，它不会对请求进程产生任何的阻塞。
同步=阻塞？异步=非阻塞？
1.阻塞I/O 与 非阻塞I/O
结合I/O模型来说，阻塞I/O会一直block对应的进程直到操作完成，而非阻塞 IO在kernel 在"等待数据准备"阶段会立刻返回。
所以一般认为，阻塞I/O只有BIO，另外四个模型都是属于非阻塞I/O。
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操作阻塞。
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，但是效果不是很理想，最终废弃了。
