You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

31 KiB

Raw Blame History Unescape Escape

16 | Job：协程也有生命周期吗？

你好，我是朱涛。今天我们来学习Kotlin协程的Job。

Job其实就是协程的句柄。从某种程度上讲，当我们用launch和async创建一个协程以后，同时也会创建一个对应的Job对象。另外，Job也是我们理解协程生命周期、结构化并发的关键知识点。通过Job暴露的API，我们还可以让不同的协程之间互相配合，从而实现更加复杂的功能。

虽然前面已经解释过，Job就是协程的句柄，但你可能还是不清楚它到底是什么，因为句柄本身就是一个比较“虚”的概念。所以在这节课中，我们会从使用的角度入手，来看看Job到底能干什么。在充分理解了Job的用法以后，我们再来结合它的源代码进一步分析，这样对Job也会有一个更加清晰的认知。

Job生命周期

在上节课我们学习launch、async的时候，我们知道它们两个返回值类型分别是Job和Deferred。

// 代码段1

public interface Deferred<out T> : Job {
    public suspend fun await(): T
}

而如果你去看Deferred的源代码，你会发现，它其实也是继承自Job的。对应的，它只是多了一个泛型参数T，还多了一个返回类型为T的await()方法。所以，不管是launch还是async，它们本质上都会返回一个Job对象。

通过Job对象，我们主要可以做两件事情：

使用Job 监测协程的生命周期状态；
使用Job 操控协程。

让我们来看一个具体的例子：

// 代码段2

fun main() = runBlocking {
    val job = launch {
        delay(1000L)
    }
    job.log()       // ①
    job.cancel()    // ②
    job.log()       // ③
    delay(1500L)
}

/**
 * 打印Job的状态信息
 */
fun Job.log() {
    logX("""
        isActive = $isActive
        isCancelled = $isCancelled
        isCompleted = $isCompleted
    """.trimIndent())
}

/**
 * 控制台输出带协程信息的log
 */
fun logX(any: Any?) {
    println("""
================================
$any
Thread:${Thread.currentThread().name}
================================""".trimIndent())
}


/*
输出结果：
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
isActive = false
isCancelled = true
isCompleted = false
Thread:main @coroutine#1
================================
*/

在这段代码当中，我们定义了一个Job.log()扩展函数，它的作用就是打印Job的生命周期状态。通过调用这个函数，我们就可以知道对应的协程处于什么状态。

注释①处的调用结果，“isActive = true”，这代表了当前的协程处于活跃状态。注释②，我们调用了job.cancel()以后，协程任务就会被取消。因此，注释③处的调用结果就会变成“isCancelled = true”，这代表了协程任务处于取消状态。

所以从上面的代码中，我们可以看到：job.log()，其实就是在监测协程；job.cancel()，其实就是在操控协程。

而除了job.cancel()可以操控协程以外，我们还经常使用job.start()来启动协程任务，一般来说，它都是搭配“CoroutineStart.LAZY”来使用的。

// 代码段3

fun main() = runBlocking {
    //                  变化在这里
    //                      ↓
    val job = launch(start = CoroutineStart.LAZY) {
        logX("Coroutine start!")
        delay(1000L)
    }
    delay(500L)     
    job.log()       
    job.start()     // 变化在这里
    job.log()
    delay(500L)
    job.cancel()
    delay(500L)
    job.log()
    delay(2000L)
    logX("Process end!")
}

/*
输出结果：
================================
isActive = false
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
Coroutine start!
Thread:main @coroutine#2
================================
================================
isActive = false
isCancelled = true
isCompleted = true
Thread:main @coroutine#1
================================
================================
Process end!
Thread:main @coroutine#1
================================
*/

根据以上代码的运行结果，可以发现，当我们使用CoroutineStart.LAZY作为启动模式的时候，协程任务被launch以后，并不会立即执行，即使我们在代码中delay了500毫秒，launch内部的"Coroutine start!"也仍然没有输出。这是典型的懒加载行为模式。

当我们在外部调用了job.start()以后，job的状态才变成了Active活跃。而当调用了cancel以后，job的状态才变成isCancelled、isCompleted。

到这里，我们基本上就可以想象出Job整个的生命周期了。请参考下面这张图：

从图中，我们可以看到，对于协程的Job来说，它有两种初始状态，如果Job是以懒加载的方式创建的，那么它的初始状态将会是New；而如果一个协程是以非懒加载的方式创建的，那么它的初始状态就会是Active。

