要谈Java的NIO, 还是先从I/O开始说起。 Unix提供了5种不同的I/O模型，分别是
- 阻塞I/O(blocking I/O)
- 非阻塞I/O(non-blocking I/O)
- I/O复用(I/O multiplexing)
- 信号驱动式I/O(signal-driven I/O)
- 异步I/O(asynchronous I/O)
一个I/O操作需要从用户态进入内核态运行,通常包括俩阶段
- 等待数据
- 从内核向进程复制数据
对于socket I/O而言，第一步通常是等待数据从网络中到达，到达之后会复制到内核的某个缓冲区 第二布就是从内核缓冲区复制到应用进程缓冲区
阻塞I/O
默认情况下，所有的socket都是阻塞的. 如图所示
- 应用发起recvfrom这个系统调用, 应用被阻塞
- 内核等待数据准备好
- 数据准备好, 内核将数据复制到应用缓冲区
- 应用从阻塞里恢复，处理数据
这也是理解和编程起来比较简单的模型，所以计算机早期用的很多,现在在处理超大文件的时候，也依然适用于这种模型。
非阻塞I/O
相比于Blocking I/O, Non-Blocking I/O的 等待数据 阶段不会被阻塞，也就是说操作系统不会挂起应用, 应用 不断轮询(polling)内核看是否数据准备好。某次轮询发现准备好了，再直接发系统调用阻塞取数据.
Unix网络编程里对轮询的定义是: 应用进程对非阻塞描述符循环发送系统调用，以查看某个操作是否就绪
I/O多路复用
在处理非常多的描述符的时候，I/O多路复用技术显得非常有用。I/O多路复用需要发送2次系统调用:
- select或者poll, 获取可读条件, 等待描述符变成可读
- 发起recvfrom系统调用，内核复制数据到应用。
在只有1个客户端的时候，I/O多路复用技术甚至不如阻塞I/O.因为多发了一次系统调用。 但有些常用的网络场景，如:
- 既要处理TCP,又要处理UDP
- 一个服务器处理多个服务或者多个协议
- 一个TCP服务器既要监听socket，又要处理已连接socket
这些场景下，多发的这次系统调用能带来更高的I/O处理效率，能更均匀的使用服务器时间片, 处理更多连接。 常用的方法是把I/O多路复用和非阻塞I/O结合使用，这样应用进程不需要阻塞，能处理别的业务，同时又能够处理多个I/O请求
信号驱动I/O
信号模型的步骤是:
- 应用进程发起一个信号，告诉内核要什么文件，然后立马返回
- 内核准备好数据
- 应用进程收到信号发起recvfrom系统调用来阻塞取数据
信号驱动模型类似于你去一点点买奶茶，对方给你一个小票。 什么时候好了对方喊xx号(这就是信号)好了.然后你来取奶茶(recvfrom取数据)
异步I/O
步骤：
- 应用进程发起aio_read系统调用，告诉内核要什么文件，然后立马返回
- 内核准备好数据, copy到应用进程, 然后给应用进程发aio_read指定的信号
- 应用进程收到信号，开始处理数据,整个过程应用进程都没有被阻塞
AIO模型是比较高效的, 异步非阻塞，从各个方面来说都是。但是编程难度比较大(和人的思维惯性相左)，代码写起来不易维护，可能未来会火吧。目前I/O多路复用已经足够用了。
总结
前四种模型的区别主要在第一阶段， 第二阶段recvfrom将数据从内核复制到应用的缓冲区期间，都会阻塞应用进程。 而异步I/O模型在两个阶段都要处理.
Non-Blocking I/O和Signal-Driven I/O在数据准备阶段都不会阻塞，前者要轮询内核数据是否准备好，后者是直接等待内核通知回调 Asynchronous I/O是在真正意义上的POSIX定义的异步io操作, 在数据准备和复制阶段都不会阻塞应用,但是编程难度大 I/O Multiplexing在数据准备阶段也会阻塞，但是可以处理更多I/O请求，也就是说加了层中间人抽象，虽然阻塞了应用进程，但是能知道多个fd可读可写,也是大名鼎鼎的reactor模式的基础
