23 如何启动协程？

从今天开始，咱们正式进入协程API的学习，一起来攻克Kotlin当中最关键的部分。这节课呢，我会给你介绍下如何启动协程，主要包括协程的调试技巧、启动协程的三种方式。这些都是学习协程最基本的概念，也是后续学习更多高阶概念的基础。

注意，在这节课当中，我会使用协程API编写大量的案例。我也希望你能够打开IDE，跟着我一起来运行对应的代码。通过这样的方式，你一定会有更多的收获。

好，接下来，让我们直接开始学习吧！

### 协程调试
想要学好Kotlin协程，掌握它的调试技巧很重要。一般来说，我们可以通过两种手段来进行调试：设置VM参数、断点调试。

### 协程VM参数
我们先来看第一种。具体的做法呢，其实很简单，我们只需要将VM参数设置成`-Dkotlinx.coroutines.debug`。
![](/media/202410/0_1730107452.gif)

完成这个设置后，当我们在log当中打印`Thread.currentThread().name`的时候，如果当前代码是运行在协程当中的，那么它就会带上协程的相关信息。具体我们可以看个代码的例子：
```kotlin
// 不必关心代码逻辑，关心输出结果即可
fun main() {
    GlobalScope.launch(Dispatchers.IO) {
        println("Coroutine started:${Thread.currentThread().name}")
        delay(1000L)
        println("Hello World!")
    }

println("After launch:${Thread.currentThread().name}")
    Thread.sleep(2000L)
}

/*
输出结果：
After launch:main
Coroutine started:DefaultDispatcher-worker-1 @coroutine#1
*/
```
可以看到，当代码处于协程当中的时候，`Thread.currentThread().name`是会带上协程相关的信息的，这里的`@coroutine#1`就代表了launch创建的协程。

### 断点调试协程
除了设置VM参数之外，我们还可以直接使用IDE的调试功能，直接以打断点的形式来调试协程。具体来说，主要有这样几个注意事项。
- 第一步，将IntelliJ升级到最新版本，目前我使用的版本是2021.3.2版本。
- 第二步，确保IDE自带的Kotlin编译器插件版本号大于1.4，目前我使用的是1.6.10。具体做法你可以参考下面的动图：
![](/media/202410/1_1730107528.gif)
- 第三步，为协程代码打断点，并且右击断点处，勾选suspend、All，这代表了我们的断点将会对协程生效。具体可以参考我下面的截图：
![](/media/202410/2024-10-28_172556_7724790.33542213074552873.png)
- 第四步，直接进行调试，当程序停留到断点处以后，我们就需要确保协程调试窗口已经被开启了。具体可以参考这个动图：
![](/media/202410/2_1730107584.gif)

让我们来单独看看最后出现的那个协程调试窗口：

![](/media/202410/2024-10-28_172650_1039030.8096848406773425.png)

在这个专属的协程调试窗口当中，我们可以看到很多有用的协程信息，包括：
- 当前协程的名字，这里是“coroutine#1”；
- 当前协程运行在哪个线程之上，这里是“DefaultDispatcher-worker-1”；
- 当前协程的运行状态，这里是“RUNNING”；
- 当前协程的“创建调用栈”。

通过调试，我们可以真真切切地看到，我们用launch创建了一个协程，“coroutine#1”，这个协程是运行在“DefaultDispatcher-worker-1”这个线程之上的。而通过这样调试的手段，我们也进一步验证了上节课提到的协程思维模型。

接下来，我们就一起来学习启动协程的三种方式。

