应用排查

应用排查（Application Troubleshooting）是后端工程师的核心能力之一。无论服务是 CPU 飙高、内存泄漏、事件循环卡死，还是接口响应缓慢，都需要一套科学的排查方法论和可靠的工具链，而不是靠猜和加 Log。

本文作为「应用排查」篇章的概览，主要梳理排查过程中脱离具体场景的通用方法论、核心工具选型与常见误区。

面试高频问题概览：
生产环境 CPU 飙到 100%，你的排查思路是什么？
Node.js 进程内存持续增长不释放，如何定位泄漏点？
什么是火焰图？怎么读懂 CPU 火焰图和 Heap 火焰图？
clinic.js 的 doctor / flame / heap 三件套各自解决什么问题？
同步代码在事件循环中会造成什么后果？如何规避？

排查的「分诊与专科」思维

医院里看病要先分诊（看哪个科），再做专项检查。Node.js 性能排查也应遵循「先分诊、后专科」的链路，避免一上来就扎进代码里盲目加 console。

1. 第一步：宏观把脉（指标层）

通过系统监控指标圈定问题大方向：

CPU 维度：top / htop 查看进程 CPU 占用，是用户态高还是内核态高。
内存维度：RSS、Heap Used、Heap Total 曲线，是缓慢上涨（疑似泄漏）还是锯齿状（正常 GC）。
事件循环维度：Node.js 独有的核心指标。clinic doctor 的 Event Loop Delay 曲线能直接告诉你主循环被阻塞了多少 ms。
句柄维度：_getActiveHandles() 查看活跃句柄数是否随请求线性增长（连接泄漏的典型征兆）。

2. 第二步：专科定位（代码层）

根据第一步的指标，对症下药选择专项工具：

现象	推荐工具	排查目标
CPU 飙高 / 主线程卡	`clinic flame` / `0x`	找到最宽的函数平顶
内存持续增长	`clinic heap` + Heap Snapshot	找到贯穿时间轴的高频分配点
不知道哪里有问题	`clinic doctor`	让 AI 帮你下诊断书
接口慢但 CPU 不高	`clinic flame` 的 Off-CPU 视图	看线程阻塞在哪个 I/O 或锁上
优化前后对比	Differential 火焰图	同一个调用栈在两次采样中的宽度变化

顺口溜总结： 出事切莫瞎猜，doctor 先拉出来；卡死算不过来，flame 看谁在嗨；爆仓内存漏掉，heap 抓代码死角。

3. 第三步：闭环验证

修改代码后，必须重新跑同样的压测场景进行回归验证。性能优化最忌讳「自我感觉良好」：

修 CPU 问题：对比 flame 报告中异常方块的宽度是否收窄。
修内存问题：对比两次 heap 报告中同一分配点的占比变化，并观察 RSS 曲线是否趋于平稳。
修完后必须重新跑 doctor，确认 Event Loop Delay 降到了正常水平（通常 < 几 ms）。

火焰图（Flame Graph）阅读心法

火焰图是 Brendan Gregg 发明的、和 perf / bpftrace / 0x / clinic 各种 profiler 配合使用的通用可视化语言。无论是排查 CPU、内存还是 Off-CPU，掌握它都能一通百通。

1. 破除视觉迷思

横向 = 占比，不是时间轴：方块越宽，代表该函数在采样期间占用 CPU / 分配内存的总比例越高。函数块按字母等非时间顺序排列，并不是从左到右依次执行的。
纵向 = 调用栈：下层是调用方（Caller），上层是被调用方（Callee）。顶部的边缘就是正在执行的「叶子函数」。
颜色：默认按分类着色，没有特殊含义。Clinic 中可能将引擎判定为可疑的块标为红/橙色以示警告。

2. 看图口诀

找「平顶」（Plateau）：顶层如果有一个很宽的平面，说明这个函数本身执行了很久，或被高频调用，是纯粹的消耗大户。
找「深谷」（Deep Tower）：调用栈非常深，说明调用链路过长（可能存在过度封装）。
Node.js 的「断层」现象：因为异步回调会被扔回事件循环，下一次执行时是全新的栈，所以纯异步 I/O 场景下火焰图往往「矮胖」；而 CPU 密集的同步代码会形成「极高极宽」的尖峰。

