协程启动模式

开篇前言

kotlin的协程在初学者看来是一个很神奇的东西，居然能做到用同步的代码块实现异步的调用，其实深入了解你会发现kotlin协程本质上是通过函数式编程的风格对Java线程池的一种封装，这样会带来很多好处，首先是函数式+响应式编程风格避免了回调地狱，这也可以说是实现promise，future等语言（比如js）的进一步演进。其次是能够避免开发者的失误导致的线程切换过多的性能损失。
那么我们就来看看协程，任何一种事物都有生命周期，协程也不例外，他的生命周期包含启动，运行（调度）和退出（取消）。首先我们来看看协程的启动

协程启动

协程的启动需要三种东西

• 上下文
• 启动模式

• 协程体
  下面是一段用于说明的例子

  
  协程三大组成.png
  他们三者加之后会提到的Flow,Sequece,selector可以组合成各种各样的流模型，以至于可以用它去完全替代RxJava中各种操作符号。我用如下图表示对其中的理解： image.png
  本文先来看协程的启动模式。

启动模式

在koltin协程中启动模式有以下四种：

public enum class CoroutineStart {
  // 立即执行协程体，随时可以取消
    DEFAULT,
// 只有在用户需要的情况下运行
    LAZY,
  // 立即执行协程体，但在开始运行协程体之前无法取消
    @ExperimentalCoroutinesApi
    ATOMIC,
// 立即在当前线程执行协程体，直到第一个 suspend函数调用，这里可以理解为耗时函数
    @ExperimentalCoroutinesApi
    UNDISPATCHED;
}

源码中是一个枚举类，其各种功能已经在注释中指出，下面我将用一个模型图和相应代码具体阐述各自的联系与区别，由于是本系列第一次用模型图阐述，所以会比较详细的描述该图的意思

DEFAULT与ATOMIC：

模型图

DEFAULT启动模式与ATOMIC启动模式的区别.png

图中的Main表示主线程，t1表示协程创建信号发起点，t2表示协程完成创建的信号时间点，t3表示协程体完成的时间点。此处红色的协程框表示其可以等价于线程或线程池（这里的描述可能还需要揣摩，因为这里本来就有争议）。所以如图所述，DEFAULT启动模式是在协程创建的期间也可以cancel的，而ATOMIC是不可以cancel的，具体实例看demo即可。一般我们常用DEFAULT模式，ATOMIC只有在涉及到cancel的时候才有意义。

demo

 suspend fun test1() {
        log(1)
        val job = GlobalScope.launch(start = CoroutineStart.DEFAULT) {
            log(2)
        }
      // 此处cancel后，2可能是输出不了的，因为可能在协程创建的期间（这里其实是线程池创建期间）就cancel了
        job.cancel()
        log(3)
    }
   suspend fun test2() {
        log(1)
        val job = GlobalScope.launch(start = CoroutineStart.ATOMIC) {
            log(2)
        }
  // 此处cancel后，2是肯定会输出，因为ATOMIC的cancel不能在协程体执行前cancel的
        job.cancel()
        log(3)
    }
fun main() = runBlocking {
    test1()
    test2()
    log("end")
}

LAZY模型

模型图

LAZY启动模式.png

符号的具体含义在上面已经描述清楚了，这里需要说明的是，此模型跟普通的线程一样，需要在某个时间点start()，其实将协程创建和执行分离宏观上来讲会变得非常灵活，所以LAZY的模型是经常使用的。

Demo

log(1)
val job = GlobalScope.launch(start = CoroutineStart.LAZY) {
    log(2)
}
log(3)
// 这里就是模型图执行的发起点
job.start()
log(4)

UNDISPATCHED模型

模型图

image.png
该图中的协程是在主线程里面创建的所以会标黑色且在main框的范围内，而红色的线程框是由协程体中的代码创建的。由图可知UNDISPATCHED启动模式也是立即执行协程体的但是却是在主线程执行的，当遇到suspend标记耗时函数时才会创建开启异步模式，该启动模式虽然现在还不稳定，但我觉得很有用，很多时候异步代码块里包含一些不用异步执行的代码，比如在执行耗时函数执行前的判断，如下代码所示，此时用该启动模式在needRun()返回false的情况下就能减少线程切换的开销。

if(!needRun()) return
// 执行耗时函数

Demo

log(1)
val job = GlobalScope.launch(start = CoroutineStart.UNDISPATCHED) {
    log(2)
  // 执行到这里的时候，协程才开始进行线程的创建，执行耗时函数，这里的delay是被suspend标注的函数，后面会提到
    delay(100)
    log(3)
}
log(4)
job.join()
log(5)

小结

本章通过模型图和代码的方式详细阐述了四种启动模式的原理与区别，并在模型图的阐述中说明了其可能的应用场景。其实总的来看，之所以需要这么几个启动模式，是想把每个原子操作分开以便和以后的调度器做组合产生更多的应用场景甚至能完全cover所有的应用场景。另外，本文中涉及到了一些除启动模式以外的知识，后面会陆续更新。