### launch启动协程
上节课我们讲到协程思维模型的时候，其实是把协程想象成了更加轻量的线程。线程的启动方式我们都知道，也就是new Thread()、或者是thread{}。那么，如何才能启动一个真正的协程呢？如果你之前看过一些协程的教程，一定见过类似这样的代码：
```kotlin
/* delay 函数的定义
     注意这个关键字
          ↓                                            */
public suspend fun delay(timeMillis: Long) { ... }

// 仅用于研究，生产环境不建议使用GlobalScope
fun main() {
    // ①
    GlobalScope.launch {
        // ②
        delay(1000L)
        println("Hello World!")
    }

// ③
    Thread.sleep(2000L)
}

/*
输出结果；
Hello World!
*/
```
这段代码的逻辑很简单，核心代码只有三行，我已经用注释标记了，我们一个个看。
- 注释①，GlobalScope.launch{}，它是一个高阶函数，它的作用就是启动一个协程。GlobalScope是Kotlin官方为我们提供的“协程作用域”，这涉及到协程的“结构化并发”理念，我们会在后面的第16、17讲里解释。
- 注释②，delay()，它的作用就是字面上的意思，“延迟”。以上代码中，我们是延迟了1秒。从delay()的函数签名这里可以发现，它的定义跟普通的函数不太一样，它多了一个“suspend”关键字，这代表了它是一个挂起函数。而这也就意味着，delay将会拥有“挂起和恢复”的能力。
>在上节课我们提到过，delay()是非阻塞，那现在我们应该就终于明白了，既然它拥有“挂起和恢复”的能力，那么它肯定能实现非阻塞（如果你无法理解这句话，一定要回过头去看上节课的思维模型）。关于挂起函数的更多知识点，我们会在下节课介绍。
- 注释③，它的作用是让当前线程休眠2秒钟。

我们暂时先将注意力放在注释③这行代码上，很多协程的初学者都会很好奇，为什么上面的代码当中需要一个Thread.sleep(2000L)呢？它的作用是什么？

现在我们把它删掉，看看到底会发生什么。
```kotlin
fun main() {
    GlobalScope.launch {
        delay(1000L)
        println("Hello World!")
    }
}

/*
输出结果；
无
*/
```
很奇怪，当我们删掉线程休眠的代码以后，协程代码就无法正常工作了。这是为什么？为了弄清楚这个问题，其实，我们可以做一个类比，暂时先将协程代码改成线程代码。
```kotlin
fun main() {
    //              守护线程
    //                 ↓
    thread(isDaemon = true) {
        Thread.sleep(1000L)
        println("Hello World!")
    }
}

/*
输出结果；
无
*/
```
可以看到，当我们将代码改为线程以后，程序仍然没有输出任何结果。而这里，我们创建的Thread其实是一个“守护线程”。守护线程，就意味着当主线程结束的时候，它也会跟着被销毁。所以这样，相信你应该就能明白了，我们前面用GlobalScope创建的协程之所以不会正常运行，也是因为类似的原因。

那么，为了让问题能够更明确地暴露出来，我们可以为之前的代码增加一些日志。
```kotlin
fun main() {
    GlobalScope.launch {
        println("Coroutine started!")

delay(1000L)
        println("Hello World!")
    }

println("Process end!")
}
/*
输出结果；
Process end!
*/
```
根据输出结果，我们可以推测出：通过launch创建的协程还没来得及开始执行，整个程序就已经结束了。相应的，我们也就能推测出，之前案例中Thread.sleep(2000)的作用了，其实，它就是为了不让我们的主线程退出。

这里，你还会发现一个协程代码特殊的行为模式，那就是：它的代码不是按照顺序执行的。为了让这一点更加明显，我们再增加一些日志：
```kotlin
fun main() {
    GlobalScope.launch {                // 1
        println("Coroutine started!")   // 2
        delay(1000L)                    // 3
        println("Hello World!")         // 4
    }

println("After launch!")            // 5
    Thread.sleep(2000L)                 // 6
    println("Process end!")             // 7
}

/*
输出结果：
After launch!
Coroutine started!
Hello World!
Process end!
*/
```
根据这个程序运行结果，我们发现，以上的协程代码运行顺序是1、5、6、2、3、4、7。也就是说，launch并不会阻塞线程的执行，甚至，我们可以认为launch()当中Lambda一定就是在函数调用之后才执行的。当然，在特殊情况下，这种行为模式也是可以打破的，这一点我们会在第17讲中详细探讨。

那么，如果你足够细心，你会发现，我们通过launch启动一个协程以后，并没有让协程为我们返回一个执行结果，这其实就是典型的 Fire-and-forget 的应用场景。打个比方，launch一个协程任务，就像猎人射箭一样。