另外如果你仔细分析了上面代码的输出结果，你会发现，当调用cancel以后，会出现一个奇怪的现象：isCancelled = true、isCompleted = true。也就是说，当协程任务被取消以后，isCancelled和isCompleted同时都是true。但这跟上面的流程图并不一致啊！这是为什么呢？

这是因为，协程认为由于某种原因取消的协程，也仍然是一种“结束状态”，这其实也就对应了流程图中的“最终状态”。

换句话说，流程图当中的New、Active、Completing、Cancelling、Completed、Cancelled这些状态，都是Job内部私有的状态。而Job对外暴露出的isCompleted并不是与其一一对应的。Job内部私有的Completed、Cancelled状态，都会认为是外部的isCompleted状态。

测试了协程cancel()方法以后，我们再来看看协程正常执行完毕的情况：

// 代码段4

fun main() = runBlocking {
    val job = launch(start = CoroutineStart.LAZY) {
        logX("Coroutine start!")
        delay(1000L)
    }
    delay(500L)
    job.log()
    job.start()
    job.log()
    delay(1100L)    // ①
    job.log()
    delay(2000L)    // ②
    logX("Process end!")
}

================================
isActive = false
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
Coroutine start!
Thread:main @coroutine#2
================================
================================
isActive = false
isCancelled = false
isCompleted = true
Thread:main @coroutine#1
================================
================================
Process end!
Thread:main @coroutine#1
================================

在这段代码中，我们可以清晰地看到，协程的状态从Start到Active，最后到Completed，这很好理解。

不过，需要注意的是注释①处，为了等待job任务执行完毕，我们在外面等待了1100毫秒，这种方式其实并不好，因为大部分情况下，我们很难从外部判断协程需要多长的时间才能结束（比如网络请求任务、下载任务）。

另外，请留意上面的注释②处，我们使用delay(2000L)的方式，希望在job执行完毕以后输出“Process end!”，这样的代码，也是建立在“我们知道Job只需要1000毫秒就能执行完毕”的前提。如果协程内部的delay远大于外部的delay，以上的运行结果就会完全不一样：

// 代码段5

fun main() = runBlocking {
    val job = launch(start = CoroutineStart.LAZY) {
        logX("Coroutine start!")
        delay(4000L) // 变化在这里
    }
    delay(500L)
    job.log()
    job.start()
    job.log()
    delay(1100L)    
    job.log()
    delay(2000L)    
    logX("Process end!")
}

/*
输出结果：
================================
isActive = false
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
Coroutine start!
Thread:main @coroutine#2
================================
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
Process end!
Thread:main @coroutine#1
================================
到这里，job仍然还在delay，整个程序并没有完全退出。
*/

可以看到，当我们将job内部的delay改为4000毫秒以后，执行结果就完全不一样了，我们无法监测到isCompleted状态。

另外，如果你实际运行了上面的代码，你会发现“Process end!”输出以后，程序并没有立即结束，而是等待了大约900毫秒才结束，这是因为runBlocking会一直阻塞，等到job任务执行完毕以后才真正退出。

所以，为了更加灵活地等待和监听协程的结束事件，我们可以用job.join()以及 invokeOnCompletion {} 来优化上面的代码。

// 代码段6

fun main() = runBlocking {
    suspend fun download() {
        // 模拟下载任务
        val time = (Random.nextDouble() * 1000).toLong()
        logX("Delay time: = $time")
        delay(time)
    }
    val job = launch(start = CoroutineStart.LAZY) {
        logX("Coroutine start!")
        download()
        logX("Coroutine end!")
    }
    delay(500L)
    job.log()
    job.start()
    job.log()
    job.invokeOnCompletion {
        job.log() // 协程结束以后就会调用这里的代码
    }
    job.join()      // 等待协程执行完毕
    logX("Process end!")
}

/*
运行结果：
================================
isActive = false
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
isActive = true
isCancelled = false
isCompleted = false
Thread:main @coroutine#1
================================
================================
Coroutine start!
Thread:main @coroutine#2
================================
================================
Delay time: = 252
Thread:main @coroutine#2
================================
================================
Coroutine end!
Thread:main @coroutine#2
================================
================================
isActive = false
isCancelled = false
isCompleted = true
Thread:main @coroutine#2
================================
================================
Process end!
Thread:main @coroutine#1
================================
*/

