## epoll简介
通常来说,实现处理tcp请求,为一个连接一个线程,在高并发的场景,这种多线程模型与Epoll相比就显得相形见绌了。`epoll`是linux2.6内核的一个新的系统调用,`epoll`在设计之初,就是为了替代`select, poll`线性复杂度的模型,epoll的时间复杂度为O(1), 也就意味着,`epoll`在高并发场景,随着文件描述符的增长,有良好的可扩展性。
* `select`和`poll`监听文件描述符list,进行一个线性的查找 O(n)
* `epoll`: 使用了内核文件级别的回调机制O(1)
## 关键函数
* `epoll_create1`: 创建一个epoll实例,返回文件描述符
* `epoll_ctl`: 将监听的文件描述符添加到epoll实例中,实例代码为将标准输入文件描述符添加到epoll中
* `epoll_wait`: 等待epoll事件从epoll实例中发生, 并返回事件以及对应文件描述符
## epoll 关键的核心数据结构如下:
~~~cpp
typedef union epoll_data
{
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
struct epoll_event
{
uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
~~~
## epoll高效原理
`epoll`使用`RB-Tree`红黑树去监听并维护所有文件描述符,`RB-Tree`的根节点
调用epoll_create时,内核除了帮我们在epoll文件系统里建了个file结点,在内核cache里建了个**红黑树**用于存储以后epoll_ctl传来的socket外,还会再建立一个list链表,用于存储准备就绪的事件.
当**epoll_wait调用时,仅仅观察这个list链表里有没有数据即可。有数据就返回,没有数据就sleep,等到timeout时间到后即使链表没数据也返回。所以,epoll_wait非常高效**。而且,通常情况下即使我们要监控百万计的句柄,大多一次也只返回很少量的准备就绪句柄而已,所以,epoll_wait仅需要从内核态copy少量的句柄到用户态而已.
那么,这个准备就绪list链表是怎么维护的呢?
当我们执行epoll_ctl时,除了把socket放到epoll文件系统里file对象对应的红黑树上之外,还会给内核中断处理程序注册一个回调函数,告诉内核,如果这个句柄的中断到了,就把它放到准备就绪list链表里。所以,当一个socket上有数据到了,内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。
epoll相比于select并不是在所有情况下都要高效,