![](/media/202410/2024-10-28_173041_7659020.5854150778230903.png)

launch和射箭，有几个共同点：
- 箭一旦射出去了，目标就无法再被改变；协程一旦被launch，那么它当中执行的任务也不会被中途改变。
- 箭如果命中了猎物，猎物也不会自动送到我们手上来；launch的协程任务一旦完成了，即使有了结果，也没办法直接返回给调用方。

那么，launch为什么无法将结果返回给调用方呢？如果你去看launch函数的源代码，你就会发现，这个函数的返回值是一个Job，它其实代表的是协程的句柄（Handle），它并不能为我们返回协程的执行结果。
```kotlin
public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job { ... }
```
不过，从launch的函数签名这里，我们还是可以得到很多有用的信息的，我们一个个看。
首先是 CoroutineScope.launch()，代表了launch其实是一个扩展函数，而它的“扩展接收者类型”是CoroutineScope。这就意味着，我们的launch()会等价于CoroutineScope的成员方法。而如果我们要调用launch()来启动协程，就必须要先拿到CoroutineScope的对象。前面的案例，我们使用的GlobalScope，其实就是Kotlin官方为我们提供的一个CoroutineScope对象，方便我们开发者直接启动协程。

接着是第一个参数：CoroutineContext，它代表了我们协程的上下文，它的默认值是EmptyCoroutineContext，如果我们不传这个参数，默认就会使用EmptyCoroutineContext。一般来说，我们也可以传入Kotlin官方为我们提供的Dispatchers，来指定协程运行的线程池。协程上下文，是协程当中非常关键的元素，具体细节我会在17节课的时候再探讨。

然后是第二个参数：CoroutineStart，它代表了协程的启动模式。如果我们不传这个参数，它会默认使用CoroutineStart.DEFAULT。CoroutineStart其实是一个枚举类，一共有：DEFAULT、LAZY、ATOMIC、UNDISPATCHED。我们最常使用的就是DEFAULT、LAZY，它们分别代表：立即执行、懒加载执行。

最后一个参数，是一个函数类型的block，它的类型是“suspend CoroutineScope.() -> Unit”。这个类型看起来有点复杂，不过不要担心，我们可以一步步来推理，让我们先以“(Int) -> Double”这个函数类型开始：

```kotlin
fun func1(num: Int): Double {
    return num.toDouble()
}

val f1: (Int) -> Double = ::func1
```
上面的代码很好理解，`(Int) -> Double`代表了参数类型是Int，返回值类型是Double的函数，::func1这里，我们使用了函数引用的语法。接下来，我们再来看看`CoroutineScope.(Int) -> Double`意味着什么：

```kotlin
fun CoroutineScope.func2(num: Int): Double {
    return num.toDouble()
}

val f2: CoroutineScope.(Int) -> Double = CoroutineScope::func2
```
很明显，当我们在函数类型前面增加了一个接收者类型后，它的含义就变成了：这个函数应该是CoroutineScope类的成员方法或是扩展方法，并且，它的参数类型必须是Int，返回值类型必须是Double。

那么，“suspend (Int) -> Double”这个类型代表了什么呢？我们来看个例子：
```kotlin
suspend fun func3(num: Int): Double {
    delay(100L)
    return num.toDouble()
}

val f3: suspend (Int) -> Double = ::func3
```
有了前面的基础，相信你很容易就能理解了，`suspend (Int) -> Double`，其实就代表了一个“挂起函数”，同时它的参数类型是Int，返回值类型是Double。

到这里，我们还可以再做一次推理，请看下面的代码：
```kotlin
suspend fun CoroutineScope.func4(num: Int): Double {
    delay(100L)
    return num.toDouble()
}

val f4: suspend CoroutineScope.(Int) -> Double = CoroutineScope::func4
```
这时候，对于`suspend CoroutineScope.(Int) -> Double`这个函数类型，你应该也能轻松解释了。首先，它应该是一个“挂起函数”，同时，它还应该是CoroutineScope类的成员方法或是扩展方法，并且，它的参数类型必须是Int，返回值类型必须是Double。