这里我们可以看到，invokeOnCompletion {} 的作用，其实就是监听协程结束的事件。需要注意的是，它和前面的isCompleted类似，如果job被取消了，invokeOnCompletion {} 这个回调仍然会被调用。

而job.join()其实是一个“挂起函数”，它的作用就是：挂起当前的程序执行流程，等待job当中的协程任务执行完毕，然后再恢复当前的程序执行流程。可以看到，上节课学的“挂起函数”的概念再一次出现了，它对我们后续理解协程的API非常重要，如果你无法理解上面那句话的意思，一定要去重新回顾上节课的内容。

至此，我们就对Job的两种使用场景都已经有了充分认识了。我们来大概看看Job的源代码：

// 代码段7

public interface Job : CoroutineContext.Element {

    // 省略部分代码

    // ------------ 状态查询API ------------

    public val isActive: Boolean

    public val isCompleted: Boolean

    public val isCancelled: Boolean

    public fun getCancellationException(): CancellationException

    // ------------ 操控状态API ------------

    public fun start(): Boolean

    public fun cancel(cause: CancellationException? = null)

    public fun cancel(): Unit = cancel(null)

    public fun cancel(cause: Throwable? = null): Boolean

    // ------------ 等待状态API ------------

    public suspend fun join()

    public val onJoin: SelectClause0

    // ------------ 完成状态回调API ------------

    public fun invokeOnCompletion(handler: CompletionHandler): DisposableHandle

    public fun invokeOnCompletion(
        onCancelling: Boolean = false,
        invokeImmediately: Boolean = true,
        handler: CompletionHandler): DisposableHandle

}

可见，Kotlin官方对Job的API做了更加详细的划分，但实际上来说都属于“监测状态”“操控状态”这两个大的范畴。

现在我们对Job也有了更加深入的认识了，不过到底该如何理解“Job是协程的句柄”这句话呢？

这里，我们还是可以从现实生活中找例子，来建立大致的思维模型。Job和协程的关系，就有点像“遥控器和空调的关系”。

空调遥控器可以监测空调的运行状态；Job也可以监测协程的运行状态；
空调遥控器可以操控空调的运行状态，Job也可以简单操控协程的运行状态。

所以，从某种程度来讲，遥控器也是空调对外暴露的一个“句柄”。

好，充分理解了Job以后，我们来看看Deferred。

Deferred

前面我们介绍过Deferred其实就是继承自Job的一个接口，它并没有在Job的基础上扩展出很多其他功能，最重要的就是await()这个方法。让我们来看一个简单的例子：

// 代码段8

fun main() = runBlocking {
    val deferred = async {
        logX("Coroutine start!")
        delay(1000L)
        logX("Coroutine end!")
        "Coroutine result!"
    }
    val result = deferred.await()
    println("Result = $result")
    logX("Process end!")
}

/*
输出结果：
================================
Coroutine start!
Thread:main @coroutine#2
================================
================================
Coroutine end!
Thread:main @coroutine#2
================================
Result = Coroutine result!
================================
Process end!
Thread:main @coroutine#1
================================
*/

从代码的执行结果中，我们可以发现，deferred.await()这个方法，不仅可以帮助我们获取协程的执行结果，它还会阻塞当前协程的执行流程，直到协程任务执行完毕。在这一点的行为上，await()和join()是类似的。

我们也来看看await()的函数签名：

// 代码段9

public interface Deferred<out T> : Job {
//          注意这里
//            ↓
    public suspend fun await(): T
}

可以看到，await()这个方法其实是一个挂起函数，这也就意味着，这个方法拥有挂起和恢复的能力。如果当前的Deferred任务还没执行完毕，那么，await()就会挂起当前的协程执行流程，等待Deferred任务执行完毕，再恢复执行后面剩下的代码。

看到这里，也许你会觉得奇怪，**挂起函数不是非阻塞的吗？怎么这里又出现了阻塞？**注意，这里其实只是看起来像是阻塞了，但它实际上是将剩下的代码存了起来，留在后面才执行了。

为了让你更加透彻地理解await()挂起函数背后的细节，我进一步完善了之前协程思维模型的动图。

所以，这里await()后面的代码，虽然看起来是阻塞了，但它只是执行流程被挂起和恢复的一种表现。而且如果你仔细思考的话，你会发现上面这个动图，同样也描述了之前job.join()的行为模式，在协程执行完毕之前，后面的协程代码都被暂时挂起了，等到协程执行完毕，才有机会继续执行。

