看了很多的博客，让我感觉精神一振的还是这篇：
https://blog.csdn.net/historyasamirror/article/details/5778378
我们先来说一下我们在使用BIO socket编程时候调用socket.read()方法时整体的执行流程：
1.程序调用socket.read()，这个方法会调用一个native read()方法，所以最终是由 OS执行read
2.OS得到read指令，命令网卡读取数据。
3.网卡读取数据完成后，将数据传递给内核。
4.内核把读取的数据拷贝的用户空间。
5.程序解除阻塞，完成read函数。
其实阻塞就是程序获得了CPU的资源，但是它就在那里干等着什么也不干。说白了就是占着茅坑不拉屎。
1. IO Model
Stevens在文章中一共比较了五种IO Model：
- Blocking IO
- Non-Blocking IO
- IO multiplexing
- Signal driven IO
- Asynchronous IO
其中Signal driven IO实际使用不多，我也没有仔细了解。
1.1 Blocking IO
Blocking IO是我们一开始学习Java都使用过的BIO编程方式，在jdk1.4之前， NIO没有出，Java IO编程只有这一个方式。它的调用过程：
我们开头举得例子就是这个图，socket.read()会调用native read(),而Java中的native方法会调用底层的dll，而dll是C/C++编写的，图中的recvfrom其实是C语言socket编程中的一个方法。所以其实我们在Java中调用socket.read()最后也会调用到图中的recvfrom方法。
解释一下图含义：
应用程序(也就是我们的代码)想要读取数据就会调用recvfrom,而recvfrom会通知OS来执行，OS就会判断数据报是否准备好(比如判断是否收到了一个完整的UDP报文，如果收到UDP报文不完整，那么就继续等待)。当数据包准备好了之后，OS就会将数据从内核空间拷贝到用户空间(因为我们的用户程序只能获取用户空间的内存，无法直接获取内核空间的内存)。拷贝完成之后socket,read()就会解除阻塞，并得到read的结果。
在BIO中我们称作的阻塞，也就是阻塞在2个地方：
- OS等待数据报准备好。
- 将数据从内核空间拷贝到用户空间。
在这2个时候，我们的BIO程序就是占着茅坑不拉屎，啥事情都不干。
1.2 Non-Blocking IO
直接上图：
NIO就是采用这种方式，当我们new了一个socket后我们可以设置它是非阻塞的。比如：
// 初始化一个 serverSocketChannel
serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.bind(new InetSocketAddress(8000));
// 设置serverSocketChannel为非阻塞模式
// 即 accept()会立即得到返回
serverSocketChannel.configureBlocking(false);
上面的代码是设置ServerSocketChannel为非阻塞，SocketChannel也是可以设置。NIO中提供了集中Channel(没有举例完，可能还有其他的Channel)：
ServerSocketChannelSocketChannelFileChannel-
DatagramChannel
只有FileChannel无法设置成非阻塞模式，其他Channel都可以设置为非阻塞模式。
从图中我们可以看到，当我设置非阻塞后，我们的socket.read()方法就会立即得到一个返回结果(成功 or 失败)，我们可以根据返回结果执行不同的逻辑，比如在失败时，我们可以做一些其他的事情。但事实上这种方式也是低效的，因为我们不得不使用轮询方法区一直问OS：“我的数据好了没啊”。
BIO 不会在recvfrom也就是socket.read()时候阻塞，但是还是会在将数据从内核空间拷贝到用户空间阻塞。一定要注意这个地方，Non-Blocking还是会阻塞的。
1.3 IO Multiplex
IO Multiplex即IO多路复用，我通信工程专业，看到这个我就想到了信道复用技术：时分复用，频分复用，码分复用。我是这样理解IO多路复用：传统情况下client与server通信需要一个3个socket(client的socket，server监听client连接的socket，即serversocket，还有一个server中用来和client通信的socket)，而在IO多路复用中，client与server通信需要的不是socket，而是3个channel，通过channel可以完成与socket同样的操作，channel的底层还是使用的socket进行通信，但是多个channel只对应一个socket(可能不只是一个，但是socket的数量一定少于channel数量)，这样仅仅通过少量的socket就可以完成更多的连接，提高了client容量。
不同的操作系统有不同的实现：
- Windows：selector
- Linux：epoll
- Mac：kqueue
其中epoll，kqueue比selector更为高效，这是因为他们监听方式的不同。selector的监听是通过轮询FD_SETSIZE来问每一个socket：“你改变了吗？”，假若监听到时间，那么selector就会调用相应的时间处理器进行处理。但是epoll与kqueue不同，他们把socket与事件绑定在一起，当监听到socket变化时，立即可以调用相应的处理。
selector，epoll，kqueue都属于Reactor IO设计。关于 Reactor与Proactor，可以看：
IO 模式 Reactor与Proactor
1.4 Signal driven IO
1.5 Asynchronous IO
Asynchronous IO异步IO。
Asynchronous IO调用中是真正的无阻塞，其他IO model中多少会有点阻塞。程序发起read操作之后，立刻就可以开始去做其它的事。而在内核角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。
我们思考一下问题
Blocking IO 与Non-Blocking IO 区别？
阻塞或非阻塞只涉及程序和OS，Blocking IO 会一直block程序知道OS返回，而Non-Block IO在OS内核在准备数据包的情况下会立即得到返回。
Asynchronous IO 与 Synchronous IO？
根据POSIX定义同步与非同步：
A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
我们可以理解为只要有block就是同步IO，完全没有block则是异步IO。所以我们之前所说的
- Blocking IO
- Non-Blocking IO
- IO Multiplex
均为Synchronous IO，只有Asynchronous IO为异步IO。
Non-Blocking IO 不是会立即返回没有阻塞吗?
Non-Blocking IO在数据包准备时是非阻塞的，但是在将数据从内核空间拷贝的用户空间还是会阻塞。而Asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，由内核完成读写，完成读写操作后kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。
2.各种IO对比
四种IO举例：
有A，B，C，D四个人在钓鱼：
A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；
B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；
C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；
D是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给D发个短信。
