分析与定位 on Dorkytiger 的小屋

分析流程：五步法

Mon, 01 Jan 0001 00:00:00 +0000

6.1 分析流程：五步法

上一节：无　|　下一节：6.2 延迟分解配套代码：06-analysis-and-profiling/01-analysis-workflow

一句话结论

分析就是「提出假设 → 用一条命令证伪 → 更新认知」的循环。 关键纪律是：每个假设都必须能被一条命令证伪——说不出「看什么数据能推翻它」的假设，不是假设，是感想。

一、用「侦探破案」理解分析流程

一个合格的侦探不会说「我觉得是张三是凶手」就结案。流程是：

侦探	性能分析
现场勘查：什么时候、在哪、死了谁、怎么死的	现象量化：哪个接口、多慢、从何时开始、影响范围
尸检与物证：死亡时间、凶器、痕迹	分层拆解：延迟花在哪几段，CPU 花在哪
提出嫌疑人：谁有动机、有机会	提出假设：可能是连接池排队 / GC / 慢查询
审讯验证：逐个排查不在场证明	设计验证：用一条命令确认或排除
结案：证据链完整，能回答「为什么不是别人」	结论：含贡献占比与被排除的假设

注意最后一项：合格的结案报告不只要说「是张三」，还要说「为什么不是李四」。对应到性能分析：你不仅要证明「是连接池排队」，还要说明「为什么不是 GC」。

二、五步详解

第一步：现象量化（不是「慢」，是「谁在多慢的时候慢」）

必须回答的四个问题：

问题	为什么
谁慢？	是所有接口还是某个接口？是全部实例还是某一台？
多慢？	P50 还是 P99？错对率如何？是否达标？
从何时开始？	是突变的（部署引起）还是渐变的（数据量增长/泄漏）？
影响范围？	只影响某类请求？某个地域？某种数据？

用一张表把现象量化：

## 现象量化

| 维度 | 观测值 |
| --- | --- |
| 接口 | GET /orders/{id} |
| 指标 | P99 从 80ms → 400ms（P50 从 20ms → 25ms） |
| 时间 | 2025-01-15 14:30 开始，持续至今 |
| 范围 | 所有实例；只影响带 user_id 的查询；无 user_id 的正常 |
| 错误率 | 0.1%（未变） |
| QPS | 850（未变） |
| CPU | 45%（未变） |
| 变更 | 14:00 有一次部署（版本 v2.3.1） |

这张表本身就排除了很多可能：

延迟分解：把总账拆成明细

Mon, 01 Jan 0001 00:00:00 +0000

6.2 延迟分解：把总账拆成明细

上一节：6.1 分析流程五步法　|　下一节：6.3 火焰图读法配套代码：06-analysis-and-profiling/02-latency-decomposition

一句话结论

「这个接口要 400 ms」是一个总账。 分析的第一步是把它拆成网络 / 排队 / 应用 / 各依赖几段——因为不同的段对应完全不同的修法，而总账无法告诉你该改哪里。

一、用「工厂流水线的工时分析」理解延迟分解

工厂发现「一件产品从下单到发货要 8 天」，要改进就得知道这 8 天花在哪：

工序	耗时	占 8 天的比例
订单排队等排产	3 天	37%
原料采购	2 天	25%
生产加工	1 天	12%
质检	0.5 天	6%
包装入库	0.5 天	6%
发货运输	1 天	12%

看到这张表，改进方向立刻明确：优化「生产加工」（只占 12%）最多省 1 天；而"订单排队"占了 3 天——那才是大头。

后端的延迟分解完全一样，而且结论常常反直觉：

一个 P99 = 200 ms 的接口：
  网络 + 客户端排队   70 ms  (35%)
  网关 + 服务排队     90 ms  (45%)  ← 真正的瓶颈
  应用自身代码         7 ms  (3.5%) ← 你想优化的地方
  数据库              25 ms  (12.5%)
  缓存 + 下游          8 ms  (4%)

你写的代码只占 3.5%。 如果只优化它，最多省 7 ms。

火焰图读法

Mon, 01 Jan 0001 00:00:00 +0000

6.3 火焰图读法

上一节：6.2 延迟分解　|　下一节：6.4 线程与协程快照配套代码：06-analysis-and-profiling/03-flamegraph-reading 工具用法见第 4 章 4.3；本节讲怎么读。

一句话结论

火焰图是一张「时间面积图」，不是调用顺序图。 横轴是采样数（≈ 时间占比），纵轴是调用栈深度。看宽度找大头，看叶子找自己耗时的函数，两张图对照找真相。