所以，总的来说，Deferred只是比Job多了一个await()挂起函数而已，通过这个挂起函数，我们可以等待协程执行完毕的同时，还可以直接拿到协程的执行结果。

至此，我们就已经把Job和Deferred的生命周期讲清楚了。对于Job，我们了解了监测生命周期状态、操控生命周期状态；对于Deferred，我们也明白了如何拿到它的执行结果。

那么接下来，就只剩下一个话题了：结构化并发。

Job与结构化并发

也许你会经常看到类似这样的话：协程的优势在于结构化并发。在我看来，Kotlin协程的结构化并发，它的重要性，是仅次于“挂起函数”的。

也就是说，“结构化并发”是Kotlin协程的第二大优势。那么，到底什么是结构化并发呢？其实，这是一个非常大的话题，三言两语真的很难讲清楚。“结构化并发”会贯穿我们整个课程，随着课程的进展，你会发现，它跟很多其他协程概念都会发生牵连。

简单来说，“结构化并发”就是：带有结构和层级的并发。

说实话，在抽象的概念面前，语言和文字总会显得苍白无力。所以，我们还是来看一个具体的例子吧。

// 代码段10

fun main() = runBlocking {
    val parentJob: Job
    var job1: Job? = null
    var job2: Job? = null
    var job3: Job? = null

    parentJob = launch {
        job1 = launch {
            delay(1000L)
        }

        job2 = launch {
            delay(3000L)
        }

        job3 = launch {
            delay(5000L)
        }
    }

    delay(500L)

    parentJob.children.forEachIndexed { index, job ->
        when (index) {
            0 -> println("job1 === job is ${job1 === job}")
            1 -> println("job2 === job is ${job2 === job}")
            2 -> println("job3 === job is ${job3 === job}")
        }
    }

    parentJob.join() // 这里会挂起大约5秒钟
    logX("Process end!")
}

/*
输出结果：
job1 === job is true
job2 === job is true
job3 === job is true
// 等待大约5秒钟
================================
Process end!
Thread:main @coroutine#1
================================
*/

在上面的代码中，我们一共定义了4个Job，parentJob是最外层的launch返回的对象，而在这个launch的内部，还额外嵌套了三个launch，它们的Job对象分别赋值给了job1、job2、job3。
接着，我们对“parentJob.children”进行了遍历，然后逐一对比了它们与job1、job2、job3的引用是否相等（“===”代表了引用相等，即是否是同一个对象）。

通过这样的方式，我们可以确定，job1、job2、job3其实就是parentJob的children。也就是说，我们使用launch创建出来的协程，是存在父子关系的。

如果你去看Job的源代码，你会发现它还有两个API是用来描述父子关系的。

// 代码段11

public interface Job : CoroutineContext.Element {
    // 省略部分代码

    // ------------ parent-child ------------

    public val children: Sequence<Job>

    @InternalCoroutinesApi
    public fun attachChild(child: ChildJob): ChildHandle
}

可以看到，每个Job对象，都会有一个children属性，它的类型是Sequence，它是一个惰性的集合，我们可以对它进行遍历。而attachChild()则是一个协程内部的API，用于绑定ChildJob的，这个我们到源码篇的时候再深入了解。

所以，我们其实可以用一个简单的结构图来描述上面4个Job之间的关系：

那么，这样的父子关系到底意味着什么呢？如果你实际运行这里的代码，你就会注意到：“parentJob.join()”这行代码会被挂起大约5秒钟。

注意了，我们调用的是parentJob的join()方法，但是，它会等待其内部的job1、job2、job3全部执行完毕，才会恢复执行。换句话说，只有当job1、job2、job3全部执行完毕，parentJob才算是执行完毕了。

所以到这里，也许你就已经可以理解前面的那句话了：结构化并发就是带有结构和层级的并发。

实际上，协程不像我们之前学过的线程，线程之间是不存在父子关系的，但协程之间是会存在父子关系的。不过要命的是，协程的这种父子关系并不明显，如果我们不深入Job的源码，就无法意识到这一点。这也是很多人无法理解协程运行模式的原因所在。

毕竟，如果你将上面的4个launch都割裂来看，那么无论如何，你都无法理解上面代码的运行顺序，可是一旦你建立了协程Job父子关系的思维模型，你就可以轻而易举地理解以上的代码。

现在，我们将上面的代码做一些修改，我相信你也可以马上弄明白它的运行模式！

// 代码段12

