服务器中fork 、 select、poll、 epoll有什么区别

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

这篇文章将为大家详细讲解有关服务器中 fork、select、poll、epoll 有什么区别，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

使用了 fork、select、epoll 三种 socket 服务器工作模式，客户端向服务端发送任何数据，服务端再原样返回给客户端，本文的目的只为加深偶的记忆。
fork: 每 accept 到一个 socket 之后，开启一个子进程来负责收发处理工作。select

select 最早于 1983 年出现在 4.2BSD 中，它通过一个 select() 系统调用来监视多个文件描述符的数组，当 select() 返回后，该数组中就绪的文件描述符便会被内核修改标志位，使得进程可以获得这些文件描述符从而进行后续的读写操作。

select 目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，事实上从现在看来，这也是它所剩不多的优点之一。

select 的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在 Linux 上一般为 1024，不过可以通过修改宏定义甚至重新编译内核的方式提升这一限制。

另外，select() 所维护的存储大量文件描述符的数据结构，随着文件描述符数量的增大，其复制的开销也线性增长。同时，由于网络响应时间的延迟使得大量 TCP 连接处于非活跃状态，但调用 select() 会对所有 socket 进行一次线性扫描，所以这也浪费了一定的开销。

poll

poll 在 1986 年诞生于 System V Release 3，它和 select 在本质上没有多大差别，但是 poll 没有最大文件描述符数量的限制。

poll 和 select 同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

另外，select() 和 poll() 将就绪的文件描述符告诉进程后，如果进程没有对其进行 IO 操作，那么下次调用 select() 和 poll() 的时候将再次报告这些文件描述符，所以它们一般不会丢失就绪的消息，这种方式称为水平触发（Level Triggered）。

epoll

直到 Linux2.6 才出现了由内核直接支持的实现方法，那就是 epoll，它几乎具备了之前所说的一切优点，被公认为 Linux2.6 下性能最好的多路 I / O 就绪通知方法。

epoll 可以同时支持水平触发和边缘触发（Edge Triggered，只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发），理论上边缘触发的性能要更高一些，但是代码实现相当复杂。

epoll 同样只告知那些就绪的文件描述符，而且当我们调用 epoll_wait() 获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去 epoll 指定的一个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。

另一个本质的改进在于 epoll 采用基于事件的就绪通知方式。在 select/poll 中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而 epoll 事先通过 epoll_ctl() 来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似 callback 的回调机制，迅速激活这个文件描述符，当进程调用 epoll_wait() 时便得到通知。

关于“服务器中 fork、select、poll、epoll 有什么区别”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。