selectpollepoll区别

select&＃xff0c;poll&＃xff0c;epoll都是IO多路复用的机制。I/O多路复用就通过一种机制&＃xff0c;可以监视多个描述符&＃xff0c;一旦某个描述符就绪&＃xff08;一般是读就绪或者写就绪&＃xff09;&＃xff0c;能够通知程序进行相应的读写操作。但select&＃xff0c;poll&＃xff0c;epoll本质上都是同步I/O&＃xff0c;因为他们都需要在读写事件就绪后自己负责进行读写&＃xff0c;也就是说这个读写过程是阻塞的&＃xff0c;而异步I/O则无需自己负责进行读写&＃xff0c;异步I/O的实现会负责把数据从内核拷贝到用户空间。  

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持&＃xff0c;其中epoll是Linux所特有&＃xff0c;而select则应该是POSIX所规定&＃xff0c;一般操作系统均有实现

fd(file descriptor),用于表述指向文件的引用的抽象化概念&＃xff0c;是进程独有的文件描述符表的索引,它是一个索引值&＃xff0c;指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时&＃xff0c;内核向进程返回一个文件描述符。在程序设计中&＃xff0c;一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

简单的说&＃xff0c;就是内核为每个进程维护了一个file descriptor table&＃xff0c;file descriptor是file descriptor table的索引&＃xff0c;file descriptor table的表项又转而可以索引到系统级的file table&＃xff0c;file table又可以索引到系统级的inode table&＃xff0c;而这个inode table则真正的描述了底层的文件。系统级的file table还记录了每个文件被打开的方式&＃xff1a;读、写、追加…。file descriptor table每个进程都有一个&＃xff0c;所以fork的会被拷贝。

int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

&＃xff08;1&＃xff09;使用copy_from_user从用户空间拷贝fd_set到内核空间

&＃xff08;2&＃xff09;注册回调函数__pollwait

&＃xff08;3&＃xff09;遍历所有fd&＃xff0c;调用其对应的poll方法&＃xff08;对于socket&＃xff0c;这个poll方法是sock_poll&＃xff0c;sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll&＃xff09;

&＃xff08;4&＃xff09;以tcp_poll为例&＃xff0c;其核心实现就是__pollwait&＃xff0c;也就是上面注册的回调函数。

&＃xff08;5&＃xff09;__pollwait的主要工作就是把current&＃xff08;当前进程&＃xff09;挂到设备的等待队列中&＃xff0c;不同的设备有不同的等待队列&＃xff0c;对于tcp_poll来说&＃xff0c;其等待队列是sk->sk_sleep&＃xff08;注意把进程挂到等待队列中并不代表进程已经睡眠了&＃xff09;。在设备收到一条消息&＃xff08;网络设备&＃xff09;或填写完文件数据&＃xff08;磁盘设备&＃xff09;后&＃xff0c;会唤醒设备等待队列上睡眠的进程&＃xff0c;这时current便被唤醒了。

&＃xff08;6&＃xff09;poll方法返回时会返回一个描述读写操作是否就绪的mask掩码&＃xff0c;根据这个mask掩码给fd_set赋值。

&＃xff08;7&＃xff09;如果遍历完所有的fd&＃xff0c;还没有返回一个可读写的mask掩码&＃xff0c;则会调用schedule_timeout是调用select的进程&＃xff08;也就是current&＃xff09;进入睡眠。当设备驱动发生自身资源可读写后&＃xff0c;会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间&＃xff08;schedule_timeout指定&＃xff09;&＃xff0c;还是没人唤醒&＃xff0c;则调用select的进程会重新被唤醒获得CPU&＃xff0c;进而重新遍历fd&＃xff0c;判断有没有就绪的fd。

&＃xff08;8&＃xff09;把fd_set从内核空间拷贝到用户空间。

select 函数监视的文件描述符分3类&＃xff0c;分别是writefds、readfds、和exceptfds。调用后select函数会阻塞&＃xff0c;直到有描述副就绪&＃xff08;有数据 可读、可写、或者有except&＃xff09;&＃xff0c;或者超时&＃xff08;timeout指定等待时间&＃xff0c;如果立即返回设为null即可&＃xff09;&＃xff0c;函数返回。当select函数返回后&＃xff0c;可以 通过遍历fdset&＃xff0c;来找到就绪的描述符。

fd_set(监听的端口个数)&＃xff1a;32位机默认是1024个&＃xff0c;64位机默认是2048。

