别再只背“红黑树+就绪链表”了，带你看透 epoll 的内核并发收割协议

你大概率知道 epoll 用了红黑树和就绪链表——几乎每篇讲 epoll 的文章都会告诉你这两个数据结构，然后画一张示意图，箭头从红黑树指向就绪链表，配上"高效"两个字就结束了。但如果我问你：当 epoll_wait 正在把就绪链表里的事件拷贝给用户态的那几微秒里，一个新的网络包到达了，这个事件会被放到哪里？你可能会下意识地回答"放到就绪链表里"——这个回答是错的。内核在 epoll_wait 收割事件期间，会把就绪链表整个"摘走"，然后启用一个你在几乎所有 epoll 教程里都看不到的第三个数据结构——ovflist（overflow list，溢出链表）——来暂存这段时间内新到达的事件，等收割完成后再把溢出链表里的事件合并回就绪链表。这个设计的精妙之处在于，它让 epoll_wait 在收割事件时不需要一直持有自旋锁，从而避免了在高并发场景下回调函数被阻塞在锁上导致网卡中断处理延迟飙升的问题。

select/poll 的 O(n) 之痛——epoll 要解决的根本问题

在深入 epoll 的内核实现之前，你需要先理解它到底在解决什么问题。

select的核心数据结构是三个fd_set位图——分别对应读、写、异常三种事件——每次调用select时，你必须把这三个位图从用户态完整拷贝到内核态，内核遍历每一个被置位的 fd 检查其状态，然后把结果写回位图，再把位图拷贝回用户态。这意味着即使你监控了 10000 个连接但只有 3 个有数据到达，内核仍然要遍历全部 10000 个 fd，用户态仍然要拷贝全部位图。更致命的是，