使用SupervisorJob()与不使用时协程执行结果不同的原因咨询

你遇到的差异本质上是协程Job的层级结构不同，导致调度器的执行顺序变化，具体拆解如下：

两种场景的Job层级对比 #

1. 不使用SupervisorJob()时 #

runBlocking的协程Job是根Job，第一个launch的协程继承这个根Job作为父，形成如下层级：

runBlocking Job
└── 协程1 Job
    ├── 协程2 Job
    │   └── 协程3 Job（打印"Launch B"）
    └── 协程4 Job（打印"Launch A End"）

协程3是协程2的子协程，属于嵌套两层的层级；协程4是协程1的直接子协程，和协程2同级。

2. 使用SupervisorJob()时 #

你给第一个launch显式传入了SupervisorJob()（未指定parent），这个SupervisorJob成为协程1的独立Job，和runBlocking的根Job没有父子关系，层级变为：

独立的SupervisorJob（协程1的Job）
├── 协程2 Job
│   └── 协程3 Job
└── 协程4 Job

调度器的执行逻辑差异 #

Kotlin协程的调度器在处理不同层级的协程时，会有细微的优先级差异：

• 在普通Job层级下，调度器会优先处理同一层级的协程。当协程2执行完println("Launch A")并启动协程3后，协程2的代码逻辑已经完成（只是Job会等待协程3结束），此时协程1会立即启动协程4，调度器会优先执行同级的协程4，所以先打印"Launch A End"，之后才会调度嵌套的协程3打印"Launch B"。
• 在SupervisorJob作为父Job时，调度器对嵌套子协程的调度更“及时”。协程2启动协程3后，调度器会立即调度协程3执行，打印"Launch B"，之后才会处理协程4的执行，所以输出顺序是"Launch A" → "Launch B" → "Launch A End"。

额外说明 #

需要注意的是，SupervisorJob的核心设计目的是隔离子协程的异常传播（单个子协程异常不会取消其他子协程），这里的执行顺序差异是Job层级变化带来的调度副作用，并非SupervisorJob的核心特性。而且协程调度本身存在一定非确定性，但在这个特定场景下，Job层级的差异导致了稳定的输出顺序区别。

内容的提问来源于stack exchange，提问作者user9628944