6.4 线程与协程快照

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

     47        at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:196)
     47        at com.example.repo.OrderRepository.findById(OrderRepository.kt:42)
     47        at com.example.service.OrderService.get(OrderService.kt:28)

for f in threads-*.txt; do
  echo "── $f ──"
  grep -oE "java.lang.Thread.State: [A-Z_]+" "$f" | sort | uniq -c | sort -rn
done

线程 dump 显示：io-8 线程 WAITING (parking)
                 ↑ 看起来很"闲"
但实际：        这个线程上有 200 个协程在排队等它

// 仅在排障时启用（开销很大）
import kotlinx.coroutines.debug.DebugProbes

DebugProbes.install()
// ... 出问题时 ...
DebugProbes.dumpCoroutines()      // 打印所有活跃协程及挂起点
DebugProbes.uninstall()

// build.gradle.kts
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-debug:1.9.0")
}

Coroutine "coroutine#12345":Active
    at com.example.service.OrderService.find(OrderService.kt:28)
    at com.example.db.OrderRepository.queryJdbc(OrderRepository.kt:42)
    at com.example.repo.JdbcQuery.execute(JdbcQuery.kt:15)

Coroutine "coroutine#12346":Active
    at com.example.service.OrderService.find(OrderService.kt:28)
    ...

// 自己埋一个"活跃协程数"指标，开销低
private val activeCoroutines = AtomicInteger(0)

fun CoroutineScope.tracked(block: suspend () -> Unit): Job = launch {
    activeCoroutines.incrementAndGet()
    try { block() } finally { activeCoroutines.decrementAndGet() }
}

// 注册为 Gauge
Gauge.builder("app.coroutines.active") { activeCoroutines.get().toDouble() }
    .register(registry)

第 1 步：看状态分布
   → 大量 BLOCKED？→ 锁竞争
   → 大量 RUNNABLE 且 CPU 高？→ 真的在算
   → 大量 WAITING (parking)？→ 等池/队列

第 2 步：看关键栈特征（用上面的速查表）
   → HikariPool → 连接池排队
   → socketRead → 等下游
   → park → 等锁/任务

第 3 步：多份对比，找「持续存在」的栈
   → 这才是真正的问题

第 4 步：如果是协程应用，补一份协程快照
   → 因为线程 dump 可能"看起来正常"

现象：所有接口偶发性卡顿，CPU 30%，线程数正常，GC 正常

① 线程状态分布（5 份快照）
   每份都是：8 个 RUNNABLE，42 个 WAITING (parking)
   → 没有明显的 BLOCKED（排除锁竞争）

② 看 8 个 RUNNABLE 的栈
   全部停在 socketRead0 / pg_sleep 相关调用
   → 但只有 8 个线程，为什么所有接口都卡？

③ 关键发现：这 8 个 RUNNABLE 是 Dispatchers.Default 的 worker
   而 CPU 核数也是 8 ！
   → Dispatchers.Default 的 8 个线程全部被阻塞调用占住

④ 协程快照验证
   DebugProbes.dumpCoroutines() 显示 240 个协程挂在同一个 JDBC 调用点
   → 证实：调度器被阻塞调用污染（第 2 章 2.7）

⑤ 结论
   根因：某个接口在 Dispatchers.Default 上执行 JDBC 查询，
         8 个 worker 被占满 → 所有使用 Default 的协程排队
   证据：线程 dump（8 个 RUNNABLE 全在 JDBC）+ 协程 dump（240 个协程排队）
   被排除：锁竞争（无 BLOCKED）、GC（停顿与尖刺不对齐）、
           连接池（pending = 0）