9.6 步骤五：剖析定位

① 现象量化 → 已有（步骤三、四的数据）
② 分层拆解 → 找出哪一段占大头
③ 提出假设 → 六颗埋雷对应六个假设
④ 设计验证 → 每条假设一条可证伪的命令
⑤ 得出结论 → 证据链 + 贡献占比 + 被排除的假设

# 在拐点负载（约 700 RPS）下测量
tools/decompose-at-knee.sh E11-diagnosis

#!/usr/bin/env bash
# tools/decompose-at-knee.sh <EXP_ID>
set -uo pipefail

EXP_ID="${1:?usage: decompose-at-knee.sh <exp_id>}"
DIR="docs/experiments/${EXP_ID}"
mkdir -p "$DIR/results"

# ⚠️ 关键：在【拐点负载】下剖析，不是在低负载下
KNEE_QPS="${KNEE_QPS:-700}"

scripts/restart-app.sh "$DIR/results/gc.log"
sleep 5
BASE_URL=http://127.0.0.1:8080 k6 run --quiet --vus 20 --duration 60s loadtest/read-path.js > /dev/null

# 后台施压（持续整个剖析过程）
BASE_URL=http://127.0.0.1:8080 RATE="$KNEE_QPS" DURATION=5m \
k6 run --summary-export="$DIR/results/k6-knee.json" loadtest/read-path.js > /dev/null 2>&1 &
K6_PID=$!
sleep 40    # 等进入稳态

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

echo "═══ 在 ${KNEE_QPS} RPS 下采集证据 ═══"
echo

# ① 四类火焰图
echo "① 火焰图"
for E in cpu wall alloc lock; do
  asprof -d 20 -e "$E" -f "$DIR/results/$E.html" "$PID" > /dev/null 2>&1
  asprof -d 20 -e "$E" -o collapsed -f "$DIR/results/$E.collapsed" "$PID" > /dev/null 2>&1
  echo "   $E.html / $E.collapsed"
done
echo

# ② 线程快照（连续 3 份）
echo "② 线程快照"
mkdir -p "$DIR/results/threads"
for i in 1 2 3; do
  jcmd "$PID" Thread.print > "$DIR/results/threads/threads-$i.txt"
  sleep 3
done
python3 tools/analyze-threads.py "$DIR/results/threads"/threads-*.txt \
  > "$DIR/results/threads/analysis.txt"
echo "   分析已生成"
echo

# ③ 指标快照
curl -s localhost:8080/metrics > "$DIR/results/metrics.txt"

# ④ 数据库侧
echo "③ 数据库诊断"
psql "${PG_CONN:-postgresql://app:app@localhost:5432/shortlink}" > "$DIR/results/pg-diagnostics.txt" 2>&1 <<'SQL'
-- 最贵的语句（看 calls 与 mean）
SELECT calls, round(mean_exec_time::numeric,2) AS mean_ms,
       round(total_exec_time::numeric,0) AS total_ms,
       left(regexp_replace(query,'\s+',' ','g'), 50) AS query
FROM pg_stat_statements
WHERE query NOT LIKE '%pg_stat_statements%'
ORDER BY total_exec_time DESC LIMIT 10;

-- 当前活跃查询与等待
SELECT pid, round(extract(epoch from (now()-query_start))::numeric,1) AS dur_s,
       state, wait_event_type, wait_event, left(query,50)
FROM pg_stat_activity WHERE state <> 'idle' AND pid <> pg_backend_pid()
ORDER BY dur_s DESC NULLS LAST LIMIT 10;
SQL
echo "   已保存到 pg-diagnostics.txt"

wait $K6_PID 2>/dev/null || true

echo
echo "═══ 关键证据摘要 ═══"
echo
echo "── 数据库最贵的语句 ──"
head -8 "$DIR/results/pg-diagnostics.txt" | tail -6

echo
echo "── 火焰图热点（自身耗时 Top 5）──"
for E in cpu wall; do
  echo "[$E]"
  python3 tools/analyze-flamegraph.py "$DIR/results/$E.collapsed" 2>/dev/null \
    | grep -A6 "自身耗时 Top" | tail -5 | sed 's/^/  /'
done

echo
echo "── 线程分析关键结论 ──"
grep -E "BLOCKED|持续|⚠️|❌" "$DIR/results/threads/analysis.txt" 2>/dev/null | head -6 | sed 's/^/  /'

echo
echo "✅ 证据已采集 → $DIR/results"

cpu.collapsed  → 很空（几乎没有采样）
wall.collapsed → 大量栈停在 socketRead0 / JDBC 调用

这个对比就是第 6.3 节的核心：
「只采 CPU 火焰图会得出『没有瓶颈』的错误结论」

# 对比两张图的「自身耗时 Top」
python3 tools/analyze-flamegraph.py results/cpu.collapsed | head -20
python3 tools/analyze-flamegraph.py results/wall.collapsed | head -20

<!-- 假设台账：hypotheses.json 的可读版本 -->

## 假设台账

