标签: async-profiler

凌晨 3 点，你被监控告警吵醒：线上某核心服务 CPU 使用率突破 95%。用户开始反馈接口超时，此时你只有 15 分钟时间，必须在故障扩散前定位到具体的代码行。本文带你走完从告警到代码行的全链路定位过程。

一、CPU 飙升的常见原因全景图

在动手排查之前，先建立 CPU 飙升原因的全局认知。不同原因对应的排查工具和修复方案完全不同：

┌─────────────────────────────────────────────────────────────┐
│                    CPU 飙升原因分类                           │
├──────────────┬──────────────┬──────────────┬────────────────┤
│  代码层面     │  JVM 层面    │  GC 层面     │  外部因素       │
├──────────────┼──────────────┼──────────────┼────────────────┤
│ 死循环       │ JIT 编译     │ Full GC      │ 流量突增       │
│ 正则回溯     │ 类加载开销   │ GC 线程过多  │ 被其他进程挤占 │
│ 高频序列化   │ 线程数过多   │ GC 算法不适配│ 容器 CPU 限制  │
│ 密集计算     │ 锁自旋       │              │                │
│ 递归无终止   │              │              │                │
└──────────────┴──────────────┴──────────────┴────────────────┘

郑天祺2026/7/3大约 16 分钟

线上问题排查：Arthas 火焰图与异步 profiling 实战

接口偶发慢但找不到原因？CPU 不高但响应延迟大？火焰图是性能分析的终极武器，一眼定位热点代码。

一、火焰图基础

1.1 什么是火焰图

火焰图（Flame Graph）：
  将 CPU 采样数据可视化为"火焰"形状的 SVG 图
  
  ┌────────────────────────────────────────────────┐
  │                  main()                        │ ← 栈底（宽=CPU时间多）
  │  ┌──────────┐  ┌────────────────┐              │
  │  │ handle() │  │ process()      │              │
  │  │ ┌──────┐ │  │ ┌────────────┐ │              │
  │  │ │ db() │ │  │ │ serialize()│ │              │ ← 栈顶（窄=CPU时间少）
  │  │ └──────┘ │  │ └────────────┘ │              │
  │  └──────────┘  └────────────────┘              │
  └────────────────────────────────────────────────┘
  
  横轴：CPU 占用时间比例（越宽越热）
  纵轴：调用栈深度（从下到上）
  颜色：随机（不影响分析）

看图口诀：
  找最宽的"平台" → CPU 占用最多的方法 → 优化目标
  找最深的"柱子" → 调用链最长的路径 → 可能有问题

郑天祺2026/7/2大约 7 分钟