IO 模型与多路复用

epoll 快在哪：

1. epoll_create 在内核建一个 eventpoll 对象，里面一棵红黑树存所有注册的 fd，增删改是 O(log n)
2. 每个 fd 注册时挂一个回调，网卡中断把数据送进内核缓冲区后，回调把对应的 epitem 挂到就绪链表 rdllist
3. epoll_wait 只看这条链表，有多少就绪返回多少，不需要遍历全量 fd，也不用每次把集合拷进内核

所谓 O(1)，准确说是「与总连接数无关，只与就绪数有关」。连接都很活跃时，epoll 和 select 的差距并不大。

LT 与 ET

• LT（水平触发，默认）：只要缓冲区还有数据，每次 epoll_wait 都会通知。写起来安全，忘了读也只会在下一轮再被提醒，代价是可能重复通知。
• ET（边缘触发）：只在状态变化时通知一次。必须配非阻塞 fd，并且一次 read 到返回 EAGAIN 为止，否则剩下的数据不会再触发事件，连接就卡住了。

Nginx 默认用 ET 减少唤醒次数；Redis 用的是 LT 风格，逻辑简单不易错。选 ET 是在拿实现复杂度换系统调用次数。

libuv 怎么抹平平台差异

libuv 在 uv__io_poll 里按平台编译不同实现，上层只认 uv_loop_t。注意 Windows 的 IOCP 是「完成端口」，回调时数据已经拷好，语义比 epoll 更接近真异步；Linux 上的普通文件读写则被扔进线程池，因为 epoll 管不了普通文件（它永远就绪）。

事件循环的六个阶段，本质是把 epoll 的等待点嵌进 poll 阶段：

每个阶段之间会清空 process.nextTick 和微任务队列，这就是「微任务优先于下一阶段」的实现位置。

代码：阻塞与非阻塞的真实差别

// 阻塞版：整个事件循环停在这，期间所有请求排队
import { readFileSync } from 'node:fs'
const t0 = performance.now()
const buf = readFileSync('./access.log') // 文件多大就占多大内存
console.log('sync', (performance.now() - t0).toFixed(1), 'ms', buf.length)

// 非阻塞版：交给 libuv 线程池，主线程立刻继续
import { readFile } from 'node:fs/promises'
readFile('./access.log').then((buf) => console.log('done', buf.length))
console.log('这一行先打印') // 一定先于 done

网络 IO 则是另一条路径，不需要线程池：

import net from 'node:net'

// 单线程处理上万连接：连接不占线程，epoll 告诉你哪个 fd 可读
const server = net.createServer((socket) => {
  socket.on('data', (chunk) => socket.write(chunk))
})
server.listen(3000)

createServer 把 listening fd 注册进 epoll，epoll_wait 返回可读事件时才回调 connection。这一步如果换成阻塞的 accept 循环，并发数就直接等于线程数。

浏览器为什么不让你管这些

页面里写 fetch 时，DNS、TCP、TLS、HTTP 解析全在网络进程里完成，那里有自己的线程池和事件循环。渲染进程只拿到一个 Promise，网络进程通过 IPC 把响应体送过来再 resolve。

分层的好处：epoll/kqueue 的平台差异、连接池复用、HTTP/2 多路复用都被关在浏览器内部；坏处是你无法控制连接调度，max-connections-per-host（Chrome 是 6）这类限制只能靠域名分片或升级协议绕开。

常见误区

很多人以为 epoll 一定比 select 快。 实际上连接数少且全部活跃时，两者都是 O(n) 且常数很小，epoll 的优势只在「大量连接里只有少量活跃」的场景，比如 IM、推送网关。

很多人以为 Node 的异步 IO 都是内核异步。 实际上 Linux 上普通文件读写是 libuv 线程池里的阻塞调用，只有网络走 epoll，真正的内核异步要等 io_uring（Node 尚未默认启用）。

面试怎么答

同步/异步与阻塞/非阻塞的区别？ 阻塞与否看调用后线程是否被挂起，同步与否看数据拷贝由谁完成。epoll 是同步非阻塞：等待阶段不占线程，但 read 拷贝数据时仍要自己阻塞完成。只有 io_uring、IOCP 这类拷贝也由内核完成后通知的才算异步 IO。

epoll 为什么高效？ 内核用红黑树保存注册的 fd，只在 epoll_ctl 时增删一次；fd 就绪时由回调挂进就绪链表，epoll_wait 只取链表，开销与总连接数无关。select/poll 每次调用都要把整个集合拷进内核并线性扫描。

LT 和 ET 怎么选？ LT 有数据就重复通知，代码简单不易漏读；ET 只在状态变化时通知一次，必须非阻塞读直到 EAGAIN，能减少唤醒次数。高并发网关常用 ET，业务服务用 LT 更稳。

关联阅读

• 进程与线程：为什么主线程挂起不会占用 CPU
• 文件系统与页缓存：普通文件为什么用不了 epoll，只能靠线程池
• 作业队列与事件循环：浏览器侧六个任务源与渲染时机