一、用「地图」理解火焰图

火焰图像一张地图：

地图	火焰图
面积 = 实际占地	宽度 = 时间占比
相邻区域不代表有先后关系	左右相邻不代表调用顺序
放大看细节	点击可折叠/展开
等高线 = 海拔	栈深度 = 调用层级

⚠️ 最容易犯的错误：把横轴当时间轴，以为「左边先发生、右边后发生」。它不是时间轴——左边和右边只是不同的调用栈，可能在同一毫秒内交替出现。

二、三种要认出的形状

形状一：宽而平（热点函数）

┌──────────────────────────────────────────────────┐
│                  handleRequest                    │
├───────┬──────────────────────────────────────────┤
│ 业务   │         serialize (很宽，下方无子帧)        │  ← 热点！
└───────┴──────────────────────────────────────────┘

含义：这个函数自己在消耗时间（不是子调用）。

行动：这就是优化目标。看它的实现——常见的是序列化、正则、加密、字符串处理、集合操作。

形状二：深而窄（深调用链）

handleRequest
 └─ service
     └─ repository
         └─ hibernate
             └─ jdbc
                 └─ socketRead   ← 深而窄

含义：调用链深，但每一层占的时间都不多——时间分散在整条链上。

线程与协程快照

Mon, 01 Jan 0001 00:00:00 +0000

6.4 线程与协程快照

上一节：6.3 火焰图读法　|　下一节：6.5 瓶颈模式库（一）：池化类配套代码：06-analysis-and-profiling/04-thread-and-coroutine-dumps

一句话结论

一张线程快照没有价值，连续多张才有。 单张快照告诉你「此刻谁在哪」（可能只是路过），多张对比才能看出「谁一直卡在那里」。这就是「瞬时状态」与「持续问题」的区别。

一、用「工厂巡检拍照」理解快照

你去工厂检查为什么产线慢了。拍一张照片：

照片里 3 个工人站着不动。
但这可能只是巧合——他们可能刚好在等下一个零件。

连拍 5 张（每 3 秒一张）：

5 张照片里，同样的 3 个工人站在同一个位置不动。
而其他工人都在移动。
结论：这 3 个工人被卡住了。

线程快照完全一样：单张是「瞬时状态」，多张才能识别「持续阻塞」。

二、线程状态的五种含义

状态	含义	大量出现说明
`RUNNABLE`	正在运行或等待 CPU	CPU 饱和，或在自旋
`BLOCKED (on object monitor)`	等 monitor 锁	锁竞争
`WAITING (parking)`	无限期等待（`LockSupport.park`）	等锁、等队列、等任务
`TIMED_WAITING`	有时限等待（`sleep`、`await(timeout)`）	有超时等待（可能是重试退避）
`WAITING (on object monitor)`	`Object.wait()`	等条件变量

关键栈特征速查

栈里出现	含义
`HikariPool.getConnection`	连接池排队
`socketRead0` / `socketWrite0`	等网络（数据库/下游）
`Unsafe.park` / `LockSupport.park`	等锁或等任务
`LinkedBlockingQueue.take`	线程池空闲（正常）或队列空
`ArrayBlockingQueue.put`	队列满，生产者被阻塞（背压生效）
`Object.wait`	等条件变量
`Thread.sleep`	主动睡眠（重试退避或轮询）
`FileOutputStream.write`	同步日志刷盘
`classloader` 相关	类加载锁（启动期常见）

三、多个快照的对比方法

方法一：统计「持续存在」的栈

PID=$(jcmd | grep app.jar | awk '{print $1}')

# 连续取 5 份，间隔 3 秒
for i in $(seq 1 5); do
  jcmd "$PID" Thread.print > "threads-$i.txt"
  sleep 3
done

# 统计哪些栈在【所有快照】里都出现
comm -12 <(grep -E '^\s+at ' threads-1.txt | sort -u) \
         <(grep -E '^\s+at ' threads-2.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-3.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-4.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-5.txt | sort -u) | \
sort | uniq -c | sort -rn | head -20

输出示例：

瓶颈模式库（一）：池化类

Mon, 01 Jan 0001 00:00:00 +0000

6.5 瓶颈模式库（一）：池化类

上一节：6.4 线程与协程快照　|　下一节：6.6 瓶颈模式库（二）：数据与算法类配套代码：06-analysis-and-profiling/05-bottleneck-pools