fun main() = runBlocking {
    val parentJob: Job
    var job1: Job? = null
    var job2: Job? = null
    var job3: Job? = null

    parentJob = launch {
        job1 = launch {
            logX("Job1 start!")
            delay(1000L)
            logX("Job1 done!") // ①，不会执行
        }

        job2 = launch {
            logX("Job2 start!")
            delay(3000L)
            logX("Job2 done!") // ②，不会执行
        }

        job3 = launch {
            logX("Job3 start!")
            delay(5000L)
            logX("Job3 done!")// ③，不会执行
        }
    }

    delay(500L)

    parentJob.children.forEachIndexed { index, job ->
        when (index) {
            0 -> println("job1 === job is ${job1 === job}")
            1 -> println("job2 === job is ${job2 === job}")
            2 -> println("job3 === job is ${job3 === job}")
        }
    }

    parentJob.cancel() // 变化在这里
    logX("Process end!")
}

/*
输出结果：
================================
Job1 start!
Thread:main @coroutine#3
================================
================================
Job2 start!
Thread:main @coroutine#4
================================
================================
Job3 start!
Thread:main @coroutine#5
================================
job1 === job is true
job2 === job is true
job3 === job is true
================================
// 这里不会等待5秒钟
Process end!
Thread:main @coroutine#1
================================
*/

这段代码，最大的改变就在于我们将“parentJob.join”改为了“parentJob.cancel()”。从运行结果中我们可以看到，即使我们调用的只是parentJob的cancel()方法，并没有碰过job1、job2、job3，但是它们内部的协程任务也全都被取消了。

这里，我们也可以用一个简单的动图来描述它们之间的关系：

所以，当我们以结构化的方式构建协程以后，我们的join()、cancel()等操作，也会以结构化的模式来执行。

思考与实战

在学完Job和Deferred以后，也许你已经可以非常明确地判断出什么场景该用launch，什么场景该用async了。那么，这是不是就意味着你已经完成了学习的目标呢？

当然不是！理论学得再多，如果不能结合实际落地场景来分析，那终究都是一场空。接下来，我们来看一个常见的代码模式：

// 代码段13

fun main() = runBlocking {
    suspend fun getResult1(): String {
        delay(1000L) // 模拟耗时操作
        return "Result1"
    }

    suspend fun getResult2(): String {
        delay(1000L) // 模拟耗时操作
        return "Result2"
    }

    suspend fun getResult3(): String {
        delay(1000L) // 模拟耗时操作
        return "Result3"
    }

    val results = mutableListOf<String>()

    val time = measureTimeMillis {
        results.add(getResult1())
        results.add(getResult2())
        results.add(getResult3())
    }
    println("Time: $time")
    println(results)
}

/*
输出结果：
Time: 3018
[Result1, Result2, Result3]
*/

这段代码里，我们在内部定义了三个挂起函数getResult1()、getResult2()、getResult3()，它们各自都会耗时1000毫秒，而且它们之间的运行结果也互不相干。代码逻辑也很简单，也是我们平时在工作中会经常遇到的业务场景。

不过请问，你知道该如何优化上面的代码吗？

我们进一步来分析一下。当我们直接调用这三个挂起函数，并且拿到结果以后，整个过程大约需要消耗3000毫秒，也就是这几个函数耗时的总和。对于这样的情况，我们其实完全可以使用async来优化：

// 代码段14

fun main() = runBlocking {
    suspend fun getResult1(): String {
        delay(1000L) // 模拟耗时操作
        return "Result1"
    }

    suspend fun getResult2(): String {
        delay(1000L) // 模拟耗时操作
        return "Result2"
    }

    suspend fun getResult3(): String {
        delay(1000L) // 模拟耗时操作
        return "Result3"
    }

    val results: List<String>

    val time = measureTimeMillis {
        val result1 = async { getResult1() }
        val result2 = async { getResult2() }
        val result3 = async { getResult3() }

        results = listOf(result1.await(), result2.await(), result3.await())
    }

    println("Time: $time")
    println(results)
}

/*
输出结果：
Time: 1032
[Result1, Result2, Result3]
*/

所以，当我们总是拿launch和async来做对比的时候，就会不自觉地认为async是用来替代launch的。但实际上，async最常见的使用场景是：与挂起函数结合，优化并发。

请不要小看这个场景，在实际工作中，如果你仔细去分析嵌套的异步代码，你会发现，很多异步任务之间都是没有互相依赖的，这样的代码结合挂起函数后，再通过async并发来执行，是可以大大提升代码运行效率的。

