Kotlin协程挂起恢复是否会切换线程？内存可见性是否有保障？

先直接给出三个核心问题的明确答案：

• 协程挂起后完全可能恢复到不同线程上执行
• 挂起前线程产生的内存修改，会由协程内存模型保证同步传递到恢复执行的目标线程
• 示例代码中delay挂起点存在线程切换可能，但打印结果一定是1，不需要将变量声明为AtomicInteger

1. 挂起恢复的线程调度逻辑 #

示例中使用的Dispatchers.Default是基于JVM共享线程池实现的调度器，核心线程数和CPU核数一致。当协程调用delay这类非阻塞挂起函数时，当前持有的线程会立刻释放回线程池供其他任务使用；等挂起时间到需要恢复执行时，调度器会从空闲线程中任意选择一个执行后续协程代码，这个线程和挂起前执行代码的线程不一定是同一个，线程切换是完全符合设计预期的正常行为。

2. 挂起点的内存可见性保障 #

Kotlin协程的内存模型对挂起点有明确的happens-before约束：挂起点之前的所有内存写操作，一定对挂起点之后的代码可见，不管恢复时运行在哪个线程上。协程框架在实现挂起、调度逻辑时已经插入了对应的内存屏障，不会出现CPU缓存、指令重排导致的修改丢失问题，不需要开发者额外为挂起前后的代码做可见性处理。

3. 示例代码的执行逻辑验证 #

示例代码如下：

fun main(args: Array<String>) {
    runBlocking {
        launch(Dispatchers.Default) {
            var a = 0
            a++
            delay(100)
            println(a)
        }
    }
}

这段代码的执行结果不存在任何歧义：

• 首先变量a是定义在launch代码块内部的局部变量，生命周期完全和当前协程绑定，根本不会被其他线程访问，从根源上就不存在多线程竞争问题。
• 哪怕退一步把a换成协程外部的共享变量，a++的写操作发生在delay挂起点之前，协程保证的happens-before规则也会确保恢复执行的线程一定能读到修改后的值1，不会出现读到旧值0的情况。
• 这里完全不需要使用AtomicInteger，多余的原子包装只会增加不必要的性能开销。

注意：这个结论只适用于协程框架调度的代码逻辑。如果你在协程内部手动创建原生线程、或者不通过协程调度器直接往线程池提交任务，这种跨线程的内存访问还是需要遵循普通Java/Kotlin的多线程规则，自行处理可见性和原子性问题。

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