这篇文章大部分内容，图片都来自《Unix网络编程》和《深入浅出Nodejs》这本两本书。如果有书的同学，可以直接去看书了，在我看来，目前还没遇到过比书上讲得更清楚的。如果没有，没关系，看我的文章也一样（反正我也是抄的，哈哈）。
阻塞与非阻塞
从简单的开始，我们以经典的读取文件的模型举例。（对操作系统而言，所有的输入输出设备都被抽象成文件。）
在发起读取文件的请求时，应用层会调用系统内核的I/O接口。
如果应用层调用的是阻塞型I/O，那么在调用之后，应用层即刻被挂起，一直出于等待数据返回的状态，直到系统内核从磁盘读取完数据并返回给应用层，应用层才用获得的数据进行接下来的其他操作。
如果应用层调用的是非阻塞I/O，那么调用后，系统内核会立即返回（虽然还没有文件内容的数据），应用层并不会被挂起，它可以做其他任意它想做的操作。（至于文件内容数据如何返回给应用层，这已经超出了阻塞和非阻塞的辨别范畴。）
这便是（脱离同步和异步来说之后）阻塞和非阻塞的区别。总结来说，是否是阻塞还是非阻塞，关注的是接口调用（发出请求）后等待数据返回时的状态。被挂起无法执行其他操作的则是阻塞型的，可以被立即「抽离」去完成其他「任务」的则是非阻塞型的。
但任何技术都不是完美的，非阻塞I/O带来的是需要轮询技术去确定是否完成数据的获取，他让Cpu长期处理状态的判断也是一种CPU资源的浪费。
现在的轮询技术大概有以下几类
- read
他是最原始的，性能最低的，在数据返回前，CPU一直用在等待上 - select
他是在read上的一种改进，通过对文件描述符上的事件状态进行判断，但他有一个较弱的限制，他最多能同时检查1024个文件描述符 - poll
在select上进行改进，采用链表的方式避免了数组长度的限制，但文件描述符较多时，他的效率还是十分低下的 - epoll
是Linux下效率最高的I/O事件通知机制，在进入轮询时如果没有检查到I/O事件，将会进行休眠，直到事件发生将它唤醒。他真实利用了事件通知。执行回调的方式，而不是遍历，极大地提升了效率
尽管epoll已经利用了事件通知降低了CPU的调用，但是，休眠期间的CPU几乎是闲置的，那么是否有一种理想的异步模型呢?
同步和异步
阻塞和非阻塞解决了应用层等待数据返回时的状态问题，那系统内核获取到的数据到底如何返回给应用层呢？这里不同类型的操作便体现的是同步和异步的区别。
对于同步型的调用，应用层需要自己去向系统内核问询，如果数据还未读取完毕，那此时读取文件的任务还未完成，应用层根据其阻塞和非阻塞的划分，或挂起或去做其他事情（所以同步和异步并不决定其等待数据返回时的状态）；如果数据已经读取完毕，那此时系统内核将数据返回给应用层，应用层即可以用取得的数据做其他相关的事情。
而对于异步型的调用，应用层无需主动向系统内核问询，在系统内核读取完文件数据之后，会主动通知应用层数据已经读取完毕，此时应用层即可以接收系统内核返回过来的数据，再做其他事情。
这便是（脱离阻塞和非阻塞来说之后）同步和异步的区别。也就是说，是否是同步还是异步，关注的是任务完成时消息通知的方式。由调用方盲目主动问询的方式是同步调用，由被调用方主动通知调用方任务已完成的方式是异步调用。
总的来说，同步和异步关注的是任务完成消息通知的机制，而阻塞和非阻塞关注的是等待任务完成时请求者的状态。
Node的异步I/O
事件循环
在进程启动时Node便会创建一个while()循环，每次循环过程就查看是否有事件待处理，如果有，就取出事件及其相关的回调函数。如果不再有，就跳出流程。
观察者
请求对象
对于Node中的I/O调用而言，回调函数不由开发者用。从我们发出调用后, 到回调函数被执行,中发生了什么？事实上,从JavaScript发起调用到内核执行完I/O操作的过程中,存在一中间产物,它叫做请求对象。
从js调用Node的核心模块，核心模块调用Cpp内建模块，内建模块再通过libuv进行系统调用。实质上调用的是一个叫uv_fs_open的方法，同时创建了请求对象（FSReqWrap）。包装完请求对象后，就将这个包装好的请求对象推入线程池等待执行，当线程池中有可用线程时，就会根据传入参数的类型调用相应的底层函数。至此，由JavaScript发起的异步调用第一阶段就此结束，JavaScript线程就可以继续执行当前任务后续操作。当前I/O操作在线程池中等待执行，不管是否阻塞I/O都不会影响JS线程的后续操作，达到了异步的效果
执行回调
请求对象送入线程池等待执行之后，异步I/O的第一步就完成了，回调通知是第二部分。I/O调用完成后，会将结果储存在req-result属性上，再通知IOCP，告知当前对象操作完成，并将线程还给线程池，在这个过程中事件循环中的观察者一折被调用，用于检查线程池中是否有执行完的请求，如果存在，就加入到I/O观察者队列中，再将其当做事件处理
小节
从前实I/O的过程中,我们可以提取出几个关于异步I/O的关键词：单线程、事件循 环、观察者，I/O线程池。这里就要问了单线程与I/O线程池之间好像冲突了。由于 JavaScript是单线程的,所以我们认为他不能驾驭多核CPU。事实上,在Node中, 除了JavaScript（主线程）是单线程外,Node自身是多线程的,只是I/O线程使用的CPU很少。
Java的I/O模型
《unix网络编程》里总结了五类IO模型。为了更好地理解，我会举一个叫外卖的例子来说明。
1. 完全阻塞模型
它的示意图如下：
就是说，如果我客户端发起了connect请求，那么当前线程就会休眠，等待服务端响应完毕，返回消息，才会继续走下去。这种代码，我们已经写过了：
socketChannel = SocketChannel.open();
socketChannel.connect(new InetSocketAddress("192.168.0.13", 8000));
System.out.println("Hello");
你会看到，在connect没有完成之前，最后第三行的println根本不会执行。也就是说客户端会阻塞在这个地方。
就好比，我叫个外卖，然后我就去大门口傻等着，外卖不送到，我也什么都不做，就坐在门口打盹，直到外卖小哥过来，把我叫醒，我才拿着外卖回家去吃。这样做显然效率不高，显得脑子有水。
2. 非阻塞式IO。
把非阻塞的文件描述符称为非阻塞I/O。可以通过设置SOCK_NONBLOCK标记创建非阻塞的socket fd，或者使用fcntl将fd设置为非阻塞。
对非阻塞fd调用系统接口时，不需要等待事件发生而立即返回，事件没有发生，接口返回-1，此时需要通过errno的值来区分是否出错，有过网络编程的经验的应该都了解这点。不同的接口，立即返回时的errno值不尽相同，如，recv、send、accept errno通常被设置为EAGIN 或者EWOULDBLOCK，connect 则为EINPRO- GRESS 。
就是说，客户端程序会不停地去尝试读取数据，但是不会阻塞在那个读方法里，如果读的时候，没有读到内容，也会立即返回。这就允许我们在客户端里，读到不数据的时候可以搞点其他的事情了。
仍然以外卖举例，就相当于，我一边扫地，一边等外卖。我不再像原来一样，在门口傻等了，而是扫两下，就跑到门口看看外卖到了没有。一直这样循环，直到我取到外卖，才从这个循环中跳出来，进入吃的流程。
3. IO多路复用
非常非常非常重要。可能是我的课程开始以来，最重要的一部分。请务必保证能理解透彻，这是NIO的核心与关键，也是高性能服务器的第一要诀。
最常用的I/O事件通知机制就是I/O复用(I/O multiplexing)。Linux 环境中使用select/poll/epoll_wait 实现I/O复用，I/O复用接口本身是阻塞的，在应用程序中通过I/O复用接口向内核注册fd所关注的事件，当关注事件触发时，通过I/O复用接口的返回值通知到应用程序。I/O复用接口可以同时监听多个I/O事件以提高事件处理效率。
4. SIGIO
除了I/O复用方式通知I/O事件，还可以通过SIGIO信号来通知I/O事件，如图所示。两者不同的是，在等待数据达到期间，I/O复用是会阻塞应用程序，而SIGIO方式是不会阻塞应用程序的。
上面这张图，就是我们现实生活中真正的外卖。数据到达以后，给客户端发一个消息，让客户端过来取数据。这就像外卖小哥到你家门口给你打电话，让你出来取一下。显然，这种是最方便的，也是最合理的。
但实际上，在真正的编程中，我们很少使用这种模型。
5. async io
POSIX规范定义了一组异步操作I/O的接口，不用关心fd 是阻塞还是非阻塞，异步I/O是由内核接管应用层对fd的I/O操作。异步I/O向应用层通知I/O操作完成的事件，这与前面介绍的I/O 复用模型、SIGIO模型通知事件就绪的方式明显不同。以aio_read 实现异步读取IO数据为例，如图所示，在等待I/O操作完成期间，不会阻塞应用程序。
这个图，如果对应到外卖有点不合适了，比较像网购空调，我所要做的，只是下单，而快递小哥会把空调送过来，他也不会让你自己去取，他会让安装师傅直接帮你安装。这个过程中，你什么都不需要做。你所要做的仅仅是发起一个请求。这种IO模型就是纯正的异步IO。
这种纯异步IO的最典型例子就是上面我们提到node.js中的callback。
这5种IO并不是相互对立的，通过一定的技巧，是可以相互转化的。
参考资料：
Java NIO(3): IO模型
深入浅出Nodejs
