Kotlin：一棵会传播失败与取消的树

Job 树：每个协程都有父亲

当你写 launch { } 或 async { }，你创建的不只是一个协程，还是树上的一个节点：

viewModelScope (SupervisorJob)
    │
    └── launch { }                    ← Job A
            │
            ├── async { fetchUser() }     ← Job A1
            ├── async { fetchOrders() }   ← Job A2
            └── async { fetchCoupons() }  ← Job A3

规则(记住这三条,你就懂了一切):
  ① 父 Job 被取消  →  所有子 Job 都被取消          (向下传播)
  ② 子 Job 失败    →  父 Job 被取消 → 兄弟全被取消  (向上传播,再向下)
  ③ 父 Job 会等所有子 Job 完成，自己才算完成         (不会有孤儿!)

suspend fun loadDashboard(): Dashboard = coroutineScope {
    val user   = async { api.getUser() }
    val orders = async { api.getOrders() }
    Dashboard(user.await(), orders.await())
}
// 这个函数返回的那一刻,保证:
//   · 两个 async 要么都完成了
//   · 要么都被取消了(如果有一个失败了)
// 【不可能】有任何协程还在后台偷偷跑。

取消：它是协作式的（这是理解一切的钥匙）

没有人能强行杀死一个正在跑的协程。取消只是「设置一个标志位，然后请它自己停下来」。

val job = launch {
    while (true) {
        doWork()          // ← 一个纯 CPU 的循环
    }
}
delay(100)
job.cancel()              // 设置 isActive = false
job.join()                // 等它真的结束

// ❌ 但它永远不会结束!
// 因为这个循环里【没有任何挂起点】,取消检查发生在挂起点上。
// 这个协程会一直跑下去,占死一个线程。

三种让循环变得「可取消」的办法

// ① 检查 isActive
while (isActive) {         // CoroutineScope.isActive
    doWork()
}
// 取消后循环正常退出,不抛异常

// ② ensureActive() —— 取消了就抛 CancellationException
while (true) {
    ensureActive()
    doWork()
}

// ③ yield() —— 检查取消 + 顺便让出线程给别的协程
while (true) {
    yield()               // ← CPU 密集循环里最该用这个
    doWork()
}

launch {
    Thread.sleep(10_000)   // ❌ 取消它?没门。
}                          //    Thread.sleep 不知道协程是什么。

launch {
    delay(10_000)          // ✅ 可以取消 —— delay 是挂起函数,是取消点
}

launch {
    blockingHttpCall()     // ❌ 取消不了。线程卡在 socket read 上。
}                          //    (取消标志设了,但没人去检查它)

suspend fun download(url: String) = withContext(Dispatchers.IO) {
    val call = okHttpClient.newCall(request)
    try {
        // 注册一个「协程被取消时」的回调
        coroutineContext.job.invokeOnCompletion { call.cancel() }
        call.execute()      // 阻塞的,但被 cancel() 时会抛 IOException 提前返回
    } finally { ... }
}
// 或者直接用支持协程的库(Retrofit 的 suspend 函数、Ktor)——
// 它们内部已经处理好了。

CancellationException 是特殊的

// 取消是靠抛一个 CancellationException 实现的。
// 它有一个特权:【它不会被当成「失败」】

launch {
    try {
        delay(1000)
    } catch (e: CancellationException) {
        // 被取消了
        throw e            // ← 必须重新抛出!否则取消就失效了
    }
}

// ❌ 最经典的一个坑:
launch {
    try {
        delay(1000)
    } catch (e: Exception) {     // CancellationException 是 Exception 的子类!
        log.error("出错了", e)    // ← 你刚刚把取消信号吞了
    }                            //   协程会「以为自己成功了」,继续往下跑
}

// ❌ 同一个坑的另一个面目:
launch {
    val result = runCatching { api.call() }   // runCatching 抓 Throwable!
    //           ^^^^^^^^^^^ 它会吞掉 CancellationException
    result.onFailure { log.error(it) }
}

// ✅ 正确
launch {
    try {
        delay(1000)
    } catch (e: CancellationException) {
        throw e                      // 先放取消过去
    } catch (e: Exception) {
        log.error("真的出错了", e)     // 再处理真正的错误
    }
}

inline fun <R> coRunCatching(block: () -> R): Result<R> =
    try { Result.success(block()) }
    catch (e: CancellationException) { throw e }   // ← 放取消过去
    catch (e: Throwable) { Result.failure(e) }

coroutineScope vs supervisorScope

这是最常被问、也最常用错的一对。区别只有一句话：子协程失败时，兄弟们要不要陪葬。

// ✅ 全都要:一个失败 → 全部取消,立刻返回错误
suspend fun loadPage() = coroutineScope {
    val user   = async { api.getUser() }
    val orders = async { api.getOrders() }
    Page(user.await(), orders.await())
}

// ✅ 各自独立:一个失败 → 其他继续
suspend fun loadDashboard() = supervisorScope {
    val cards = listOf("weather", "news", "stocks").map { type ->
        async {
            runCatching { api.getCard(type) }   // 注意:每个自己 catch!
                .getOrElse { ErrorCard(type) }
        }
    }
    cards.awaitAll()
}

async 的异常，为什么迟到

这是协程里最反直觉的一课：

// ❌ 这个 try/catch 抓不到异常!
try {
    val d = async { throw IOException("boom") }
} catch (e: IOException) {
    // 永远不会执行到这里
}

// ✅ 异常在 await() 的时候才抛
try {
    val d = async { throw IOException("boom") }
    d.await()          // ← 在这里抛
} catch (e: IOException) {
    // ✓ 抓到了
}

// ❌ 装在子协程上 —— 完全无效
scope.launch {
    launch(CoroutineExceptionHandler { _, e -> log(e) }) {  // ← 无效!
        throw RuntimeException()
    }
}
// 异常会一路传给【父 Job】,子协程上的 handler 根本不会被调用。

// ✅ 装在根协程上(或者 scope 的 context 里)
val scope = CoroutineScope(
    SupervisorJob() + Dispatchers.Main +
    CoroutineExceptionHandler { _, e -> log(e) }   // ✅ 这里才有效
)

Flow：把「一个值」变成「一串值」

suspend fun 返回一个值。Flow 返回一串值 —— 而且它天生带背压。

fun prices(): Flow<Price> = flow {
    while (true) {
        emit(api.getPrice())    // emit 是 suspend 的!
        delay(1000)
    }
}

prices()
    .map { it.toDisplay() }
    .collect { println(it) }    // 收集时才真的开始跑(冷流)

StateFlow：Android 的那个 5000

val uiState: StateFlow<UiState> = repository.observeData()
    .map { UiState.Success(it) }
    .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),  // ← 那个神秘的 5000
        initialValue = UiState.Loading
    )

那个 5000 是在等屏幕旋转。

屏幕旋转时，Activity 被销毁重建，订阅者会短暂地降到 0。如果用的是 SharingStarted.Lazily 之外的「一没人订阅就停」策略，上游会立刻停掉，然后马上又被重新订阅 —— 白白重新请求一次网络。

WhileSubscribed(5000) 的意思是：订阅者归零后，再等 5 秒；如果 5 秒内有人重新订阅（旋转完成了），就什么也不做，继续用原来的上游。

下一章：第三门语言。Go 没有 async，没有 suspend，没有染色 —— 它把整个问题塞进了 runtime。六幕看完 GMP 调度器，然后你会明白 conn.Read() 那个「假阻塞」是怎么做到的。