Node.js 服务 CPU 飙高怎么排查？

详细解析#

常见原因#

正则回溯：JS 的正则引擎是回溯式的，嵌套量词这类写法（如 (a+)+$）在匹配失败时会尝试指数级数量的组合，一段很短的恶意输入就能把主线程卡住几秒以上。防御办法：避免嵌套量词和有重叠的分支；对输入先做长度限制；用户可控的正则交给 RE2 这类线性时间引擎（如 npm 的 re2 包）；用 eslint 的正则检查插件在开发阶段发现危险写法。

第一步：确认问题在主线程#

• 系统层面：top -H -p <pid> 看是主线程还是其他线程（libuv 线程池、GC 线程）占用高
• 事件循环延迟：perf_hooks.monitorEventLoopDelay() 统计主线程被阻塞的程度，p99 持续升高说明有同步代码长时间占着主线程（原理见 怎么发现事件循环被阻塞）；performance.eventLoopUtilization() 反映事件循环有多大比例的时间在忙
• 关联变更和流量：是发布之后、某个大客户调用之后，还是定时任务触发时开始的

第二步：采样 CPU profile#

.cpuprofile 文件可以直接拖进 Chrome DevTools 的 Performance 面板或 VS Code 打开。

怎么读火焰图#

• 0x 这类工具画的经典火焰图（speedscope 的 Left Heavy 视图同理）：纵轴是调用栈，下面的函数调用了上面的函数；横轴是采样占比，同一个调用栈的样本合并在一起，宽度代表在 CPU 上花的时间，不代表时间先后
• Chrome DevTools Performance 面板显示的是火焰图表（flame chart）：横轴是时间线，调用栈从上往下长，能看到每次调用发生的时刻。要看汇总的热点，切到 Bottom-Up 视图按 Self Time 排序
• 在经典火焰图中找顶部又宽又平的块：它是自己在执行（self time 高），而不是在等子函数，最可能是热点
• 某个业务函数整体很宽、但最上层是 JSON.stringify、RegExp 或 GC 相关的帧，说明时间花在序列化、正则或回收上
• 特殊节点：(idle) 是空闲，大片的 (idle) 说明 CPU 并不忙，问题可能在 I/O 或下游；(garbage collector) 是 GC 时间；(program) 是引擎自身和原生代码中无法归到某个 JS 函数的时间

线上采样的安全做法#

1. 先把目标实例从负载均衡中摘掉，或者挑一个实例单独引流，避免采样影响用户
2. 只采 10～30 秒，采样本身也会增加 CPU 开销
3. 调试端口只监听 127.0.0.1，通过 SSH 隧道访问；不要把 9229 暴露到公网，连上调试端口就能执行任意代码
4. 代码里提供的采样入口要鉴权，或者只在内网的管理端口上开放，并限制并发和频率

代码示例#

import { Session } from 'node:inspector/promises'
import { writeFile } from 'node:fs/promises'
import { monitorEventLoopDelay } from 'node:perf_hooks'
import { setTimeout as sleep } from 'node:timers/promises'

// 事件循环延迟监控：每秒检查一次 p99
const h = monitorEventLoopDelay({ resolution: 20 })
h.enable()
setInterval(() => {
  const p99 = h.percentile(99) / 1e6 // 结果单位是纳秒，转成毫秒
  if (p99 > 100) console.warn(`事件循环延迟 p99=${p99.toFixed(0)}ms`)
  h.reset()
}, 1000).unref()

// 按需采样：只采一小段时间，写成 .cpuprofile 拿到本地分析
export async function captureCpuProfile(ms) {
  const session = new Session()
  session.connect()
  try {
    await session.post('Profiler.enable')
    await session.post('Profiler.start')
    await sleep(ms)
    const { profile } = await session.post('Profiler.stop')
    const file = `cpu-${Date.now()}.cpuprofile`
    await writeFile(file, JSON.stringify(profile))
    return file
  } finally {
    session.disconnect()
  }
}

面试官可能追问#

易错点#

• 分不清两种图：经典火焰图的横轴是采样占比，左右顺序没有意义；DevTools 的火焰图表横轴才是时间线
• 在线上直接把 --inspect 绑定到 0.0.0.0，等于开放了远程执行代码的入口
• 只看平均 CPU：一个请求卡住 2 秒，平均值可能并不高，事件循环延迟的 p99 更能反映问题
• 把 CPU 问题都归结为"Node 不适合计算"：先采样定位，很多时候只是一个正则或一次大 JSON 序列化