3. 四种火焰图，看场景选择

类型	看什么	适合排查
CPU（最经典）	哪个函数消耗 CPU	进程 CPU 高、主线程卡顿
Heap / 内存	哪段代码在分配对象	内存泄漏、RSS 增长
Off-CPU	线程阻塞在哪儿	接口慢但 CPU 不高
Differential	两次采样的差异	优化前后对比

内存排查的三阶策略

内存问题比 CPU 问题更隐蔽，往往要持续观察几天才能复现。这里推荐一套递进式的排查策略，避免一上来就导出几百 MB 的 Heap Snapshot 把自己看晕。

第一阶：clinic heap 定位代码行 通过堆分配火焰图，找到是哪个函数（如 leakCache 里的 lists.push）在疯狂分配。看「贯穿整个时间轴的最宽方块」 —— 这就是持续分配且未被回收的泄漏元凶。
第二阶：内存采样曲线量化速度 火焰图只能告诉你「哪里漏」，但不知道「漏多快」。通过 RSS / Heap Used 的采样脚本（sample-mem.sh）画出曲线斜率，能让你判断这是「温水煮青蛙」式的慢泄漏，还是「分分钟爆掉」的急性泄漏。
第三阶：Heap Snapshot 锁定对象 如果火焰图不能找出根本原因（例如对象被闭包或全局 Map 持有），再导出 Chrome DevTools 的堆快照：
- Summary 视图：看 Retained Size，找到真正占用大量内存的「容器」对象。
- Comparison 视图：看两次快照间新分配的对象（注意：仅显示新分配，若容器快照前已存在则需走 Summary 视图）。
- Retainers 保留树：从根节点追踪谁在持有这个对象，找到代码级的持有者（如 globalThis.cache.set('user_42', data)），泄漏链条就彻底暴露了。

经典灾难现场：主线程阻塞与「宽平顶」

在生产环境中，最常见的性能灾难就是在主线程中同步处理密集计算（如加密、大数组解析、大 JSON 序列化、复杂正则）。

1. 灾难的火焰图表现

在 clinic flame 报告中，你会看到某个函数（例如 JSON.parse 或自定义的 calculateHeavyTask）在顶层形成一个极宽的红色/黄色「平顶」，横向宽度接近 90% ~ 100%。这意味着主线程死死卡在这个同步函数里，事件循环被完全阻塞，其他网络请求全部排队超时。

2. 「伪异步」陷阱

很多开发者企图用 Promise 包装同步计算来解决问题：

// 错误示范：这依然会阻塞主线程！
app.get("/compute", async (req, res) => {
  const result = await new Promise((resolve) => {
    resolve(calculateHeavyTask(40)); // ❌ 只是外表套了 Promise
  });
  res.send(`Result: ${result}`);
});

这是无效的！ Promise 只改变了控制流的传递方式（微任务机制），但并没有创造新线程。只要计算逻辑还是纯 JavaScript 的同步代码，它依然会死死霸占独一无二的主线程。

3. 破局之道：Worker Threads

面对 CPU 密集型任务，唯一的银弹是剥离主线程。Node.js 10.5+ 提供的 worker_threads 模块允许在 JS 层面真正地创建多线程。

优化后再次观察火焰图，你会看到神奇的变化：

占满屏幕的红色宽平顶彻底消失。
火焰图整体变得矮且分散，呈现大量网络 I/O 的浅蓝色/灰色小矮块。
因为 worker_threads 跑在 V8 的另一个独立实例中，默认的火焰图只采样主线程，因此子线程的耗时计算在主图上「隐身」了。

生产环境提示：频繁地 new Worker() 会带来创建和销毁线程的额外开销。在真实的生产项目中，通常会引入线程池（Worker Pool），例如使用开源库 piscina，预先创建好固定数量的常驻子线程，重复利用它们来处理密集的计算任务。

句柄泄漏与僵尸定时器

除了 CPU 和内存，Node.js 还有一类特有的「退出异常」问题——句柄泄漏。当进程无法正常退出，或者退出耗时远超预期时，往往就是活跃句柄在作祟。

1. Handle vs Request