一句话结论

池化类瓶颈的共同特征是「CPU 不高但延迟高」，因为时间花在排队上而不在计算上。 它们的鉴别关键都在饱和度指标：池的 pending、队列的深度、调度器的排队数。

一、用「机场安检」理解池化类瓶颈

机场安检有 4 个通道（= 池大小）：

现象	原因	对策
队伍不长，但每个乘客检查很慢	服务慢（不是通道不够）	加快单个检查（优化查询）
检查很快，但队伍越来越长	通道不够	加通道（加池）——但要小心
4 个通道全开，队伍还在涨	到瓶颈了	加通道 + 优化检查流程
通道空着，但乘客在别处排队	瓶颈不在安检	查别的环节

关键区分：「检查慢」和「通道少」是两件事，修法相反。

检查慢 → 优化检查（查询）
通道少 → 加通道（池）

判断方法：看 pending（队伍长度）与单次检查耗时（查询耗时）。

二、模式一：数据库连接池耗尽

现象

观测	值
CPU	40%（不高）
P99	从 80 ms 涨到 400 ms
`db_pool_pending`	18 ⭐
`db_pool_active`	10（= `total`，已打满）
wall 火焰图	大量栈停在 `HikariPool.getConnection`
线程 dump	40+ 线程停在 `HikariPool.getConnection`

验证命令

# ① 池状态
curl -s localhost:8080/metrics | grep -E "db_pool_(active|idle|pending|total)"

# ② 数据库侧：是否有长事务/慢查询占用连接
psql -c "SELECT pid, now()-query_start AS dur, state, wait_event_type, left(query,60)
         FROM pg_stat_activity WHERE state <> 'idle' ORDER BY dur DESC LIMIT 10;"

# ③ 慢查询排行
psql -c "SELECT calls, mean_exec_time, total_exec_time, left(query,50)
         FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"

修复方向（顺序很重要）

① 先确认「是查询慢还是池小」
   ├─ 有慢查询（mean_exec_time 高）→ 优化 SQL / 加索引（❗不要先加池）
   └─ 查询都快但仍然 pending → 用 Little's Law 计算所需连接数

② 如果是池小：
   所需连接 = 峰值 QPS × 单次查询 P99
   （用 P99 而不是平均，见第 0 章 0.4）

③ 无论如何都要加：获取连接超时（防止无限等待）

为什么不能先加池：池是数据库的并发闸门。加大它意味着允许更多并发查询打到数据库 → 锁竞争加剧、上下文切换增多 → 整体可能更慢，而且掩盖了真正的问题。

瓶颈模式库（二）：数据与算法类

Mon, 01 Jan 0001 00:00:00 +0000

6.6 瓶颈模式库（二）：数据与算法类

上一节：6.5 瓶颈模式库（一）：池化类　|　下一节：6.7 陷阱清单：Kotlin 与 C++ 直觉配套代码：06-analysis-and-profiling/06-bottleneck-data

一句话结论

这八种瓶颈的共同特征是「能从一个具体指标上直接看出来」——不像池化类那么隐蔽。所以它们的排查更依赖**「知道该看哪个指标」**，而不是复杂的工具。

一、八种模式的速查表

#	模式	一句话现象	关键指标	验证命令
1	N+1 查询	DB 调用次数与请求数成正比	`pg_stat_statements` 的 `calls`	对比 calls 与 QPS
2	缺索引/全表扫描	单条查询慢且随数据量恶化	`EXPLAIN` 的 `Seq Scan`	`EXPLAIN (ANALYZE, BUFFERS)`
3	锁竞争	CPU 高但吞吐不涨，`sys` 偏高	lock 火焰图、`BLOCKED` 线程	`jstack` + `pg_locks`
4	GC 停顿	P99 尖刺呈周期性	GC 日志停顿时间	与 P99 尖刺时间对齐
5	缓存击穿/雪崩	周期性尖刺，DB 负载脉冲	缓存命中率、DB QPS	对齐缓存失效时间
6	序列化开销	CPU 火焰图顶部是序列化栈	`cpu` 火焰图、`alloc` 图	对比不同序列化器
7	日志同步 IO	`sys` 高，火焰图有文件写栈	JFR `jdk.FileWrite`	降日志级别做对照
8	无界队列 OOM	内存持续增长，最终 OOM	队列深度、堆基线	看趋势是否单调

二、模式一：N+1 查询

现象与验证

典型症状：接口 P99 与返回的记录数成正比；QPS 不高但数据库负载很高。

