IO复用的三种方法(select,poll,epoll)深入理解
(一)IO复用是Linux中的IO模型之一,IO复用就是进程告诉内核需要监视的IO条件,使得内核一旦发现进程指定的一个或多个IO条件就绪,就通过进程处理,从而不会在单个IO上阻塞了,Linux中,提供了select、poll、epoll三种接口来实现IO复用
(二)select:
缺点:
单个进程能够监视的文件描述符的数量存在最大限制,通常是1024。由于select采用轮询的方式扫描文件描述符,文件描述符数量越多,性能越差;
内核/用户空间内存拷贝,select需要大量的句柄数据结构,产生巨大开销;
select返回的是含有整个句柄的数组,应用程序需要遍历整个数组才能发现哪些句柄发生事件;
select的触发方式为水平触发,应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作,那么下次select调用还会将这些文件描述符通知进程;
(三)poll:
使用链表保存文件描述符,没有了文件描述符的限制,但其他的三个缺点依然存在
(四)epoll:
上面所说的select缺点都不存在,epoll使用了一个文件描述符管理了多个文件描述符。拿select模型为例,假设我们服务器需要支持100万个并发链接,则在_FD_SETSIZE为1024的情况下,则我们至少需要开辟1K个进程才能实现100万的并发连接,除了进程上下文切换的时间消耗,从内核到用户空间的拷贝,数据轮询,是系统难以承受的,因此,基于select模型的服务器程序,要达到10万级别的并发访问,是一个很难完成的任务。
epoll的设计与select完全不同,epoll通过在Linux内核申请一个简易的文件系统(文件一般使用什么数据结构实现?B+树),把原先的select/epoll调用分为3个部分:
调用epoll_create()建立了一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
调用epoll_ctl()向epoll对象添加这100万个连接的套接字(ip地址+端口号)
调用epoll_wait()收集发生事件的连接
epoll机制实现思路:
当某一进程调用epoll_create()方法时,Linux内核会创建一个eventpoll结构体,这个结构体中有两个成员与epoll的使用密切相关
struct eventpoll
{
//............
//红黑树的根节点,这棵树的每个节点代表着用户告诉内核需要监控的文件描述符
struct rb_root rbr;
//调用epoll_wait()函数后满足条件的文件描述符会被添加到rdlist中,也是后期返回用户的事件
struct list_head rdlist;
};
每一个epoll对象都有一个独立的eventpoll结构体,用于存放epoll_ctl()方法向epoll对象中添加进来的事件,这些事件都会存放在这颗红黑树中,红黑树的增删查改的效率为logn,其中n为数的高度。
而所有添加到epoll对象中的事件都会与设备(网卡)驱动程序建立回调关系,当相应的事件发生时会调用这个回调方法,这个回调方法在内核中叫做ep_poll_back,它会将发生的事件添加到rdlist双链表中。
在一个epoll对象中,对于每一个事件,都会建立一个epitem结构体如下:
struct epitem
{
struct rb_node rbn;//红黑树节点
struct list_head rdllink;//双向链表节点
struct epoll_filefd ffd;//事件句柄信息
struct eventpoll *ep;//指向其所属的event对象
struct epoll_event event;//期待发生的事件类型
};
当调用epoll_wait()检查是否有事件发生时,只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可,如果rdlist不为空,则把发生的事件复制到用户态,同时将事件数量返回给用户。
从上面的讲解可知:通过红黑树和双链表数据结构并结合回调机制,才有如此高效的epoll
epoll在使用ET模式的时候一定是非阻塞的,如果是阻塞的话,一个任务监控多个文件描述符时,当一个描述符阻塞就会使其他的描述符所在的任务失败(饿死)
————————————————
版权声明:本文为CSDN博主「_kean」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/C1029323236/java/article/details/90551959