epoll(epoll实现原理)

epoll，epoll实现原理？

EPOLL是Linux IO的多路复用的机制，是select/poll的增强版本，在Linux内核fs/eventpoll.c中可以查看epoll的具体的实现。

学习任何组件，首先得知道它有什么数据结构或者数据类型，epoll主要有两个结构体：eventpoll和epitem。epitem是每一个IO对应的事件，比如EPOLL_CTL_ADD操作时，就需要创建一个epitem；eventpoll是每一个epoll所对应的，比如epoll_create就是创建一个eventpoll。

list太多了怎么办？

1，如果已经存在这个大list，获取数据不要全部提取，分页取

2，不要往大list继续塞新数据，可“分片”存多list

3，作为缓存list存热数据，冷数据存db吧

selectpoll和epoll的区别？

select、poll 和 epoll 都是 Linux 系统中网络编程中用于多路复用的 API，但它们在实现上有一些不同：

1. select 和 poll：select 和 poll 都是最早的多路复用机制。它们通过一个函数轮询 (poll) 所有的描述符，并且当其中有一个描述符准备好进行 I/O 时，立即返回准备就绪的文件描述符集合。这种方式的缺点是效率低下，因为轮询是顺序扫描，需要遍历整个 fd_set 集合，并且需要在用户态和内核态之间进行多次数据拷贝。

2. epoll：epoll 是 Linux 2.6 内核中引入的新的多路复用机制，它使用了事件通知的方式。和 select、poll 不同，epoll 的操作系统内核回调机制是基于事件的，只有当有事件到达时才会通知应用程序，这样能够大幅减少无用的轮询。epoll 支持一个进程打开的所有 socket，而不是根据描述符数来进行限制。同时，epoll 还引入了两种操作模式：ET 和 LT。ET 模式表示当一个事件发生并被处理后，不再通知后续事件。LT 模式则反过来，连续通知事件，知道事件被处理完为止。这种方式可以避免某个事件被阻塞而导致其他事件无法及时得到处理的问题。

综上所述，虽然 select 和 poll 是最早的多路复用机制，但是它们存在效率低下的缺点，而 epoll 引入了事件通知机制，只有在有数据到达时才会通知应用程序，大幅提升了效率，同时还具有两种操作模式和支持大量 socket 的特点。因此，在实际的网络编程中，epoll 是首选的多路复用机制。

epoll模型属于哪一部分？

epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

epoll是如何实现高效处理大量句柄的？

epoll的高效就在于，当我们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的句柄给我们用户。这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。

而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已，如何能不高效？！