poll、epoll 与事件等待
这页讲的是：当程序要同时盯很多文件描述符、socket 或管道时，Linux 不会让它一个个傻等，而是提供一套“哪些东西已经就绪”的事件等待模型。学这页的重点，是理解它不是单纯接口差别，而是在组织大量等待关系。
这块是什么
poll、epoll 与事件等待，讲的是应用在面对多个可能阻塞的对象时，如何不是挨个试探、也不是给每个连接都配一条线程，而是把“谁准备好了、谁还要等”交给内核来集中组织。它把等待从单个对象提升到一组对象的协调问题。
可以把它理解成：你不是守着几十个窗口轮流探头看，而是去大厅看统一叫号屏，哪个窗口有结果，屏幕就告诉你先去哪里。
它负责什么
组织多对象等待
- 让程序一次等多个文件描述符
- 减少轮询和盲等
- 把等待从“单点堵塞”变成“整体观察”
- 让大量连接场景更可管理
汇报就绪事件
- 告诉应用哪些对象已经可读可写
- 让等待和实际 I/O 推进重新接上
- 避免应用反复空试
- 把“条件变了”正式反馈出来
衔接用户态与内核等待模型
- 把等待队列和唤醒逻辑暴露成用户可用接口
- 让大量网络与 I/O 服务更高效
- 避免“一连接一线程”过早失控
- 把高并发等待组织成系统能力
为什么不能靠挨个试或一人守一个
| 做法 | 会怎样 | 事件等待模型的价值 |
|---|
| 挨个轮询很多对象 | 会浪费大量 CPU 在空转检查上。 | 只在真正有事件时再推进处理。 |
| 每个连接一条线程 | 连接一多，调度和资源成本会快速上升。 | 让一个执行流也能盯住很多等待对象。 |
| 等待关系散落在应用里自己硬编排 | 逻辑会越来越乱，也很难扩展。 | 把“谁准备好了”交给内核统一组织。 |
| 事件来了还不知道先处理谁 | 应用容易被大量状态判断拖住。 | 就绪通知让推进顺序更清晰。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| poll | 等待一组对象状态变化的一类接口思路。 |
| epoll | 更适合大量连接与高并发等待场景的一种组织方式。 |
| 事件就绪 | 不是事情做完了，而是某个对象现在已经到了可继续推进的时机。 |
| 文件描述符 | 用户态拿来代表文件、socket、管道等内核对象入口的句柄。 |
| 事件循环 | 围绕“等事件、拿结果、推进处理、再继续等”的运行节奏。 |
为什么重要
- 它解释了高并发网络服务为什么不一定要靠海量线程才能工作。
- 它把等待队列、唤醒和用户空间 I/O 模型真正连到了一起。
- 理解这层后，你会更容易看懂“事件驱动”为什么在 Linux 上这么常见。
- 很多服务端性能与扩展性问题，根子都和等待模型选型有关。
常见误解
- 误解一：poll 和 epoll 只是 API 语法不同。实际上背后是不同规模场景下的等待组织方式。
- 误解二：事件就绪就等于数据处理已经完成。实际上它只是在告诉你“现在可以继续干了”。
- 误解三：这只是网络编程话题。实际上它深深依赖内核等待、唤醒和对象模型。
它不负责什么
- 它不替代真正的 I/O 操作，只负责告诉你什么时候值得去做。
- 它不创造事件本身，真正的状态变化仍然来自文件、socket、驱动和内核子系统。
- 它不等于完整并发模型，但会显著影响应用如何组织并发等待。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 系统调用与用户空间边界 | 这是用户态把内核等待模型拿来直接用的一条重要边界接口。 |
| 等待队列、睡眠与唤醒 | 用户可见的事件等待，底下常是等待与唤醒关系在支撑。 |
| 网络数据路径 | 高并发 socket 服务最常见地依赖这种等待模型。 |
| 调度器 / 并发 | 等待方式会影响线程数量、阻塞方式和整体调度压力。 |
读完这页后，你应该能回答
- 为什么高并发服务不想靠“每个连接一条线程”硬撑？
- 为什么事件等待模型本质上是在组织大量等待关系？
- 为什么 poll/epoll 会把用户态和内核等待机制紧密接起来？
后面适合继续问：epoll 为什么更适合大量连接？事件就绪和真正处理完之间最容易混淆在哪？等待队列是怎么把这些事件模型托起来的？