unix和Linux的五种io模型,Unix的五种IO模型介绍
前言
之前打算总结一下Java的BIO(IO)，AIO，NIO，最后一步步深入，发现Unix(Linux)的IO模型需要提前掌握，所以先总结一下Unix的IO模型。
概述
Java IO 与 Unix IO 的关系(非严格对应)
Unix网络编程中介绍了五种IO模型，分别是：阻塞IO、非阻塞IO、IO多路复用、信号驱动IO、异步IO。
Java的IO模型与Unix的IO模型的对应关系如下所示(这个对应关系并不严格)：
Java-IO模型
Unix-IO模型
BIO
阻塞式IO
NIO
IO多路复用
AIO
异步IO
数据的内核态和用户态
在进行IO模型讲解之前，先讲讲数据的两个状态：内核态和用户态。
我们将文件从磁盘加载到内存中。操作系统是怎么做的？
第一步：因为我们的所有程序，都是和操作系统的内核进行交互，所以文件首先是从磁盘加载到内核，这时候文件是处于内核态。
第二步：文件从内核再加载到内存中，应用程序此时才可以在内存中进行读写操作。这个时候的文件就是内核态。
所以Unix的五种IO模型的不同指出，就是这两个步骤的处理流程不同。
Unix五种IO模型分别介绍
阻塞式IO
这种模式很简单，系统给调用recvfrom函数之后，线程一直处于等待状态，一直等到：
第一步文件加载到内核态完成，第二步文件加载到用户态完成。
非阻塞IO
系统不停的通过recvfrom进行轮询，一直到第一步完成，然后在第二步阻塞式的将数据从内核态加载到用户态。
这里的非阻塞IO模式，主要是指第一步，加载数据到内核态，这个过程是非阻塞的，通过轮询来判断数据是否在内核准备好。
IO多路复用
系统首先通过select，阻塞式的查看内核数据是否准备完毕。
当内核数据加载完成之后，系统会调用recvfrom，将内核态的数据加载到用户态。
这里看起来第一步和第二步都是阻塞式操作，但是，select可以在极小代价的情况下，同时处理多个文件句柄(包括socket)。
信号驱动IO
第一步，相当于系统注册一个回调函数，当内核数据准备好了之后通知我。
此时系统可以做其他的事情，并不需要阻塞式的等待内核数据。
第二步，阻塞式调用recvfrom，将内核的数据加载到用户态。
异步IO
这个模型在理论上来说，是真正的异步模型，因为在以上四种模型中，在第二步：数据从内核态加载到用户态，都是同步操作。
而在该模型中，系统在加载文件的时候，只需要通过aio_read注册一个回调，当文件完成了内核态，用户态的加载之后，通知当前系统。
在这个过程中，系统不用等待，可以执行其他的运算任务。
汇总对比
这张图是对以上五种IO模型的汇总比较，总的来说，越靠后的模型在理论上来说就越高效。
前面的四种IO模型【阻塞IO、非阻塞IO、IO多路复用、信号驱动IO】，都属于同步IO，只有最后一种模型是真正的异步【异步IO】
系统调用介绍
1.Java的NIO老版本使用的是select模式，但后来改成了epoll，为什么？
因为select是轮询的模式，不停的检查文件句柄的状态。
epoll是callback的模式，当文件句柄准备好了之后，直接进行回调，更高效。
2.Java有真正的AIO模式吗？
在Windows系统下，通过IOCP实现。
在Linux系统下，没有，因为Linux系统下的AIO底层仍是epoll。
(个人猜测，这也是为什么Netty使用了NIO，而没有使用AIO)
他山之石
数据的内核态，用户态，这篇文章也有讲到，同时介绍了高效的数据传输方式：
zero-copy