缺点&＃xff1a;

        &＃xff08;1&＃xff09;单进程可以打开fd有限制&＃xff0c;在Linux上一般为1024&＃xff0c;可以通过修改宏定义甚至重新编译内核的方式提升这一限制&＃xff0c;但 是这样也会造成效率的降低。

        &＃xff08;2&＃xff09;对socket进行扫描时是线性扫描&＃xff0c;即采用轮询的方法&＃xff0c;效率较低&＃xff1b;        

        &＃xff08;3&＃xff09;用户空间和内核空间的复制非常消耗资源&＃xff1b;

int poll (struct pollfd *fds, unsigned int nfds, int timeout);

不同与select使用三个位图来表示三个fdset的方式&＃xff0c;poll使用一个 pollfd的指针实现。

struct pollfd {int fd; /* file descriptor */short events; /* requested events to watch */short revents; /* returned events witnessed */
};

调用过程和select类似

 时间复杂度:O(n)

 其和select不同的地方&＃xff1a;采用链表的方式替换原有fd_set数据结构,而使其没有连接数的限制。

select和poll都需要在返回后&＃xff0c;通过遍历文件描述符来获取已经就绪的socket。事实上&＃xff0c;同时连接的大量客户端在一时刻可能只有很少的处于就绪状态&＃xff0c;因此随着监视的描述符数量的增长&＃xff0c;其效率也会线性下降。(花大量时间只能获取小部分有用数据这也是很明显的缺点)

epoll是在2.6内核中提出的&＃xff0c;是之前的select和poll的增强版本。相对于select和poll来说&＃xff0c;epoll更加灵活&＃xff0c;没有描述符限制。epoll使用一个文件描述符管理多个描述符&＃xff0c;将用户关系的文件描述符的事件存放到内核的一个事件表中&＃xff0c;这样在用户空间和内核空间的copy只需一次。

epoll可以理解为event poll&＃xff0c;不同于忙轮询和无差别轮询,epoll事先通过epoll_ctl()来注册一 个文件描述符&＃xff0c;一旦基于某个文件描述符就绪时&＃xff0c;内核会采用类似callback的回调机制&＃xff0c;迅速激活这个文件描述符&＃xff0c;当进程调用epoll_wait() 时便得到通知。(此处去掉了遍历文件描述符&＃xff0c;而是通过监听回调的的机制。这正是epoll的魅力所在。)

epoll操作过程定义的三个接口&＃xff0c;分别如下&＃xff1a;

int epoll_create(int size)&＃xff1b;//创建一个epoll的句柄&＃xff0c;size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)&＃xff1b;
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

1. int epoll_create(int size);

创建一个epoll的句柄&＃xff0c;size用来告诉内核这个监听的数目一共有多大&＃xff0c;这个参数不同于select()中的第一个参数&＃xff0c;给出最大监听的fd&＃43;1的值&＃xff0c;参数size并不是限制了epoll所能监听的描述符最大个数&＃xff0c;只是对内核初始分配内部数据结构的一个建议。
当创建好epoll句柄后&＃xff0c;它就会占用一个fd值&＃xff0c;在linux下如果查看/proc/进程id/fd/&＃xff0c;是能够看到这个fd的&＃xff0c;所以在使用完epoll后&＃xff0c;必须调用close()关闭&＃xff0c;否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)&＃xff1b;

函数是对指定描述符fd执行op操作。
- epfd&＃xff1a;是epoll_create()的返回值。
- op&＃xff1a;表示op操作&＃xff0c;用三个宏来表示&＃xff1a;添加EPOLL_CTL_ADD&＃xff0c;删除EPOLL_CTL_DEL&＃xff0c;修改EPOLL_CTL_MOD。分别添加、删除和修改对fd的监听事件。
- fd&＃xff1a;是需要监听的fd&＃xff08;文件描述符&＃xff09;
- epoll_event&＃xff1a;是告诉内核需要监听什么事&＃xff0c;struct epoll_event结构如下&＃xff1a;

