首先，介绍几种常见的I/O模型及其区别
blocking I/O (阻塞I/O)
nonblocking I/O (非阻塞I/O)
I/O multiplexing (select and poll) (I/O复用(select和poll))
signal driven I/O (SIGIO) (信号驱动I/O(SIGIO) nginx默认采用了边缘触发驱动机制 )
asynchronous I/O (the POSIX aio_functions) (异步I/O(POSIX的aio_系列函数))
同步I/O与异步I/O
POSIX把这两个术语定义如下：
同步I/O操作（synchronous I/O operation）导致请求进程阻塞，直到I/O操作完成。
异步I/O（asynchronous I/O operation）不导致请求进程阻塞。
根据上述定义，我们前4种模型----阻塞I/O模型、非阻塞I/O模型、I/O复用模型和信号去驱动I/O模型都是同步I/O模型，因为其中真正的I/O操作（recvfrom）将阻塞进程。
只有异步I/O模型与POSIX定义的异步I/O相匹配。
同步&&异步
同步：如果有多个任务或者事件要发生，这些任务或者事件必须逐个地进行，一个事件或者任务的执行会导致整个流程的暂时等待，这些事件没有办法并发地执行；
异步：如果有多个任务或者事件发生，这些事件可以并发地执行，一个事件或者任务的执行不会导致整个流程的暂时等待。
这就是同步和异步。举个简单的例子，假如有一个任务包括两个子任务A和B，对于同步来说，当A在执行的过程中，B只有等待，直至A执行完毕，B才能执行；而对于异步就是A和B可以并发地执行，B不必等待A执行完毕之后再执行，这样就不会由于A的执行导致整个任务的暂时等待。
阻塞&&非阻塞
阻塞：当某个事件或者任务在执行过程中，它发出一个请求操作，但是由于该请求操作需要的条件不满足，那么就会一直在那等待，直至条件满足；
非阻塞：当某个事件或者任务在执行过程中，它发出一个请求操作，如果该请求操作需要的条件不满足，会立即返回一个标志信息告知条件不满足，不会一直在那等待。
这就是阻塞和非阻塞的区别。也就是说阻塞和非阻塞的区别关键在于当发出请求一个操作时，如果条件不满足，是会一直等待还是返回一个标志信息。
阻塞IO&&非阻塞IO
在阻塞模式下，若从网络流中读取不到指定大小的数据量，阻塞IO就在那里阻塞着。比如，已知后面会有10个字节的数据发过来，但是我现在只收到8个字节，那么当前线程就在那傻傻地等到下一个字节的到来，对，就在那等着，啥事也不做，直到把这10个字节读取完，这才将阻塞放开通行。
在非阻塞模式下，若从网络流中读取不到指定大小的数据量，非阻塞IO就立即通行。比如，已知后面会有10个字节的数据发过来，但是我现在只收到8个字节，那么当前线程就读取这8个字节的数据，读完后就立即返回，等另外两个字节再来的时候再去读取。
同步IO&&异步IO
在同步文件IO中，线程启动一个IO操作然后就立即进入等待状态，直到IO操作完成后才醒来继续执行。而异步文件IO方式中，线程发送一个IO请求到内核，然后继续处理其他的事情，内核完成IO请求后，将会通知线程IO操作完成了。
同步过程中进程触发IO操作并等待或者轮询的去查看IO操作是否完成。异步过程中进程触发IO操作以后，直接返回，做自己的事情，IO交给内核来处理，完成后内核通知进程IO完成
Java nio包是什么I/O机制？
目前的java本质是select()模型，可以检查/jre/bin/nio.dll得知。至于java服务器为什么效率还不错。
总结一些重点：
只有IOCP是asynchronous I/O，其他机制或多或少都会有一点阻塞。
select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
epoll, kqueue是Reacor模式，IOCP是Proactor模式。
java nio包是select模型。
（1）选择模式（Select）
选择模型是Winsock中最常见的I/O模型。之所以称其为“select模型”，是由于它的“中心思想”便是利用select函数，实现对I/O的管理！最初设计该模型时，主要面向的是某些使用Unix操作系统的计算机，它们采用的是 Berkeley套接字方案。select模型已集成到Winsock 1.1中，它使那些想避免在套接字调用过程中被无辜“锁定”的应用程序，采取一种有序的方式，同时进行对多个套接字的管理。
（2 ）异步选择模式（WSAAsyncSelect）
使用异步选择模型，应用程序可在一个套接字上，接收以Windows消息为基础的网络事件通知。具体的做法是在建好一个套接字后，调用WSAAsyncSelect函数。
（3 事件选择模式（WSAEventSelect）
WSAEventSelect和WSAAsyncSelect模型类似，它也允许应用程序在一个或多个套接字上，接收以事件为基础的网络事件通知。对于WSAAsyncSelect模型采用的网络事件来说，它们均可原封不动地移植到事件选择模型上。在用事件选择模型开发的应用程序中，也能接收和处理所有那些事件。该模型最主要的差别在于网络事件会投递至一个事件对象句柄，而非投递至一个窗口例程。
（4 ）重叠I/O模式（Overlapped I/O）
在Winsock中，相比我们迄今为止解释过的其他所有I/O模型，重叠I/O模型使应用程序能达到更佳的系统性能。重叠模型的基本设计原理便是让应用程序使用一个重叠的数据结构，一次投递一个或多个Winsock I/O请求。针对那些提交的请求，在它们完成之后，应用程序可为它们提供服务。该模型适用于除Windows CE之外的各种Windows平台。模型的总体设计以Win32重叠I/O机制为基础。那个机制可通过ReadFile和WriteFile两个函数，针对设备执行I/O操作。
（5 ）完成端口模式（Completion Port)
“完成端口”模型是迄今为止最为复杂的一种I/O模型。然而，假若一个应用程序同时需要管理为数众多的套接字，那么采用这种模型，往往可以达到最佳的系统性能！但不幸的是，该模型只适用于Windows NT和Windows 2000操作系统。
因其设计的复杂性，只有在你的应用程序需要同时管理数百乃至上千个套接字的时候，而且希望随着系统内安装的CPU数量的增多，应用程序的性能也可以线性提升，才应考虑采用“完成端口”模型。要记住的一个基本准则是，假如要为Windows NT或Windows 2000开发高性能的服务器应用，同时希望为大量套接字I/O请求提供服务（Web服务器便是这方面的典型例子），那么I/O完成端口模型便是最佳选择！
IO 完成的步骤
①进程向内核发起一个系统调用，
②内核接收到系统调用，知道是对文件的请求，于是告诉磁盘，把文件读取出来
③磁盘接收到来着内核的命令后，把文件载入到内核的内存空间里面
④内核的内存空间接收到数据之后，把数据copy到用户进程的内存空间(此过程是I/O发生的地方)
⑤进程内存空间得到数据后，给内核发送通知
⑥内核把接收到的通知回复给进程，此过程为唤醒进程，然后进程得到数据，进行下一步操作
周末人多，吃饭需要排队，我和朋友有以下几种方案：
（1）我和朋友点完餐后，不知道什么时候能做好，只好坐在餐厅里面等，直到做好，然后吃完才离开。
朋友本想还和我一起逛街的，但是不知道饭能什么时候做好，只好和我一起在餐厅等，而不能去逛街，直到吃完饭才能去逛街，中间等待做饭的时间浪费掉了。这就是典型的阻塞。
（2）我朋友不甘心白白在这等，又想去逛商场，又担心饭好了。所以我们逛一会，回来询问服务员饭好了没有，来来回回好多次，饭都还没吃都快累死了啦。这就是非阻塞。需要不断的询问，是否准备好了。
（3）与第二个方案差不多，餐厅安装了电子屏幕用来显示点餐的状态，这样我和朋友逛街一会，回来就不用去询问服务员了，直接看电子屏幕就可以了。这样每个人的餐是否好了，都直接看电子屏幕就可以了，这就是典型的IO多路复用，如select、poll、epoll（nginx）。
（4）朋友不想逛街，餐厅又太吵了，回家好好休息一下。于是我们叫外卖，打个电话点餐，然后我和朋友可以在家好好休息一下，饭好了送货员送到家里来。这就是典型的异步，只需要打个电话说一下，然后可以做自己的事情，饭好了就送来了。