那么现在，我们回过头再来看看launch()函数的第三个参数“suspend CoroutineScope.() -> Unit”，其实就能轻松分析出它的类型了。所以，当我们遇到复杂的函数类型的时候，一定不能害怕，只要我们一步步来拆解、推理，就一定能分析清楚了。

到这里，我们就弄清楚launch的作用了。我们通过调用launch()可以创建一个新的协程。那么，除了launch以外，还有其他办法启动协程吗？有的，那就是runBlocking。

### runBlocking启动协程
runBlocking跟我们前面学的launch的行为模式不太一样，通过它的名字，我们就可以看出来，它是存在某种阻塞行为的。让我们将前面launch的代码直接改为runBlocking，看看运行结果是否有差异。
```kotlin
fun main() {
    runBlocking {                       // 1
        println("Coroutine started!")   // 2
        delay(1000L)                    // 3
        println("Hello World!")         // 4
    }

println("After launch!")            // 5
    Thread.sleep(2000L)                 // 6
    println("Process end!")             // 7
}

/*
输出结果：
Coroutine started!
Hello World!
After launch!
Process end!
*/
```
通过分析上面的运行结果，我们可以发现，使用runBlocking启动的协程会阻塞当前线程的执行，这样一来，所有的代码就变成了顺序执行：1、2、3、4、5、6、7。这其实就是runBlocking与launch的最大差异。

为了验证这一点，我们可以将上面的例子再改造一下：
```kotlin
fun main() {
    runBlocking {
        println("First:${Thread.currentThread().name}")
        delay(1000L)
        println("Hello First!")
    }

runBlocking {
        println("Second:${Thread.currentThread().name}")
        delay(1000L)
        println("Hello Second!")
    }

runBlocking {
        println("Third:${Thread.currentThread().name}")
        delay(1000L)
        println("Hello Third!")
    }

// 删掉了 Thread.sleep
    println("Process end!")
}

/*
输出结果：
First:main @coroutine#1
Hello First!
Second:main @coroutine#2
Hello Second!
Third:main @coroutine#3
Hello Third!
Process end!
*/
```
请注意这里的输出结果，我们调用三次runBlocking，对应地，程序就启动了三个协程。另外还有一点：以上代码中，我们删掉了末尾的`Thread.sleep(2000L)`，而程序仍然按照顺序执行了。这就进一步说明，runBlocking确实会阻塞当前线程的执行。对于这一点，Kotlin官方也强调了：runBlocking只推荐用于连接线程与协程，并且，大部分情况下，都只应该用于编写Demo或是测试代码。

所以，请不要在生产环境当中使用runBlocking。

另外，相信你也注意到了，当我们调用runBlocking的时候，并不需要GlobalScope，这也是它跟launch之间的一大差异，具体，让我们来看看runBlocking的函数签名：
```kotlin
public actual fun  runBlocking(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T): T {
...
}
```
可以看到，runBlocking就是一个普通的顶层函数，它并不是CoroutineScope的扩展函数，因此，我们调用它的时候，不需要CoroutineScope的对象。前面我们提到过，GlobalScope是不建议使用的，因此，后面的案例我们将不再使用GlobalScope。

另外，你可以注意到它的第二个参数`suspend CoroutineScope.() -> T`，这个函数类型是有返回值类型T的，而它刚好跟runBlocking的返回值类型是一样的。因此，我们可以推测，runBlocking其实是可以从协程当中返回执行结果的。让我们来试试：
```kotlin
fun main() {
    val result = runBlocking {
        delay(1000L)
        // return@runBlocking 可写可不写
        return@runBlocking "Coroutine done!" 
    }

println("Result is: $result")
}
/*
输出结果：
Result is: Coroutine done!
*/
```
所以，从表面上看，runBlocking是对launch的一种补充，但由于它是阻塞式的，因此，runBlocking并不适用于实际的工作当中。那么，还有什么办法可以让我们拿到协程当中的执行结果吗？

答案就是：async。

