看了很多的博客，让我感觉精神一振的还是这篇：
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编程只有这一个方式。它的调用过程：

image

我们开头举得例子就是这个图，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个地方：

1. OS等待数据报准备好。
2. 将数据从内核空间拷贝到用户空间。

在这2个时候，我们的BIO程序就是占着茅坑不拉屎，啥事情都不干。

1.2 Non-Blocking IO

直接上图：

image

NIO就是采用这种方式，当我们new了一个socket后我们可以设置它是非阻塞的。比如：

// 初始化一个 serverSocketChannel
serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.bind(new InetSocketAddress(8000));
// 设置serverSocketChannel为非阻塞模式
// 即 accept()会立即得到返回
serverSocketChannel.configureBlocking(false);

上面的代码是设置ServerSocketChannel为非阻塞，SocketChannel也是可以设置。NIO中提供了集中Channel(没有举例完，可能还有其他的Channel)：

• ServerSocketChannel
• SocketChannel
• FileChannel
• DatagramChannel
  只有FileChannel无法设置成非阻塞模式，其他Channel都可以设置为非阻塞模式。

从图中我们可以看到，当我设置非阻塞后，我们的socket.read()方法就会立即得到一个返回结果(成功 or 失败)，我们可以根据返回结果执行不同的逻辑，比如在失败时，我们可以做一些其他的事情。但事实上这种方式也是低效的，因为我们不得不使用轮询方法区一直问OS：“我的数据好了没啊”。

BIO 不会在recvfrom也就是socket.read()时候阻塞，但是还是会在将数据从内核空间拷贝到用户空间阻塞。一定要注意这个地方，Non-Blocking还是会阻塞的。

1.3 IO Multiplex

image

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

image

1.5 Asynchronous IO

Asynchronous IO异步IO。

image

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对比

2.png

四种IO举例：

有A，B，C，D四个人在钓鱼：
A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；
B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；
C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；
D是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给D发个短信。

3. 参考博客

IO - 同步，异步，阻塞，非阻塞 （亡羊补牢篇）