libuv 层面有两个核心概念，新手很容易混淆：

Handle（句柄）：长期存在的资源，如 uv_timer_t（定时器）、uv_tcp_t（Socket）。它会阻止进程退出。
Request（请求）：短生命周期的操作，如 fs.read、DNS 查询、crypto 计算。它不会阻止进程退出。

常见误区：你以为 setTimeout(() => {}, 1000) 是个小操作，但如果忘了 clearTimeout，它会变成一个 uv_timer_t 句柄 hold 住事件循环，导致进程退出时被卡 5 秒。

2. 排查利器

Node.js 提供了两个调试用 API（注意下划线开头，属内部 API）：

process._getActiveHandles()：列出当前所有活跃句柄。注意：Timer 不会出现在这个列表中（这是 V8 层与 libuv 层的差异）。
process._getActiveRequests()：列出所有进行中的短周期请求。

在生产环境中，进程退出异常 99% 是由 Handle 泄漏引起（特别是未关闭的 Socket、未解绑的事件监听器、僵尸定时器），而不是短周期的 Request。

3. 经典案例

// 看似无害的代码
setTimeout(() => {
  console.log("fire after 5s");
}, 5000);

如果进程还有其他工作想立即退出，会发现 process.exit(0) 之后主进程仍然存活 5 秒——因为定时器持有了事件循环，事件循环有活跃句柄就不退出。正确做法是依赖事件循环自然判定，或者在退出前 clearTimeout。

压力测试：没有负载就没有真相

所有性能分析工具（clinic、0x、火焰图）都必须在有真实负载的情况下才能采集到有效数据。单纯启动项目而不发送请求，火焰图是空的或全是无意义的噪音。

常用压测工具

autocannon：Node.js 生态最常用的压测工具，安装简单，autocannon -c 100 -d 10 http://localhost:3000/api 就能发起 100 并发持续 10 秒。
wrk：C 语言编写的高性能压测工具，Lua 脚本可扩展，但需要 Homebrew/apt 安装。
k6：现代压测工具，使用 JS 编写测试场景，适合 CI/CD 集成。

一键式脚本化

在真实项目中，建议将 clinic + 压测 + 报告生成 封装成 shell 脚本（如 run-clinic-flame.sh），避免每次手动敲一长串命令，且能处理 Ctrl+C 后自动生成 HTML 报告的边界情况。

避坑指南：常见排查误区

在多年的性能排查实战中，新手最容易掉进这些坑：

不要只看平均延迟：avg latency 漂亮不代表服务健康。P99 / P999 才是真实体验，长尾请求往往是定时炸弹。
不要在生产环境开 --inspect：调试端口暴露在公网是严重的安全事故。需要采样时，优先用 clinic 这样的「生产安全」工具。
不要相信自己的直觉：觉得「这个函数不可能慢」是没用的，火焰图会无情地打脸。
不要忽视采样噪音：node --inspect 启动时输出的 Debugger listening 会干扰内存采样脚本，需要 grep 过滤。
不要追求银弹：CPU 密集型用 Worker，I/O 密集型用异步 + 连接池，没有一种方案能解决所有问题，对症下药才是关键。

文章索引

本篇章将通过一系列实战文章，深入探讨上述方法论的具体落地：

Node性能分析与火焰图实践：详细讲解 clinic 三件套的使用方法、火焰图的阅读心法，并通过「同步阻塞 → Worker 优化」的完整案例还原一次真实的性能调优闭环。

排查的「分诊与专科」思维​

1. 第一步：宏观把脉（指标层）​

2. 第二步：专科定位（代码层）​

3. 第三步：闭环验证​

火焰图（Flame Graph）阅读心法​

1. 破除视觉迷思​

2. 看图口诀​

3. 四种火焰图，看场景选择​

内存排查的三阶策略​

经典灾难现场：主线程阻塞与「宽平顶」​

1. 灾难的火焰图表现​

2. 「伪异步」陷阱​

3. 破局之道：Worker Threads​

句柄泄漏与僵尸定时器​

1. Handle vs Request​

2. 排查利器​

3. 经典案例​

压力测试：没有负载就没有真相​

常用压测工具​

一键式脚本化​

避坑指南：常见排查误区​

文章索引​