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

// ① 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"))
}

## 现象量化

| 维度 | /slow-cpu | /slow-io | /slow-db |
| --- | --- | --- | --- |
| P50 | | | |
| P99 | | | |
| 错误率 | | | |
| CPU 利用率（压测期间） | | | |
| 线程数 | | | |
| 连接池 pending | | | |
| 数据库 QPS | | | |
| 应用内 P99 | | | |

#!/usr/bin/env bash
# 对单个接口施压 + 采证据
TARGET="${1:-slow-cpu}"
DIR="docs/experiments/E06-bottlenecks/results/$TARGET"
mkdir -p "$DIR"

# ① 后台施压（只压一个接口，隔离变量）
BASE_URL=http://127.0.0.1:8080 k6 run --quiet --vus 20 --duration 3m \
  -e ENDPOINT="$TARGET" loadtest/single-endpoint.js > "$DIR/k6.txt" 2>&1 &
K6_PID=$!
sleep 30   # 等进入稳态

# ② 采四类火焰图
PID=$(jcmd | grep app.jar | awk '{print $1}')
for E in cpu wall alloc lock; do
  asprof -d 20 -e "$E" -f "$DIR/$E.html" "$PID"
done

# ③ 线程 dump（连续 3 份）
for i in 1 2 3; do
  jcmd "$PID" Thread.print > "$DIR/threads-$i.txt"
  sleep 3
done

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

# ⑤ 数据库侧（如果是 DB 相关）
psql -c "SELECT calls, mean_exec_time, total_exec_time, left(query,50)
         FROM pg_stat_statements ORDER BY calls DESC LIMIT 10;" > "$DIR/pg-stats.txt" 2>/dev/null

wait $K6_PID
echo "✅ $TARGET 证据采集完成 → $DIR"

## 根因结论：/slow-io

### 现象
P50 25ms / P99 480ms（正常接口是 P50 8ms / P99 25ms）；CPU 30%（异常低）

### 根因
`SlowIoHandler.kt:18` 在 `Dispatchers.Default` 上执行 JDBC 查询。
Default 的并行度 = CPU 核数(8)，8 个 worker 被阻塞调用占满后，
所有使用 Default 的协程排队。

### 证据链
1. wall 火焰图：8 个 Default worker 全停在 `SocketInputStream.read`
2. 线程 dump（3 份）：持续有 8 个 RUNNABLE 停在 JDBC 调用栈
3. 协程 dump（DebugProbes）：240 个协程挂在同一 JDBC 调用点
4. 关键巧合：RUNNABLE 线程数(8) == CPU 核数(8)

### 贡献占比
约 90%：把查询切到 Dispatchers.IO 后，P99 从 480ms 降到 45ms。

### 被排除的假设
| 假设 | 排除依据 |
| --- | --- |
| GC | 停顿时间戳与尖刺不对齐，停顿幅度 < 20ms |
| 连接池 | db_pool_pending = 0（全程） |
| 慢查询 | pg_stat_statements 无异常（pg_sleep 是故意的） |
| CPU 饱和 | CPU 仅 30% |

### 复现
（命令）

### 未覆盖
- 多副本场景；连接池上限被真正打满的情况

DebugProbes.install()   // 应用启动时
// 排障时调用 DebugProbes.dumpCoroutines()