陷阱清单：Kotlin 与 C++ 直觉

Mon, 01 Jan 0001 00:00:00 +0000

6.7 陷阱清单：Kotlin 与 C++ 直觉

上一节：6.6 瓶颈模式库（二）　|　下一节：6.8 结论的写法配套代码：06-analysis-and-profiling/07-traps-kotlin-and-cpp

一句话结论

九条 Kotlin 陷阱和六条 C++ 直觉误判，是「明明代码看起来没问题，但性能就是不对」的两大来源。 前者来自语言特性，后者来自你的经验在 JVM 上不成立。

一、九条 Kotlin 陷阱（按危害排序）

❶ 在 `Dispatchers.Default` 上做阻塞调用 🔴 最严重

// ❌ 占满 Default 的 worker（= CPU 核数）
suspend fun find(id: String) = jdbcTemplate.queryForObject(...)

// ✅ 切到 IO
suspend fun find(id: String): Order = withContext(Dispatchers.IO) {
    jdbcTemplate.queryForObject(...)
}

症状：CPU 低、所有接口一起慢、常规指标正常。验证：wall 火焰图 + 「RUNNABLE == 核数」。

❷ `synchronized` 跨越挂起点 🔴

// ❌ 挂起时仍持锁，线程被占用
suspend fun update() {
    synchronized(lock) {
        val data = loadFromDb()      // ← 挂起！
        cache.update(data)
    }
}

// ✅ 用 Mutex（协程感知的锁）
private val mutex = Mutex()
suspend fun update() = mutex.withLock {
    val data = loadFromDb()
    cache.update(data)
}

为什么危险：synchronized 是线程级锁，协程会在不同线程间切换 → 语义混乱、可能死锁。

结论的写法

Mon, 01 Jan 0001 00:00:00 +0000

6.8 结论的写法

上一节：6.7 陷阱清单：Kotlin 与 C++ 直觉　|　下一节：6.9 Lab 6 配套代码：06-analysis-and-profiling/08-writing-conclusions

一句话结论

一份合格的根因结论，必须能让读者回答三个问题：「你怎么知道是这个？」「它占多少？」「为什么不是别的？」——分别对应证据链、贡献占比、被排除的假设。

一、用「结案报告」理解结论

一个合格的结案报告不会只写「凶手是张三」。它会包含：

结案报告	性能结论
案件经过（时间、地点、受害人）	现象量化（哪个接口、多慢、何时开始）
证据链（物证、口供、监控）	证据链（指标、火焰图、日志，含命令与输出）
作案动机与手法	根因（具体到代码位置/配置项）
在整体中的位置（是主犯还是从犯）	贡献占比（占总延迟的百分比）
为什么不是李四（不在场证明）	被排除的假设（含排除依据）
如何重现	复现方式（命令与预期输出）

最容易被忽略的是「为什么不是李四」——但它往往是报告中最有专业性的部分。

二、结论的标准结构

# 根因结论：<标题>

## 1. 现象
| 维度 | 观测值 |
| --- | --- |
| 接口 | GET /orders/{id} |
| 指标 | P99 从 80ms → 400ms（P50 20→25ms） |
| 时间 | 2025-01-15 14:30 开始 |
| 范围 | 所有实例；只影响带 user_id 的查询 |
| 变更 | 14:00 部署 v2.3.1 |

## 2. 延迟分解
| 环节 | P99 | 占比 |
| --- | --- | --- |
| 网络 + 客户端排队 | 20 ms | 5% |
| **服务排队** | **290 ms** | **72%** ⭐ |
| 应用自身 | 13 ms | 3% |
| PostgreSQL | 65 ms | 16% |
| Redis + 下游 | 12 ms | 3% |

## 3. 根因
**v2.3.1 新增的 `/orders/stream` 长轮询接口，占用了网关到应用的连接池，
导致普通请求在网关侧排队等待可用连接。**

具体位置：`OrderStreamHandler.kt:42`（长轮询默认 60 秒超时）

## 4. 证据链

### 证据 1：网关侧连接等待时间

命令：curl -s gateway:9090/metrics | grep gateway_upstream_wait 输出：P99 = 340ms（基线 8ms）

Lab 6：在埋雷服务上定位三个瓶颈

Mon, 01 Jan 0001 00:00:00 +0000

6.9 Lab 6：在埋雷服务上定位三个瓶颈

上一节：6.8 结论的写法　|　下一节：第 7 章优化与验证配套代码：06-analysis-and-profiling/09-lab6 预计时长：120 分钟

