极客工场

Appearance

共 1,417 字预计阅读约 5 分钟

async/await 与事件循环阻塞：一个慢调用为何拖垮全局 ​

更新时间：2026-09-18。用了 async/await 不等于自动高并发。事件循环模型用一个线程 + 非阻塞 IO 扛住海量连接，前提是每个任务都「短小、遇到 IO 就主动让出」。一旦某段代码占着线程不让——CPU 密集计算、误用同步阻塞调用——整个进程的所有请求都会被卡住。本文讲清让出机制、阻塞特征与排查修复。排查工具方法论与 perf 火焰图 相通。

本文要回答的问题 ​

  • 单线程事件循环为什么能扛高并发？它的并发边界在哪？
  • await 到底什么时候让出线程？为什么 await 一个同步函数没用？
  • 哪些写法会阻塞事件循环（CPU 密集、同步 IO、大 JSON、灾难性正则）？
  • event loop lag 怎么测？如何定位是哪段代码在堵？
  • 修复为什么是「移出线程/拆小任务/限流」而不是多加 await？

一、模型：一个线程，IO 时让出 ​

async/await 与事件循环阻塞：一个慢调用为何拖垮全局 示意图（第 2 张）

每来一个 IO 事件，对应回调被压入调用栈同步执行到结束；遇到真正的异步 IO（网络/磁盘由内核或线程池接管），代码 await 挂起当前协程，线程立刻回去执行下一个回调。高并发来自「等待 IO 期间线程不空转、去服务别的请求」，而不是同时执行多段 CPU 代码。

二、await 的误区 ​

javascript
// ✅ 真正的异步 IO：等待期间线程去服务别的请求
const rows = await db.query('SELECT ...');

// ❌ 看起来 await，实际是同步重计算，函数内部没有让出点
async function compute() {
  let s = 0;
  for (let i = 0; i < 5e9; i++) s += Math.sqrt(i); // await 救不了
  return s;
}
await compute(); // 计算期间事件循环照样卡死

// ❌ 误用同步文件 API
const data = fs.readFileSync('/huge.json');   // 阻塞线程
// ✅
const data = await fs.promises.readFile('/huge.json');

await 只是把「等待 Promise」写得像同步，只有 Promise 背后真的把工作交给内核/线程池并在完成时再排队回调，线程才会让出。对一个纯 CPU 函数加 async/await 毫无作用。

三、典型阻塞源 ​

类型例子现象
CPU 密集加解密、压缩、大 JSON.parse/stringify、排序、模板渲染P99 全局抖动、lag 飙升
灾难性正则嵌套量词导致指数回溯（ReDoS）偶发单次卡数百 ms~秒
同步/阻塞 IO*Sync API、某些驱动的 DNS 同步解析IO 期间整个进程停
大量微任务递归 process.nextTick/Promise 连环宏任务（含 IO 回调）饿死
线程池打满所有 crypto/fs/dns 共用 libuv 默认 4 线程异步但排队，表现为 IO 集体变慢

四、定位：先量化 lag，再抓现场 ​

javascript
// 1) event loop lag：定时器「应被唤醒」与「实际唤醒」的差
let last = Date.now();
setInterval(() => {
  const now = Date.now();
  const lag = now - last - 100;
  if (lag > 50) console.warn('eventloop lag', lag, 'ms'); // 被同步代码耽误
  last = now;
}, 100);

// Node 内置监控
import { monitorEventLoopDelay } from 'perf_hooks';
const h = monitorEventLoopDelay(); h.enable();
// h.max / h.percentile(99) 纳秒

// 2) 异步上下文追踪
import { AsyncLocalStorage } from 'async_hooks'; // 串联一个请求内所有异步调用
  • lag 周期性尖刺 → 找那段时间在跑的同步任务（定时任务、报表、大响应序列化）。
  • 用 CPU 采样/火焰图（Node 用 --prof/0x/clinic flame，或 perf record，方法同 perf 火焰图）抓占用 CPU 最宽的栈，定位是 JSON、正则还是加解密。
  • libuv 线程池打满表现为 fs/crypto/dns 一起慢，可调大 UV_THREADSIZE 但治标，治本是减少这类调用或外部化。

五、修复手段 ​

javascript
// 1) 把 CPU 重活移出事件循环：worker_threads / 独立服务 / 队列消费者
const { Worker } = require('worker_threads');
function hashAsync(buf){ return new Promise((res,rej)=>{ /* 交给 worker */ }); }

// 2) 把超大同步任务切片，每片之间让出（注意仅缓解、不加速总耗时）
async function processBatch(items){
  for (let i=0;i<items.length;i+=500){
    doChunk(items.slice(i,i+500));
    await new Promise(r=>setImmediate(r)); // 每片让出，给 IO 回调机会
  }
}
  1. 移出线程：CPU 密集交给 worker_threads（Node）/ 进程池 / 独立计算服务 / 消息队列异步消费，事件循环只做 IO 编排。
  2. 切片让出：必须在本进程做的大任务分批，用 setImmediate（Node）或 asyncio.sleep(0)（Python）周期性让出。
  3. 杜绝同步阻塞 IO：全链路用异步驱动，注意 DNS、部分日志库、加解密的同步路径。
  4. 限流与超时：对能触发重计算的接口（复杂查询、大导出）限流、分页、设 deadline，避免单请求拖垮全局——这与 服务熔断、降级与隔离 的限流隔离思想一致。
  5. 避开 ReDoS：正则不用嵌套量词，对用户输入长度封顶。

六、坑与对照 ​

  1. 以为加了 async 就是非阻塞。 同步重计算加 async 无用，要看有没有真正的异步 IO 让出点。
  2. 只看平均延迟。 事件循环阻塞伤的是所有请求的 P99/P99.9，必须看长尾与 lag 分布。
  3. 无脑调大 libuv 线程池。 线程多了上下文切换也多，且解决不了主循环上的 CPU 阻塞。
  4. 微任务无限递归饿死 IO。 nextTick/Promise 环会让宏任务迟迟不执行。
  5. 阻塞 GC 被误判。 大对象分配导致长 GC 停顿也表现为 lag，需要结合堆分析（JVM 侧见 faq/jvm-full-gc-frequent）。

下游变慢拖垮线程池的隔离治理见 服务熔断、降级与隔离；从容量到缓存异步的整体思路见 高并发系统设计；消息削峰见 Kafka 与 RabbitMQ 选型。

总结 ​

async/await 与事件循环阻塞：单线程事件循环靠「回调同步执行到让出点、IO 等待时去服务别的请求」实现高并发，所以栈上任何不结束的同步代码（CPU 密集计算、*Sync 阻塞 IO、大 JSON、回溯型正则、连环微任务）都会卡住进程内所有请求；await 只在背后是真正异步 IO 时才让出，对纯 CPU 函数无效；排查先量 monitorEventLoopDelay/定时器 lag 的长尾尖刺，再用 --prof/火焰图抓最宽 CPU 栈、用 AsyncLocalStorage 串联请求；修复是把重活移到 worker/独立服务/MQ、任务切片用 setImmediate 让出、全链路异步驱动并对重接口限流超时，而不是多写几个 await。