IO模型及select、poll、epoll和kqueue的区别.docxVIP

IO模型及select、poll、epoll和kqueue的区分 这个不用多解释吧，堵塞套接字。下图是它调用过程的图示： ? 重点解释下上图，下面例子都会讲到。首先application调用 recvfrom()转入kernel，留意kernel有2个过程，wait for data和copy data from kernel to user。直到最终copy complete后，recvfrom()才前往。此过程一直是堵塞的。 ? 2 nonblocking I/O：? 与blocking I/O对立的，非堵塞套接字，调用过程图如下： 可以观察，假如直接操作它，那就是个轮询。。直到内核缓冲区有数据。 ? 3 I/O multiplexing (select and poll)? 最常见的I/O复用模型，select。 select先堵塞，有活动套接字才前往。与blocking I/O相比，select会有两次系统调用，但是select能处理多个套接字。 ? 4 signal driven I/O (SIGIO)? 只要UNIX系统支持，感爱好的课查阅相关材料 与I/O multiplexing (select and poll)相比，它的优势是，免去了select的堵塞与轮询，当有活跃套接字时，由注册的handler处理。 ? 5 asynchronous I/O (the POSIX aio_functions)? 很少有*nix系统支持，windows的IOCP则是此模型 完全异步的I/O复用机制，由于纵观上面其它四种模型，至少都会在由kernel copy data to appliction时堵塞。而该模型是当copy完成后才通知application，可见是纯异步的。好像只要windows的完成端口是这个模型，效率也很精彩。 6 下面是以上五种模型的比较 可以看出，越往后，堵塞越少，理论上效率也是最优。 =====================分割线================================== 5种模型的比较比较清楚了，剩下的就是把select,epoll,iocp,kqueue按号入座那就OK了。 select和iocp分别对应第3种与第5种模型，那么epoll与kqueue呢？其实也于select属于同一种模型，只是更高级一些，可以看作有了第4种模型的某些特性，如callback机制。 为什么epoll,kqueue比select高级？? 答案是，他们无轮询。由于他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会铺张很多CPU时间。假如能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避开了轮询，这正是epoll与kqueue做的。 windows or *nix （IOCP or kqueue/epoll）？ ? 诚然，Windows的IOCP格外精彩，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue/epoll 与 IOCP相比，就是多了一层从内核copy数据到应用层的堵塞，从而不能算作asynchronous I/O类。但是，这层小小的堵塞无足轻重，kqueue与epoll已经做得很优秀了。 供应全都的接口，IO Design Patterns 实际上，不管是哪种模型，都可以笼统一层出来，供应全都的接口，广为人知的有ACE,Libevent（基于reactor模式）这些，他们都是跨平台的，而且他们自动选择最优的I/O复用机制，用户只需调用接口即可。说到这里又得说说2个设计模式，Reactor?and?Proactor。见：Reactor模式--VS--Proactor模式。Libevent是Reactor模型，ACE供应Proactor模型。实际都是对各种I/O复用机制的封装。 Java nio包是什么I/O机制？ ?现在可以确定，目前的java本质是select()模型，可以检查/jre/bin/nio.dll得知。至于java服务器为什么效率还不错。。我也不得而知，可能是设计得比较好吧。。-_-。 =====================分割线================================== 总结一些重点： 只要IOCP是asynchronous I/O，其他机制或多或少都会有一点堵塞。 select低效是由于每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善 epoll, kqueue、selec