九、Job与CoroutineScope：管理句柄与执行单元的分离

在 Java 的线程模型中，Thread 对象身兼两职：

val thread = thread {
    println("Thread: ${Thread.currentThread().name}")
}

// Thread 对象同时承载两种能力
thread.name           // 元数据访问 —— 管理功能
thread.priority       // 元数据访问 —— 管理功能
thread.interrupt()    // 生命周期控制 —— 管理功能
thread.join()         // 等待完成 —— 管理功能
// 同时，它内部封装了真正的 OS 线程 —— 执行单元

核心模型可以概括为：

Thread 这个类承载了线程的管理功能，所以我们习惯把 Thread 对象看作是"线程对象"。这很直观，但意味着管理句柄和执行单元是绑定的——你拿到了 Thread 引用，就同时拿到了对 OS 线程的控制权和元数据访问权。

在协程中也有类似的对象——Job。但 Job 只是管理句柄，和执行线程彻底解耦：

val scope = CoroutineScope(Job())
val job = scope.launch { /* 协程体 */ }
val deferred = scope.async { /* 返回结果 */ }

// ———— Job 提供的管理能力 ————
job.start()              // 当创建协程时指定 CoroutineStart.LAZY 时需要手动启动
job.cancel()             // 取消该 Job 及其所有子 Job，结构化级联取消
job.join()               // 挂起等待 Job 完成，不阻塞线程，不传播异常
job.isActive             // 是否活跃（已启动但尚未完成）
job.isCancelled          // 是否已取消
job.isCompleted          // 是否已完成（正常 / 异常 / 取消都算完成）
job.parent               // 父 Job，是结构化并发的核心纽带
job.children             // 子 Job 序列
job.cancelChildren()     // 仅取消所有子 Job，不影响自身

// ———— Deferred 额外提供 ————
deferred.await()         // 挂起等待结果，获取返回值或重新抛出异常

用对比图直观展示两种模型的差异：

Job 只负责管理，启动协程靠的是 CoroutineScope。CoroutineScope 是协程体系的核心作用域与生命周期边界：

val scope = CoroutineScope(Job())
val job = scope.launch { /* 协程体 */ }
val deferred = scope.async { /* 返回结果 */ }

启动协程的本质，是将传入的上下文参数与当前 Scope 的 coroutineContext 进行合并。

CoroutineContext 是不可变集合，+ 运算符会生成一个全新的上下文快照供新协程使用。在合并过程中：

• 如果显式传入了 ContinuationInterceptor（如 Dispatchers.IO），则覆盖父级调度器
• 若未传入，则完整继承父级调度器

用代码验证这个覆盖与继承规则：

val scope = CoroutineScope(Job() + Dispatchers.Default)

// 不传调度器：继承 scope 的 Default
val job1 = scope.launch {
    val dispatcher = coroutineContext[ContinuationInterceptor]
    println("job1 的调度器: $dispatcher")  // Dispatchers.Default（继承自 scope）
}

// 显式传入：覆盖 scope 的 Default
val job2 = scope.launch(Dispatchers.IO) {
    val dispatcher = coroutineContext[ContinuationInterceptor]
    println("job2 的调度器: $dispatcher")  // Dispatchers.IO（覆盖了 scope 的 Default）
}

// 验证 scope 自身的调度器未被修改（不可变性）
val scopeDispatcher = scope.coroutineContext[ContinuationInterceptor]
println("scope 的调度器: $scopeDispatcher")  // 仍然是 Dispatchers.Default

在协程内部，coroutineContext 访问的是当前协程自身的上下文：

val scope = CoroutineScope(Job() + Dispatchers.Default)

scope.launch(Dispatchers.IO) {
    // coroutineContext 是当前协程专属的、已计算完毕的上下文快照
    val dispatcher = coroutineContext[ContinuationInterceptor]
    println("当前协程调度器: $dispatcher")        // Dispatchers.IO

    // scope 的上下文是外层 scope 的原始上下文
    val outerDispatcher = scope.coroutineContext[ContinuationInterceptor]
    println("外层 scope 调度器: $outerDispatcher") // Dispatchers.Default

    // 当前协程的 Job 和 scope 的 Job 是不同的
    val myJob = coroutineContext[Job]             // 当前协程的 Job（子）
    val scopeJob = scope.coroutineContext[Job]    // scope 的 Job（父）
    println("是同一个 Job 吗？ ${myJob === scopeJob}")  // false！父子关系，不是同一个对象

    // 验证父子关系
    println("myJob 的父 Job 是 scopeJob 吗？ ${myJob?.parent === scopeJob}")  // true
}

用层级图展示这种父子关系：

虽然 Job 和 CoroutineScope 在概念上是分离的，但在运行时有一个重要的真相：

var innerScope: CoroutineScope? = null
val outerJob = CoroutineScope(Dispatchers.Default).launch {
    innerScope = this   // this 是协程内部的 CoroutineScope
    println("innerScope === outerJob: ${innerScope === outerJob}")
    // 输出：innerScope === outerJob: true
}
// outerJob 的类型是 Job
// innerScope 的类型是 CoroutineScope?
// 但运行时它们是同一个对象！

为什么 === 返回 true？因为 StandaloneCoroutine（launch 的内部实现类）同时实现了 Job 和 CoroutineScope：

同一个对象，同时扮演两个角色。但关键在于：编译器只允许你通过声明类型访问对应的方法。

虽然运行时是同一个对象，但设计者刻意通过类型系统隐藏了部分能力：

设计者的考量很明确：

• 拿到 Job 引用时：希望你只关心生命周期管理，而不是用它去启动新的子协程，避免作用域的意外泄露。
• 拿到 CoroutineScope 时：希望你关注结构化并发——用 launch/async 启动协程，而不是直接操作底层 Job 的状态机细节。

当然，既然运行时是同一个对象，你确实可以强行绕过这个设计：

fun sneakyLaunch(outerJob: Job) {
    val scope = outerJob as CoroutineScope  // 强转！编译通过，运行时也通过
    scope.launch {
        println("outerJob as CoroutineScope —— 可以运行！")
    }
}

// 调用
val job = CoroutineScope(Dispatchers.Default).launch {
    delay(1000)
}.also { sneakyLaunch(it) }
// sneakyLaunch 内部成功启动了一个新的子协程！

把 Job 和 CoroutineScope 的全部能力放在一起对比，职责边界就很清晰了：