| ID | 假设 | 验证命令 | 否证条件 | 状态 |
| --- | --- | --- | --- | --- |
| H1 | 跳转接口慢由 `code` 无索引（全表扫描）造成 | `EXPLAIN (ANALYZE, BUFFERS) SELECT ... WHERE code = 'c123'` | 若显示 Index Scan 或 mean < 10ms 则排除 | 待验证 |
| H2 | 每次跳转的 `UPDATE hits` 造成行锁竞争 | `pg_stat_activity` 查 `wait_event_type=Lock`；`lock` 火焰图 | 若无 Lock 等待则排除 | 待验证 |
| H3 | 缓存 TTL 无抖动导致周期性雪崩 | 对齐 DB QPS 脉冲与 TTL(10min) | 若 QPS 曲线平滑则排除 | 待验证 |
| H4 | Default 调度器被 JDBC 阻塞调用占满 | `wall` 火焰图；`RUNNABLE 线程数 == 核数` | 若 RUNNABLE ≠ 核数则排除 | 待验证 |
| H5 | 热路径 INFO 日志造成同步 IO 开销 | JFR `jdk.FileWrite`；降级日志级别的对照实验 | 若降级后 P99 无变化则排除 | 待验证 |
| H6 | `synchronized` 生成 code 造成写路径锁竞争 | 线程 dump 的 `BLOCKED`；`lock` 火焰图 | 若无 BLOCKED 且写路径正常则排除 | 待验证 |
| H7 | GC 停顿造成 P99 尖刺 | GC 日志时间戳与 P99 尖刺对齐 | **不对齐则排除**（预期：排除） | 待验证 |
| H8 | 连接池太小导致排队 | 用 Little's Law 算所需连接数 vs 当前池大小 | 若查询优化后 pending 消失则排除 | 待验证 |

H7（GC）：预期被【排除】——因为基线显示 GC 停顿只有 18ms，远小于 P99 的 420ms
H8（连接池）：预期被【排除】——因为 pending 上升是慢查询的结果，不是原因

psql -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id, url FROM links WHERE code = 'c123456';"

Seq Scan on links  (cost=0.00..22906.00 rows=1 width=40) (actual time=0.015..385.234 rows=1 loops=1)
  Filter: (code = 'c123456'::text)
  Rows Removed by Filter: 999999          ← ⭐ 扫了 100 万行只留 1 行
  Buffers: shared hit=10890
Planning Time: 0.123 ms
Execution Time: 385.456 ms                ← 与观测的数据库 P99 = 380ms 吻合 ✅

① 现象：数据库查询 P99 = 380ms
② 证据：EXPLAIN 显示 Seq Scan，Rows Removed by Filter: 999999
③ 吻合：Execution Time 385ms ≈ 观测的 380ms
④ 结论：H1 成立

# ① wall 火焰图 vs cpu 火焰图
python3 tools/analyze-flamegraph.py results/wall.collapsed | grep -A8 "关键模式检测"
python3 tools/analyze-flamegraph.py results/cpu.collapsed | grep -A8 "关键模式检测"

# ② RUNNABLE 线程数 vs CPU 核数
CORES=$(nproc)
RUNNABLE=$(grep -c "java.lang.Thread.State: RUNNABLE" results/threads/threads-1.txt)
echo "CPU 核数: $CORES, RUNNABLE 线程数: $RUNNABLE"
# 预期：两者相等（8 == 8）⭐

CPU 核数 == RUNNABLE 线程数，且 CPU 利用率不高
→ Dispatchers.Default 的 worker 全被阻塞调用占住

<!-- bottlenecks.md -->

# 瓶颈清单

> 分析负载：700 RPS（拐点附近）　|　测量点：客户端
> 关联实验：E10-capacity（曲线）、E11-diagnosis（剖析）

## 总览：按对 P99 的贡献排序

| 排名 | 瓶颈 | 对 P99 的贡献 | 证据 | 修复优先级 |
| --- | --- | --- | --- | --- |
| 1 | **`code` 无索引（全表扫描）** | **~380 ms（90%）** | `EXPLAIN` Seq Scan | P0 |
| 2 | Default 上的 JDBC 阻塞调用 | ~25 ms（6%） | wall 火焰图 + RUNNABLE==核数 | P0 |
| 3 | 每次跳转 UPDATE hits（行锁） | ~10 ms（2.4%） | lock 火焰图 + Lock 等待 | P1 |
| 4 | 热路径 INFO 日志 | ~5 ms（1.2%） | JFR FileWrite | P1 |
| 5 | `synchronized` 生成 code（写路径） | 写路径为主，读路径影响小 | BLOCKED 线程 | P1 |
| 6 | 缓存 TTL 无抖动 | 周期性尖刺，均值影响小 | 需要额外采集 | P2 |

**测量方法**：逐个关闭（方法一，最可信）。

---

## 瓶颈 1：`code` 无索引导致全表扫描

### 现象
数据库查询 P99 = 380ms（占总 P99 420ms 的 90%）。

### 根因
`links` 表的 `code` 列没有索引，`SELECT ... WHERE code = ?` 走全表扫描。
具体位置：`init.sql` 里缺少 `CREATE UNIQUE INDEX ON links(code)`。

### 证据链
1. **`EXPLAIN (ANALYZE, BUFFERS)`**：

asprof -d 30 -e wall -f wall.html <pid>    # 看 Default worker 的栈
jcmd <pid> Thread.print | grep -c RUNNABLE # 应该等于 CPU 核数