I/O复用机制概述

共计 2766 个字符，预计需要花费 7 分钟才能阅读完成。

接下来我们将介绍几种常见的 I / O 模型及其区别

• blocking I/O
• nonblocking I/O
• I/O multiplexing (select and poll)
• signal driven I/O (SIGIO)
• asynchronous I/O (the POSIX aio_functions)

这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：

重点解释下上图，下面例子都会讲到。首先 application 调用 recvfrom()转入 kernel，注意 kernel 有 2 个过程，wait for data 和 copy data from kernel to user。直到最后 copy complete 后，recvfrom()才返回。此过程一直是阻塞的。

与 blocking I/ O 对立的，非阻塞套接字，调用过程图如下：

可以看见，如果直接操作它，那就是个轮询。。直到内核缓冲区有数据。

最常见的 I / O 复用模型，select。

select 先阻塞，有活动套接字才返回。与 blocking I/O 相比，select 会有两次系统调用，但是 select 能处理多个套接字。

只有 UNIX 系统支持，感兴趣的课查阅相关资料

与 I/O multiplexing (select and poll) 相比，它的优势是，免去了 select 的阻塞与轮询，当有活跃套接字时，由注册的 handler 处理。

很少有 *nix 系统支持，windows 的 IOCP 则是此模型

完全异步的 I / O 复用机制，因为纵观上面其它四种模型，至少都会在由 kernel copy data to appliction 时阻塞。而该模型是当 copy 完成后才通知 application，可见是纯异步的。好像只有 windows 的完成端口是这个模型，效率也很出色。

可以看出，越往后，阻塞越少，理论上效率也是最优。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 这些，他们都是跨平台的，而且他们自动选择最优的 I / O 复用机制，用户只需调用接口即可。说到这里又得说说 2 个设计模式，Reactor and Proactor。Libevent 是 Reactor 模型，ACE 提供 Proactor 模型。实际都是对各种 I / O 复用机制的封装。

Java nio 包是什么 I / O 机制？

我曾天真的认为 java nio 封装的是 IOCP。。现在可以确定，目前的 java 本质是 select()模型，可以检查 /jre/bin/nio.dll 得知。至于 java 服务器为什么效率还不错。我也不得而知，可能是设计得比较好吧。

Select
1.Socket 数量限制: 该模式可操作的 Socket 数由 FD_SETSIZE 决定, 内核默认 32*32=1024.
2. 操作限制: 通过遍历 FD_SETSIZE 个 Socket 来完成调度, 不管哪个 Socket 是活跃的, 都遍历一遍.

Poll
1.Socket 数量几乎无限制: 该模式下的 Socket 对应的 fd 列表由一个数组来保存, 大小不限(默认 4k).
2. 操作限制: 同 Select.

Epoll
1.Socket 数量无限制: 同 Poll
2. 操作无限制: 基于内核提供的反射模式, 有活跃 Socket 时, 内核访问该 Socket 的 callback, 不需要遍历轮询.

大部分情况下, 反射的效率都比遍历来的高, 但是当所有 Socket 都活跃的时候, 反射还会更高么? 这时候所有的 callback 都被唤醒, 会导致资源的竞争. 既然都是要处理所有的 Socket, 那么遍历是最简单最有效的实现方式.

对于 IM 服务器, 服务器和服务器之间都是长链接, 但数量不多, 一般一台 60\70 个, 比如采用 ICE 这种架构设计, 但请求相当频繁和密集, 这时候通过反射唤醒 callback 不一定比用 select 去遍历处理更好. 对于 web portal 服务器, 都是浏览器客户端发起的 http 短链接请求, 数量很大, 好一点的网站动辄每分钟上千个请求过来, 同时服务器端还有更多的闲置等待超时的 Socket, 这时候没必要把全部的 Socket 都遍历处理, 因为那些等待超时的请求是大多数的, 这样用 Epoll 会更好.

1. 只有 IOCP 是 asynchronous I/O，其他机制或多或少都会有一点阻塞。
2. select 低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
3. epoll, kqueue 是 Reacor 模式，IOCP 是 Proactor 模式。
4. java nio 包是 select 模型。

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券