【常见的I/O模型及其区别】

首先，介绍几种常见的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）朋友不想逛街，餐厅又太吵了，回家好好休息一下。于是我们叫外卖，打个电话点餐，然后我和朋友可以在家好好休息一下，饭好了送货员送到家里来。这就是典型的异步，只需要打个电话说一下，然后可以做自己的事情，饭好了就送来了。