Kotlin 协程设计思想（一）：CoroutineContext 到底是什么？为什么 Job 和 Dispatcher 可以直接相加？

引言CoroutineContext 本质上就是一个特殊的 Map写 Kotlin 协程这些年有一段代码相信大家都写过private val scope CoroutineScope( SupervisorJob() Dispatchers.Default )或者viewModelScope.launch( Dispatchers.IO ) { }刚开始学协程的时候我只是机械地记住Dispatchers.IO Dispatchers.Default Job SupervisorJob以及IO切线程 Job管理协程但一直有个问题没想明白为什么 Job 和 Dispatcher 能直接相加那个 到底干了什么直到最近重新梳理 Kotlin 协程体系我才突然发现CoroutineContext 本质上就是一个特殊的 Map。而那个神秘的SupervisorJob() Dispatchers.IO其实根本不是加法。今天我们就彻底讲透 Kotlin 协程最核心的设计之一CoroutineContext一、第一次看到这个代码时的疑惑例如CoroutineScope( SupervisorJob() Dispatchers.IO )很多人的第一反应都是Job 是任务管理器Dispatcher 是线程调度器。这两个东西怎么相加如果放到 Java 世界job dispatcher根本说不通。因为它们不是同一种东西。那么 Kotlin 为什么允许这样写二、答案藏在 CoroutineContext 里面先看 CoroutineScope 的构造函数public fun CoroutineScope( context: CoroutineContext ): CoroutineScope看到没有真正传进去的不是Job也不是Dispatcher而是CoroutineContext问题来了CoroutineContext 又是什么三、CoroutineContext 本质是什么很多教程会告诉你CoroutineContext 协程上下文说完就结束了。但这句话其实非常抽象。如果让我用一句最直白的话解释CoroutineContext ≈ 一个特殊的 Map例如MapKey, Value里面保存了协程运行所需要的各种配置。四、Job 是一个配置项例如SupervisorJob()实际上可以理解为Key Job Value SupervisorJob也就是说这是协程生命周期配置。五、Dispatcher 也是一个配置项例如Dispatchers.IO实际上可以理解为Key Dispatcher Value IO Dispatcher表示协程应该运行在哪个线程池。六、那个 到底干了什么现在再来看SupervisorJob() Dispatchers.IO实际上不是加法而是Context 合并可以理解成{ Job SupervisorJob }加上{ Dispatcher IO }最终得到{ Job SupervisorJob Dispatcher IO }这就是CoroutineContext七、为什么还能一直加例如CoroutineScope( SupervisorJob() Dispatchers.IO CoroutineName(Download) CoroutineExceptionHandler { _, e - } )最终得到CoroutineContext { Job SupervisorJob Dispatcher IO Name Download ExceptionHandler Handler }是不是特别像MapString, Any所以 其实是在不断往 Context 中增加配置。八、为什么后面的会覆盖前面的例如Dispatchers.IO Dispatchers.Default最终生效的是Dispatchers.Default为什么因为Key 相同都属于Dispatcher所以后面的覆盖前面的就像mapOf( name to 张三, name to 李四 )最终name 李四一样。九、launch 到底干了什么例如CoroutineScope( SupervisorJob() Dispatchers.IO CoroutineName(Download) ).launch { }启动协程时协程会从 Context 中读取Job Dispatcher Name ExceptionHandler然后构建自己的运行环境。也就是说launch() 不是简单创建协程 而是在创建一个协程运行环境。十、为什么 launch(Dispatchers.IO) 能切线程很多人天天写viewModelScope.launch( Dispatchers.IO ) { }以为切线程就结束了。实际上viewModelScope本身已经有一个 Context{ Job Dispatcher(Main) }当你写launch(Dispatchers.IO)其实是父Context { Dispatcher(IO) }得到{ Job Dispatcher(IO) }于是Main 被 IO 覆盖协程运行在 IO 线程池。十一、SupervisorJob 为什么也放在 Context 里面以前我一直觉得SupervisorJob()是一个特殊工具类。后来理解 Context 以后发现它其实只是CoroutineContext 中的一个配置项。作用是定义协程之间的父子关系。例如普通 Job一个子协程异常整个作用域取消而SupervisorJob则是一个子协程异常 不影响其它子协程十二、CoroutineContext 才是协程真正的核心学协程时很多人把注意力放在launch async withContext这些 API 上。但实际上CoroutineContext 才是整个协程体系的根。因为Dispatcher Job CoroutineName ExceptionHandler全部都挂在 Context 上。协程运行时所有配置都来自CoroutineContext十三、最终总结如果让我用一句话解释SupervisorJob() Dispatchers.IO我会这样说不是把两个对象相加。 而是在组装一个协程运行环境。其中Job负责生命周期Dispatcher负责线程调度CoroutineName负责调试ExceptionHandler负责异常处理而CoroutineContext则负责把这一切组织在一起。所以CoroutineContext 本质上不是一个对象。 而是一组协程配置的集合。理解了这一点你才真正推开了 Kotlin 协程设计的大门。下篇预告既然 CoroutineContext 中最重要的配置之一是Job那么问题来了协程为什么可以取消 父协程为什么能取消子协程 SupervisorJob 为什么不会连坐 结构化并发到底是什么下一篇我们继续《Kotlin 协程设计思想二Job 到底是什么为什么协程能被取消》从 Job 树开始彻底讲透 Kotlin 协程的生命周期管理机制。