一、这个 Lab 的目标

在一个「埋了三个不同性质瓶颈」的服务上，走完整套分析流程，产出一份合格的根因结论。

三个瓶颈的设计原则是：分别只在不同类型的工具上可见。这样你会被迫走完所有分析路径。

二、三个埋雷（先不要看这一节的细节，做完再看）

请在服务里实现下面三个接口（或自己设计等价的三个瓶颈）：

接口	瓶颈类型	只在哪种工具上可见
`GET /slow-cpu`	CPU 密集：热路径上重复编译正则	`cpu` 火焰图
`GET /slow-io`	阻塞 IO：在 `Dispatchers.Default` 上执行 JDBC	`wall` 火焰图 + 协程 dump
`GET /slow-db`	N+1：循环里单条查询	DB 指标（`calls`）

关键设计

// ① CPU 密集：每次请求都重新编译正则
get("/slow-cpu") {
    val text = "x".repeat(20_000)
    var hits = 0
    repeat(200) {
        val re = Regex("""\d{3}-\d{4}""")   // ← 每次都编译！
        hits += re.findAll(text).count()
    }
    call.respondText("hits=$hits")
}

// ② 阻塞 IO：在 Default 上做阻塞调用
get("/slow-io") {
    val n = ds.connection.use { c ->          // ← JDBC 是阻塞的
        c.createStatement().use { s ->
            s.executeQuery("select pg_sleep(0.02), 1").use { rs -> rs.next(); rs.getInt(2) }
        }
    }
    call.respondText("n=$n")
}

// ③ N+1：循环里单条查询
get("/slow-db") {
    val ids = (1L..100L).map { (it * 7919) % 100_000 + 1 }
    val urls = ids.map { id ->               // ← 100 次独立查询
        ds.connection.use { c ->
            c.prepareStatement("select url from orders where id = ?").use { ps ->
                ps.setLong(1, id)
                ps.executeQuery().use { rs -> if (rs.next()) rs.getString(1) else null }
            }
        }
    }
    call.respondText(urls.filterNotNull().joinToString("\n"))
}

为什么要分开三个接口：如果三个瓶颈混在同一个接口里，你只能看到「又慢又 CPU 高」，无法分别验证。分开之后，每个瓶颈的症状是干净的。

分析与定位 on Dorkytiger 的小屋

分析流程：五步法

6.1 分析流程：五步法

一句话结论

一、用「侦探破案」理解分析流程

二、五步详解

第一步：现象量化（不是「慢」，是「谁在多慢的时候慢」）

延迟分解：把总账拆成明细

6.2 延迟分解：把总账拆成明细

一句话结论

一、用「工厂流水线的工时分析」理解延迟分解

火焰图读法

6.3 火焰图读法

一句话结论

一、用「地图」理解火焰图

二、三种要认出的形状

形状一：宽而平（热点函数）

形状二：深而窄（深调用链）

线程与协程快照

6.4 线程与协程快照

一句话结论

一、用「工厂巡检拍照」理解快照

二、线程状态的五种含义

关键栈特征速查

三、多个快照的对比方法

方法一：统计「持续存在」的栈

瓶颈模式库（一）：池化类

6.5 瓶颈模式库（一）：池化类

一句话结论

一、用「机场安检」理解池化类瓶颈

二、模式一：数据库连接池耗尽

现象

验证命令

修复方向（顺序很重要）

瓶颈模式库（二）：数据与算法类

6.6 瓶颈模式库（二）：数据与算法类

一句话结论

一、八种模式的速查表

二、模式一：N+1 查询

现象与验证

陷阱清单：Kotlin 与 C++ 直觉

6.7 陷阱清单：Kotlin 与 C++ 直觉

一句话结论

一、九条 Kotlin 陷阱（按危害排序）

❶ 在 Dispatchers.Default 上做阻塞调用 🔴 最严重

❷ synchronized 跨越挂起点 🔴

结论的写法

6.8 结论的写法

一句话结论

一、用「结案报告」理解结论

二、结论的标准结构

Lab 6：在埋雷服务上定位三个瓶颈

6.9 Lab 6：在埋雷服务上定位三个瓶颈

一、这个 Lab 的目标

二、三个埋雷（先不要看这一节的细节，做完再看）

关键设计

❶ 在 `Dispatchers.Default` 上做阻塞调用 🔴 最严重

❷ `synchronized` 跨越挂起点 🔴