### async启动协程
async，是在很多其他编程语言都存在的一种协程模式，比如C#。在Kotlin当中，我们可以使用async{} 创建协程，并且还能通过它返回的句柄拿到协程的执行结果。让我们看个简单的例子：
```kotlin
fun main() = runBlocking {
    println("In runBlocking:${Thread.currentThread().name}")

val deferred: Deferred = async {
        println("In async:${Thread.currentThread().name}")
        delay(1000L) // 模拟耗时操作
        return@async "Task completed!"
    }

println("After async:${Thread.currentThread().name}")

val result = deferred.await()
    println("Result is: $result")
}
/*
输出结果：
In runBlocking:main @coroutine#1
After async:main @coroutine#1 // 注意，它比“In async”先输出
In async:main @coroutine#2
Result is: Task completed!
*/
```
上面的代码中，我们直接使用runBlocking来实现了main函数。注意，由于runBlocking的最后一个参数的类型是“suspend CoroutineScope.() -> T”，因此在Lambda当中已经有了CoroutineScope，所以我们可以直接在runBlocking当中，用async启动一个协程。从程序的输出结果，我们也可以看到，确实存在两个协程，runBlocking启动的叫做“coroutine#1”；async启动的叫做“coroutine#2”。

另外，你应该还注意到了一个细节，那就是async启动协程以后，它也不会阻塞当前程序的执行流程，因为：“After async”在“In async”的前面就已经输出了。

这种行为模式在特殊情况下也是可以打破的，我们在第17讲的时候会介绍。

还有，请注意async{}的返回值，它是一个Deferred对象，我们通过调用它的await()方法，就可以拿到协程的执行结果。对比前面launch我们举的“射箭”的例子，这里的async，就更加像是“钓鱼”：
![](/media/202410/2024-10-28_171645_0503870.7183688387917473.png)

在我们钓鱼的时候，我们手里的鱼竿，就有点像是async当中的 Deferred对象。只要我们手里有这根鱼竿，一旦有鱼儿上钩了，我们就可以直接拿到结果。

这里，我们再来看看async的函数签名，顺便对比一下它跟launch之间的差异：
```kotlin
public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit // 不同点1
): Job {} // 不同点2

public fun  CoroutineScope.async(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> T // 不同点1
): Deferred {} // 不同点2
```
从上面的代码中，我们可以发现launch和async的两个不同点，一个是 block的函数类型，前者的返回值类型是Unit，后者则是泛型T；另外一个不同点在返回值上，前者返回值类型是Job，后者返回值类型是Deferred。而async可以返回协程执行结果的原因也在于此。关于Job与Deferred的更多细节，我们会在第16讲讨论。

这里，我制作了一张动图，来演示程序整体的执行流程：
![](/media/202410/0_1730106953.gif)

### 小结
由于协程是一个非常抽象的概念，因此，它的调试手段就显得尤为重要，我们研究协程的时候，通常有两种手段，一种是设置VM参数：-Dkotlinx.coroutines.debug。另一种是直接在IDE当中打断点，不过协程调试是在Kotlin 1.4之后才支持的新特性，因此我们要确保IDE和Kotlin的版本都更新到最新。

另外，我们还学到了三种启动协程的方式，分别是launch、runBlocking、async。
- launch，是典型的“Fire-and-forget”场景，它不会阻塞当前程序的执行流程，使用这种方式的时候，我们无法直接获取协程的执行结果。它有点像是生活中的射箭。
- runBlocking，我们可以获取协程的执行结果，但这种方式会阻塞代码的执行流程，因为它一般用于测试用途，生产环境当中是不推荐使用的。
- async，则是很多编程语言当中普遍存在的协程模式。它像是结合了launch和runBlocking两者的优点。它既不会阻塞当前的执行流程，还可以直接获取协程的执行结果。它有点像是生活中的钓鱼。
![](/media/202410/2024-10-28_171514_2006890.036716119412881554.png)

### 思考题
下面这段代码是我在当面试官时，问过其他候选人的，你能推测出这段代码的执行结果吗？
```kotlin
fun main() = runBlocking {
    val deferred: Deferred = async {
        println("In async:${Thread.currentThread().name}")
        delay(1000L) // 模拟耗时操作
        println("In async after delay!")
        return@async "Task completed!"
    }

// 不再调用 deferred.await()
    delay(2000L)
}
```