目录

1. 再看问题的本质，阻塞是万恶之源
2. 说到内核基石，epoll 的实现原理
3. libuv的观点是，跨网站 I/O 多路复用的封装
4. 说到事件循环，单线程的调度中枢
5. 至于完整数据流，从网卡中断到 JS 回调
6. 再看线程池，无法非阻塞时的兜底方案
7. 再看单线程，Worker Threads 与 Cluster
8. io_uring：下一代异步 I/O

问题的本质这方面。阻塞是万恶之源

传统多线程模型的困境

一个 TCP 连接的生命周期：

客户端 SYN → 内核三次握手 → accept 返回 fd → read 等待数据 → 处理 → write → 关闭

如果用同步阻塞模型，read 在数据到达前会挂起线程。要同时服务 N个连接，就需要 N 个线程。每个线程占用 8MB 栈空间，仅栈内存就需要 ~80GB。

从破局思路来看，让内核告诉我们“谁准备好了”

主要思想的观点是。不要主动轮询每个 fd，而是让内核在 fd 就绪时通知我们。这就是 I/O 多路复用——用一个程序调用同时监视多个 fd 的状态变化。

三种程序调用的演进：

其中 K 是就绪 fd 数量。老实说，当连接数大但活跃连接少时epoll 的性能优势是数量级的。

内核基石的观点是，epoll 的实现原理

三个程序调用。三个内核操作

// . 创建 epoll 实例 —— 在内核中创建一棵红黑树 + 一个就绪链表 int epfd = epoll_create1;// . 注册/修改/删除监视的 fd —— 将 fd 插入红黑树，同时注册回调 epoll_ctl;// . 等待事件 —— 阻塞直到有 fd 就绪，返回就绪事件数组 int nfds = epoll_wait;

内核数据结构概览

User Pain Point: 你可能想知道为什么 Node.js 能够在单线程下处理成千上万连接？主要就在这里——所有网络事件都被放进了这棵红黑树和就绪链表里等待被唤醒。只需一次 system call，你就能得到所有可读写文件描述符！ 无须为每个请求分配独立堆栈。说起来，这样才能真正做到“高并发”。如果你为每个请求分配新栈，那你很快会发现自己的服务器崩溃。因为 8MB × N 直接爆掉了。话说回来，

Epoll_ctl 内核实现细节

User Pain Point: 立即把对应 epitem 放进 ready 列表。并唤醒等待中的进程或线程。没有它，你只能像老式 select 那样轮询，效率低得离谱。

再看libuv，跨网站 I/O 多路复用封装

Pain point: “我开发跨网站应用。该怎么保证 Node.js 在 Windows、Linux、macOS 上都有一样高效？”

• AWS Linux 和 Debian 均使用 epoll_create1。macOS 使用 kqueue,Windows 使用 IOCP；libuv 会根据编译环境自动选择最优后端，零运行时开销.
• C++层通过 .
• The key is that libuv abstracts all those details into a single API so developers can just write asynchronous code once and it will work everywhere.

事件循环这方面。单线程的调度中枢

Pain point: “我想知道 Node.js 为何能在单一 JavaScript 引擎实例里完成这么多任务。”

• The event loop runs in C++ ) and drives libuv's uv_run. It has six stages that handle timers,pending callbacks。idle/prepare tasks,poll,check and close callbacks.

再看完整数据流，从网卡中断到 JS 回调

Pain point: “你是否曾经好奇，从网络包落地到底触发使用者代码回调，需要经过多少层？” 以下步骤将帮你一步步追踪。".

线程池 ：无法非阻塞时的兜底方案