struct epoll_event {__uint32_t events; /* Epoll events */epoll_data_t data; /* User data variable */
};//events可以是以下几个宏的集合&＃xff1a;
EPOLLIN &＃xff1a;表示对应的文件描述符可以读&＃xff08;包括对端SOCKET正常关闭&＃xff09;&＃xff1b;
EPOLLOUT&＃xff1a;表示对应的文件描述符可以写&＃xff1b;
EPOLLPRI&＃xff1a;表示对应的文件描述符有紧急的数据可读&＃xff08;这里应该表示有带外数据到来&＃xff09;&＃xff1b;
EPOLLERR&＃xff1a;表示对应的文件描述符发生错误&＃xff1b;
EPOLLHUP&＃xff1a;表示对应的文件描述符被挂断&＃xff1b;
EPOLLET&＃xff1a; 将EPOLL设为边缘触发(Edge Triggered)模式&＃xff0c;这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT&＃xff1a;只监听一次事件&＃xff0c;当监听完这次事件之后&＃xff0c;如果还需要继续监听这个socket的话&＃xff0c;需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待epfd上的io事件&＃xff0c;最多返回maxevents个事件。
参数events用来从内核得到事件的集合&＃xff0c;maxevents告之内核这个events有多大&＃xff0c;这个maxevents的值不能大于创建epoll_create()时的size&＃xff0c;参数timeout是超时时间&＃xff08;毫秒&＃xff0c;0会立即返回&＃xff0c;-1将不确定&＃xff0c;也有说法说是永久阻塞&＃xff09;。该函数返回需要处理的事件数目&＃xff0c;如返回0表示已超时。

epoll的两种工作方式&＃xff1a;

1.水平触发 LT (level trigger) 默认模式

LT模式&＃xff1a;是缺省的工作方式&＃xff0c;并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了&＃xff0c;然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作&＃xff0c;内核还是会继续通知你的。

2.边缘触发 ET(edge trigger) 

ET模式&＃xff1a;是高速工作方式&＃xff0c;只支持no-block socket(非阻塞的读写 : 为了保证数据的完整性 )。就绪的事件只能处理一次&＃xff0c;若没有处理完会在下次的其它事件就绪时再进行处理。而若以后再也没有就绪的事件&＃xff0c;那么剩余的那部分数据也会随之而丢失。 ET模式在很大程度上减少了epoll事件被重复触发的次数&＃xff0c;因此效率要比LT模式高。只是如果使用ET模式&＃xff0c;就要保证每次进行数据处理时&＃xff0c;要将其处理完&＃xff0c;不能造成数据丢失&＃xff0c;这样对编写代码的人要求就比较高。 

优点&＃xff1a;

1、没有最大并发连接的限制&＃xff0c;能打开的FD的上限远大于1024&＃xff08;1G的内存上能监听约10万个端口&＃xff1b;
2、效率提升&＃xff0c;不是轮询的方式&＃xff0c;不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数&＃xff1b;
即Epoll最大的优点就在于它只管你“活跃”的连接&＃xff0c;而跟连接总数无关&＃xff0c;因此在实际的网络环境中&＃xff0c;Epoll的效率就会远远高于select和poll。

3、 内存拷贝&＃xff0c;利用mmap()文件映射内存加速与内核空间的消息传递&＃xff1b;即epoll使用mmap减少复制开销。

1、select&＃xff0c;poll实现需要自己不断轮询所有fd集合&＃xff0c;直到设备就绪&＃xff0c;期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表&＃xff0c;期间也可能多次睡眠和唤醒交替&＃xff0c;但是它是设备就绪时&＃xff0c;调用回调函数&＃xff0c;把就绪fd放入就绪链表中&＃xff0c;并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替&＃xff0c;但是select和poll在“醒着”的时候要遍历整个fd集合&＃xff0c;而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了&＃xff0c;这节省了大量的CPU时间。这就是回调机制带来的性能提升。

2、select&＃xff0c;poll每次调用都要把fd集合从用户态往内核态拷贝一次&＃xff0c;并且要把current往设备等待队列中挂一次&＃xff0c;而epoll只要一次拷贝&＃xff0c;而且把current往等待队列上挂也只挂一次&＃xff08;在epoll_wait的开始&＃xff0c;注意这里的等待队列并不是设备等待队列&＃xff0c;只是一个epoll内部定义的等待队列&＃xff09;。这也能节省不少的开销。 

综上&＃xff0c;在选择select&＃xff0c;poll&＃xff0c;epoll时要根据具体的使用场合以及这三种方式的自身特点。

1、表面上看epoll的性能最好&＃xff0c;但是在连接数少并且连接都十分活跃的情况下&＃xff0c;select和poll的性能可能比epoll好&＃xff0c;毕竟epoll的通知机制需要很多函数回调(复杂的设计必然存在更多的中间处理环节,产生必要的开销)。但是当遇到大量的idle- connection&＃xff0c;就会发现epoll的效率大大高于select/poll。

2、select低效是因为每次它都需要轮询。但低效也是相对的&＃xff0c;视情况而定&＃xff0c;也可通过良好的设计改善 

IO多路复用之select总结
IO多路复用之poll总结
IO多路复用之epoll总结

Linux IO模式及 select、poll、epoll详解