换句话说，如果我们的任务是IO密集型的，代码运行效率是可以实现成倍提升的。一个简单的改造，能极大地提升运行效率，何乐而不为呢？

那么，万一我们的任务在某些场景下，并发反而会降低效率呢？这也很简单，我们也完全可以使用CoroutineStart来控制它的启动模式。所以，这种方式的扩展性和灵活性都很好。

小结

这节课，我们主要学习了Job、Deferred，通过对它们两者的学习，我们知道了，协程是有生命周期的，同时也发现，协程其实是结构化的。

具体来说，有以下几个要点我们需要好好掌握：

Job，相当于协程的句柄，Job与协程的关系，有点像“遥控器与空调的关系”。
Job，在它的内部，维护了一系列的生命周期状态，它也对应着协程的生命周期状态。
通过Job，我们可以监测协程的状态，比如isActive、isCancelled、isCompleted；另外，我们也可以一定程度地操控协程的状态，比如start()、cancel()。
除此之外，我们还可以通过 Job.invokeOnCompletion {} 来监听协程执行完毕的事件；通过Job.join()这个挂起函数，我们可以挂起当前协程的执行流程，等到协程执行完毕以后，再恢复执行后面的代码。
而对于Deferred.await()，它的行为模式和Job.join()类似，只是它还会返回协程的执行结果。
另外，协程是结构化的并发，这是它的第二大优势。通过分析Job的源码，我们发现，一个Job可以拥有多个ChildJob；对应的，协程也可拥有多个“子协程”。
那么结构化并发带来的最大优势就在于，我们可以实现只控制“父协程”，从而达到控制一堆子协程的目的。在前面的例子中，parentJob.join()不仅仅只会等待它自身执行完毕，还会等待它内部的job1、job2、job3执行完毕。parentJob.cancel()同理。

最后呢，我也想跟你分享一下我学习协程的一些方法论。

其实，人学习新知识最快的方式，就是与旧的知识建立关联。举个例子，第一门计算机语言往往是最难学的，因为这是一个无中生有的过程；但当你掌握C、C++以后，再去学习Java、Python就会简单很多，因为你可以用脑子里的旧知识与其建立关联。

所以，虽然我在学习协程的时候也走了很多弯路，但总的来说，我做对了以下几件事，这里我也把经验分享给你。

第一，横向对比。在初次学习Kotlin协程失败以后，我去粗略学习了其他语言的协程，在那个时候，C#之类的协程学习资源更加丰富。通过对比C#、Go等语言的协程后，我理解了“广义协程”的概念，并且也知道yield、async、await只是一种广泛存在的协程模式。而当我理解了广义协程这个旧的知识之后，我突然发现Kotlin的协程就不难理解了。

第二，建立思维模型。这是我的一个“习惯”，不管是计算机网络、操作系统、数据结构、设计模式，还是其他领域，比如说高中的电磁学、大学的线性代数，在学习抽象知识的时候，我都喜欢虚构一些思维模型，来模拟它们内部的运行机制。

协程，就是一门非常抽象的技术，我喜欢用协程API编写一些简单的Demo来分析它们的行为模式，同时为其建立思维模型。这样一来，我脑海里的知识既不容易遗忘，也更成体系。比如，launch就像射箭；async就像钓鱼，这既是思维模型，同时也是在用旧知识学新知识。

第三，纵向深入。当我通过建立思维模型，对协程有了全面认识之后，我开始深入研究协程的源码。这时候，我从源码当中找到了更多的细节，来完善、支撑我脑子里的思维模型，从此，它们就不再是我凭空编造出来的东西了，因为证据都在源码里。这是一个自顶向下、逐渐深入的过程，反之则行不通。

所以，现在回过头来看，其实最重要的，还是用旧知识学新知识**。**希望我的方法能对你有所启发。

思考题

请问下面这段代码的执行结果是什么？你能分析出原因吗？

// 代码段15

fun main() = runBlocking {
    val job = launch {
        logX("First coroutine start!")
        delay(1000L)
        logX("First coroutine end!")
    }

    job.join()      
    val job2 = launch(job) {
        logX("Second coroutine start!")
        delay(1000L)
        logX("Second coroutine end!")
    }
    job2.join()
    logX("Process end!")
}

欢迎在留言区分享你的答案，也欢迎你把今天的内容分享给更多的朋友。

31 KiB Raw Blame History Unescape Escape