内核aio_IO模型_NIO

I/O操作是分很多步骤的，如：等待数据、将数据拷贝到内核空间的PageCache（如果是Buffered I/O的话）、将数据拷贝到用户空间等。

同步指的是I/O动作会导致用户进程阻塞，异步则刚好相反。

在Java中，同步异步往往指的是函数是否会等待整个操作处理完成后返回，而阻塞与非阻塞指的往往是用户线程是否需要等待某个事件的到来而阻塞。

五种经典的I/O模型

1. Blocking I/O（阻塞I/O）

请求数据的进程需要一直阻塞等待读取完成才能返回，同时整个读取的动作（这里是recvfrom）也是要同步等待I/O操作的完成才返回。

[使用场景]

这个模型最大的问题在于比较耗时和浪费CPU资源，I/O设备（这里是网卡）往往是一种传输速率较慢的设备，如果在需要很大吞吐量的系统中这种模型就不太适合了。

但是，有时候我们必须等待从I/O设备中传入的数据或者要向它写入某些数据，这个时候阻塞I/O往往是最适合的。比如你的项目中有一个配置文件，里边包含了很多关于项目的配置信息，那么在启动项目的时候就必须等待这个文件的内容被全部读取并解析后才能继续启动项目，这种场景下BIO是最合适的。

2. Nonblocking I/O（非阻塞I/O）

当数据没有准备好的时候，recvfrom调用仍然是同步返回结果。对于整个用户进程而言，它是非阻塞的。

[使用场景]

通常情况下，这是一种低效且十分浪费CPU的操作。

3. I/O Multiplexing（I/O多路复用）--业务层操作

在调用recvfrom之前先调用另外一个系统调用select。整个读取的动作（由两个系统调用组成）是异步的。Java的NIO编程中，多个线程可以向同一个Selector注册多个事件，这样就达到了多路复用的效果。

4. Signal-Driven I/O（信号驱动I/O）--网络层操作

用户进程告诉网卡说，你准备好了叫我一声，然后可以去做别的事情，当网卡来叫的时候就可以继续读操作了。

5. Asynchronous I/O （异步I/O）--操作系统层操作

用户程序使用操作系统提供的异步I/O的系统调用aio_read，这个调用会即时返回，当整个I/O操作完成后它会通知用户进程。典型的异步非阻塞I/O，与「信号驱动I/O」不同的是这个信号是等到所有的I/O动作都执行完之后（数据已经被拷贝到用户空间），才被发送给用户进程。

[使用场景]

在有些平台中，AIO是默认实现的，比如nodejs，其底层其实也是使用阻塞I/O实现的异步，但是对于开发者来说，可以认为它是完全异步的。

Reactor & Proactor模式

把视线从底层的I/O概念中移开，放到普通的应用层实现上，通常基于以上几种I/O模型，可以对应几个编程模式，这里将重点介绍Reactor和Proactor。
[Reactor ---[化工] 反应器; [核] 反应堆; 起反应的人;]

[Proactor ----前摄器]

使用Reactor模式构建的服务端

简单来说，Reactor指的是反应器，在这个模式中有一个角色叫分发器（分发器的叫法多种多样，acceptor、selector或者dispatcher），它会分发各种事件给Reactor，Reactor再去根据不同的事件来做相应的动作。在上图中Reactor进行计算的方式是通过线程池实现的，这是在简单的Reactor模式上又添加了更多的能力，来进一步提高吞吐量，这也是Netty的基本架构。

Reactor的好处和坏处

Reactor带来的好处是显而易见的：

吞吐量大
对计算资源（CPU）更充分的利用

当然也有一些坏处：

系统设计更复杂了
由于系统更复杂，导致调试很困难
不适合传输大量数据的场景

Proactor模型

Proactor相比Reactor更好的地方在于，I/O操作和消息通知的过程被下层实现了，业务程序不再需要考虑这些，可以将Proactor看做是对Reactor的又一次封装。根据这个思路可以再进一步，在Reactor模式中不阻塞select，而是在每个业务逻辑执行完后去处理这些事件，也就是在每次循环结束时去处理当前积攒下来的事件（这个模型里如何定义一个循环是很重要的）。

假设在某种场景下，整个程序的目的都是处理单一的事情（比如一个web服务器的目的只是处理请求），我们可以将「与处理请求无关」的逻辑封装到一个框架内，在每次请求处理完后，都执行一次事件的分发和处理，这就是event loop了。很多语言中都有这种概念，如nodejs中的event loop，iOS中的run loop。