本文是对 Kotlin Coroutines by Tutorials By Filip Babić and Nishant Srivastava 书本内容的转述和笔记，书本内容是受原版权保护的内容。
Chapter 2: 协程入门教程
所以你已经了解了大量关于异步开发的历史，是时候让你更多地了解协程以及它是如何工作的。
在本文中，你将
了解 Routine 以及程序如何控制其执行流程。
了解代码中的 Suspending Functions 和 Suspension Points。
启动（Launch） 你的第一个 Kotlin 协程，并在后台创建工作（Jobs）。
通过创建一些经典任务来实践你所学到的知识，包括向 UI 线程发布信息。
Executing routines 执行程序
这里的语言可能会看上去有点废话，贴一部分上一篇的内容帮助没有看过的人更好的理解 「一旦你启动一个协程，或者调用一个 Suspend 函数，这个函数的返回值结果会被很好的包裹起来，立刻返回给你，这个值就像一个玉米饼一样，从外观上看，馅饼皮是准备好了，但是直到你在使用到这个变量之前，或者说，吃这个馅饼之前，里面的代码不会被执行…‘getUser’ 函数将会被标记为 Suspend 函数，这意味着系统会在后台准备调用，你会得到一个未完成的、但包装好的玉米饼。但它可能还没有执行这个函数。系统会将它移到线程池中，在那里等待进一步的命令。一旦你准备吃玉米卷，并调用结果，程序就会阻塞，直到你得到一个准备好的玉米饼…知道了这一点，程序就可以跳过函数代码的其他部分，直到它到达使用这个函数返回结果的第一行代码，这被称为 Awaiting。然后到了使用返回结果的那个点，协程开始执行
getUser函数，如果getUser还没有执行完的话，协程就会 Suspend 程序，等到执行完了再从这里恢复，再继续执行。」
每当你启动一个程序，你的计算机就会创建一个叫做 主程序（Main Routine） 的东西。这是每个程序的核心部分，因为它是你设置和运行代码中所有其他组件的地方。
作为最基本的学习样本，你通常有一个 主函数（Main
Function），它打印出
Hello World。这个主函数是你程序的入口点，是主程序的一部分。
但随着你的程序越来越大，函数的数量和对其他函数的调用也越来越多。
每当你在主程序块中调用一些其他函数时，你就会启动一个叫做 子程序（Subroutine） 的东西。一个子程序只是嵌套在另一个程序中的程序。计算机将所有这些所有的程序放在 调用堆栈（Call Stack） 中，这个结构可以跟踪当前正在运行的程序以及当前程序被调用的情况。当一个子程序运行结束后，它就会从堆栈中 弹出（Popped off），控制权将被重新传回给调用它的子程序。最后，如果堆栈是空的，也没有其他东西可以运行，程序就结束了。
调用子程序就像做阻塞式调用。而协程可以认为是某种类型的子程序，但是你可以通过非阻塞式的方法调用子程序。正因为如此，标准的一个子程序和协程的主要区别在于，后者可以与其他代码并行运行。你可以启动并忘记它们，继续进行程序的其他部分。
Launch a Coroutine 启动协程
编写一个 Demo 如下，
fun main() {
(1..10000).forEach {
GlobalScope.launch {
val threadName = Thread.currentThread().name
println("$it printed on thread ${threadName}")
}
}
Thread.sleep(1000)
}这段代码会启动一万个协程，你可以看到许多的输出，每一行都在具体的写出在打印什么数字，在什么线程上。但是如果启动一万个线程，大概率你将会得到的是
OutOfMemoryException。
但是注意，因为协程的本质是一套线程框架，协程需要在线程的基础上运行，这个对比其实不够严谨，因为协程对应的应该是线程池 API，而不是原生线程，如果你用线程池来做这个实验得到的性能效果会和协程几乎一模一样。参考：扔物线 - 到底什么是「非阻塞式」挂起？协程真的比线程更轻量级吗？
协程本质上是提供了一套更好用，写起来，看上去比原有线程池，RxJava 等线程框架更易于理解和学习的线程框架。
协程并不直接提升异步的性能，而是简化异步开发的步骤，使得异步开发变得简单清晰，从而间接的使得你写出更有利于程序性能的代码。
在上面的代码中，launch
函数包裹了协程的主体，并传递之后的 lambda
代码块，这被称之为 协程构造器（Coroutine Builder）
其次，在启动协程时，你必须提供一个
作用域（Scope），因为协程是一种后台机制，它们并不真正关心自己的起点和整体的生命周期。设想一下，如果在协程完成之前，程序就结束了，这会发生什么？在这种情况下，你会使用一个叫做
GlobalScope 的东西，他表明了，在这个全局作用域
GlobalScope
下，协程的生命周期是和程序的生命周期绑定在一起的。正因为如此，你还需要将当前线程通过
Thread.sleep(1000) 进行暂停和阻塞，等待协程运行结束。
Building a Coroutine 构建一个协程
在 Kotlin 协程库中，有许多的协程生成方法供你使用，用以
launch 一个新的协程。而在前面的例子中，你调用了
launch 方法来使用协程构建器。
public fun CoroutineScope.launch(
context: CoroutineContext = EmptyCoroutineContext,
start: CoroutineStart = CoroutineStart.DEFAULT,
block: suspend CoroutineScope.() -> Unit ): Job正如你所看到的，启动函数有几个参数可以传入：CoroutineContext，CoroutineStart
和 lambda 函数。其中 lambda
函数决定了当你启动协程时将会发生什么，而前两个参数是可选的。
CoroutineContext
是一个持久性的数据集，它包含了关于当前协程的上下文信息。它还可以包含一些对象，例如该程序的
Job 和
Dispatcher，这两个对象我们将在后面提到。由于你在上面的代码中没有指定任何上下文，它将自动使用
EmptyCoroutineContext，这意味着你不关心
CoroutineScope
所处的上下文。如果你愿意，你可以创建自定义的上下文，但在大多数情况下，现有的上下文就足够了。
CoroutineStart
是你可以启动一个协程的模式，选项包括：
DEFAULT：根据上下文，立即安排开始执行这个协程LAZY：懒启动协程，必须通过job.start(),job.join等方式手动触发协程ATOMIC：与DEFAULT相同，但是无视过程中的任何取消操作UNDISPATCHED：先立刻在当前线程下执行，直到运行到该协程内部的第一个 Suspension Point 才开始调度执行（调度的属性和上下文由那个 Suspension Point 决定）
我们后面仍会提及这四种启动方式，一时半会看不明白完全不用担心，因为这牵扯了后面需要理解的一些知识
对于这四种模式的详细解释可参考 Benny Huo - 破解 Kotlin 协程 - 2 协程启动篇
最后，你需要指定一个 lambda
块，其中包含协程需要执行的代码。如果你检查一下前面对启动函数的定义，你会发现这个
lambda 块的签名与标准lambda
块有些不同。它的签名是
block: suspend CoroutineScope.() -> Unit。这是一个带有
CoroutineScope 接收器的
lambda。也就是说，你的代码块实际运行的空间是在
CoroutineScope 下，因此你可以由此嵌套的启动更多的协，并且这个
lambda 块是被标记为 suspend 的。
Scoping Coroutines 让协程工作在作用域里
正如你所学到的那样，协程的执行可以与主程序平行启动。然而这并不意味着，如果主程序结束或停止了，协程也会随之停止。至少在 Kotlin 协程 API 的早期几个版本中是这样的。这种无法控制的行为导致了一些奇奇怪怪的错误，即使你关闭了应用程序，应用程序也会把协程执行完毕。
为了解决像这样的生命周期管理问题，协程 API 团队实现了一个
CoroutineScopes。每个 作用域（Scope）
都知道它与哪个上下文有关，而且每个作用域都有自己的生命周期。如果你的协程所使用作用域的生命周期结束了，所有的
Job，即使是正在进行的，也会停止。这就是为什么，如果你尝试在没有
Thread.sleep
的情况下运行上述代码，可能会没有任何输出，或者只有一部分输出。
由于你必须在任意一种 CoroutineScope 上调用
launch 函数，有两种方法可以做到。你可以使用
GlobalScope，就像刚刚那段代码，你并不关心协程到底在哪里被启动。或者你可以自己实现
CoroutineScope 接口，并提供一个
CoroutineContext
的实例，你可以在这其中运行协程。显然，前者更简单，当你不关心协程的结果，也不关心
Job
的完成情况时，这是一个很好的选择。但是如果你想指定，使用协程结果的地方（比如UI线程），以及当你想把
Job 绑定到某个对象实例的生命周期，比如
Android 中的 Activity 实例时，后者将会更好。
有些情况下，生命周期或手动取消不一定会取消协程。你不仅要提供取消机制，而且还要写出合作的代码（Cooperative
Code）。这意味着你的函数要检查其包装的 Job
是否正在运行。在本文的后面，你会看到如何做到这一点。
Explaining Jobs 理解 Jobs
如果你已经注意到了，协程中的大多数东西都会指向
Job，你会创建并运行它。这个 Job 也是你之前使用
launch 函数所返回的。但什么是 Job
对象，你能用它做什么呢？
当你启动一个协程时，你基本上要求在要求系统执行你的
lambda
代码块，而这段代码实际上并不会被立即执行，而是被插入到一个队列中。
一个 Job
基本上是队列中协程的一个处理者（Handle）。它只有几个字段和函数，但它提供了很多可扩展性。例如，可以使用
join 函数在不同的 Job
实例之间引入一个依赖关系。例如 Job A 对 Job B
调用了 join 函数，这意味着在 B 完成之前，
A 不会被执行。也可以使用特定的协程构造器在 Job
实例之间建立 父子（Parent-child） 关系。一个
Job 中的任何的一个子 Job 没有完成，那么这个父
Job 就不能完成。所有的子 Job
必须完成，以使其父 Job 完成。
Job
的抽象结构，使得状态控制成为可能，这些状态的转换遵循下图描述的流程。
当你启动一个协程时，你创建一个 Job，它会先是处于
NEW 状态，然后直接进入 ACTIVE
状态，不过这取决于你使用的协程构建器的 CoroutineStart
参数（DEFAULT 就会直接被调度且直接被运行，就会直接进入
ACTIVE 状态，而 LAZY 便只会处于
NEW 状态）。当协程处于 NEW 状态，而没有进入
ACTIVE 状态时，你也可以使用 start 或
join 函数，将一个 Job 从 NEW
状态移动到 ACTIVE 状态。一个正在运行的协程总是处于
ACTIVE 状态。正如你在状态图中所看到的，Job
可以完成也可以被取消。
完成和取消对依赖型 Job
实例的作用是非常重要的。特别是，你可以看到一个 Job 一直处于
COMPLETING 状态，直到它的所有子 Job
完成。这种完成状态是内部的，如果从外部查询，会导致该 Job
变回 ACTIVE 状态。
状态是非常基本的属性，因为它们给你提供了关于协程正在进行的信息，以及你可以对它们做什么。你也可以查询一个
Job 的状态并采取相应的行动，或者简单地迭代这些子
Job 并对它们做一些事情。
创建一个 Job
是非常容易的，嵌套起来也不难。你已经看到了它们是如何完成工作的，但在被取消或出现异常的情况下，Job
会发生什么？
Canceling Jobs 取消 Jobs
当你启动一个协程并创建一个 Job
时，可能会发生很多奇奇怪怪的事情。异常可能发生，或者你可能需要取消这个
Job，因为可能你的程序中出现了一些新的情况。例如，假设你需要从网络上下载一个图片列表，每当你需要将一张图片显示在一个列表中的一行时，你就启动一个下载的协程。这个下载可能因为没有连接而失败，你必须处理相关的异常。或者下载可能被取消，因为用户在滚动列表时，图像在下载好之前就离开了屏幕。在使用协程时，理解如何管理这种情况是非常重要的。
通常情况下，一个 未捕获的异常（Uncaught Exception） 会导致整个程序崩溃。然而，由于协程有 Suspend 行为，如果发生异常，也可以 Suspend 并在以后管理。
更简单的是，你可以处理 Job
取消的方式。你可以通过调用相关 Job 实例上的
cancel 函数来实现。然后，系统就会很聪明地理解
Job 对象之间的依赖关系。如果你取消一个
Job，你会自动取消它的所有子
Job。如果它还有一个父 Job，那么这个父
Job 也会被取消。所以这是一个连锁反应，嵌套 Job
中的任何一个 Job 被取消，所有的 Job
都会被取消。
当然你也可以使用一个特殊的父
Job，它不要求所有的子Job都顺利完成。它们可以被取消，也可以独立失败。这种Job被称为SupervisorJob。
如前所述，即使你取消了一个
Job，你的代码也可能不关心取消事件。但是如果你想的话，你可以通过使用其
isActive 属性来检查这一点，使用 isActive
标志运行 while
循环比使用你自己的条件更安全。或者你至少应该在你的条件之上，尝试依赖
isActive。
Digging Deeper into Coroutines 深入了解协程
到目前为止，你已经启动了大量的协程，而且你已经知道了多个协程
Job
之间可以建立起他们的依赖关系。但是，在启动一个协程时，你还可以做其他事情。例如，你有一些工作必须要在运行前延迟一段时间，你可以用
delay 函数来做这件事。
fun main() {
GlobalScope.launch {
println("Hello coroutine!")
delay(500)
println("Right back at ya!")
}
Thread.sleep(1000)
}如果你运行上面的代码，你应该在控制台中看到
Hello coroutine，然后是，Right back at ya。delay
函数可以高效地等待给定的时间，然后在一切准备就绪后运行代码。
相较于 Thread.sleep()，delay
函数更加高效，因为 Thread.sleep()
会直接阻塞当前线程（它真的开始睡大觉了），直到时间停止，线程恢复。而
delay
函数则是会将当前线程调度到别的需要的地方，线程会持续的工作。而当
delay 时间结束时，则会使用其他线程恢复协程。
Dependent Jobs in Action 让 Job 之间依赖起来
到目前为止，你已经了解到，每当你启动一个协程时，你可以得到一个
Job 引用。你还可以在不同的 Job
实例之间建立依赖关系──但如何建立呢？只要把前面的代码换成这样就行了。
fun main(args: Array<String>) {
val job1 = GlobalScope.launch(start = CoroutineStart.LAZY) {
delay(200)
println("Pong")
delay(200)
}
GlobalScope.launch {
delay(200)
println("Ping")
job1.join()
println("Ping")
delay(200)
}
Thread.sleep(1000)
}通过上面的代码。
你首先启动了一个包含一些
delay并打印Pong字的协程，将创建的Job保存到job1的引用中。然后，你又启动了包含几个
println的协程，同时也调用了job1的join函数。
那么预期的输出会是什么？
如果你直接跟着代码走，你会期望看到 Pong，然后是两次
Ping，但事实并非如此。
正如你所看到的，你用 CoroutineStart.LAZY 的值作为
CoroutineStart，这意味着相关的代码将只会在你真正需要时被执行。
而在这里，「真正被需要」发生在第二个协程调用 job1 的
join 函数时。这就是为什么前面的代码的结果应该是
Ping，Pong，Ping。
Managing Jobs Hierarchy 管理 Job 的层级关系
在前面的代码中，你在不同的 Job
实例之间创建了一个依赖关系，但这不是那种父-子的关系。同样，用下面的代码来代替前面的代码，此时你可以使用with
函数，以避免重复出现 GlobalScope 接收器。
fun main(args: Array<String>) {
with(GlobalScope) {
val parentJob = launch {
delay(200)
println("I'm the parent")
delay(200)
}
launch(context = parentJob) {
delay(200)
println("I'm a child")
delay(200)
}
if (parentJob.children.iterator().hasNext()) {
println("The Job has children ${parentJob.children}")
} else {
println("The Job has NO children")
}
Thread.sleep(1000)
}
}依次翻阅上述代码。
在这里，你启动了一个协程，并将其
Job分配给parentJob引用。然后，你使用前一个
Job作为CoroutineContext启动另一个协程。能这么做的原因是Job也实现了CoroutineContext接口。在此之下，你在这里传递的由Job充当的CoroutineContext与当前激活的那个CoroutineContext会由此 合并（Merged），而由于你使用的是GlobalScope所以先前激活的上下文是EmptyCoroutineContext。
如果你运行前面的代码，你可以看到 parentJob 是如何拥有子
Job
的。如果你运行同样的代码，去掉第二个协程构造器的上下文，你可以看到父子关系没有建立，子
Job 也不存在。
Using Standard Functions with Coroutines 与标准函数一起使用协程
另一件你可以用协程做的事情是建立一种重试机制（类似于断线重连）。
使用标准库中的 repeat 函数，再配合上面学到的
delay 协程函数，你可以使得协程实现一种「重试」的逻辑。
fun main(args: Array<String>) {
var isDoorOpen = false
println("Unlocking the door... please wait.\n")
GlobalScope.launch {
delay(3000)
isDoorOpen = true
}
GlobalScope.launch {
repeat(4) {
println("Trying to open the door...\n")
delay(800)
if (isDoorOpen) {
println("Opened the door!\n")
} else {
println("The door is still locked\n")
}
}
}
Thread.sleep(5000)
}试着运行这段代码。你应该可以看到，有人在尝试开门几次后，最终成功了。
因此，使用 delay 函数，以及 Kotlin 标准库中的
repeat，你成功地建立了一个重试机制。你可以使用同样的流程来构建网络化的回退和重试逻辑。一旦你在稍后学习了如何从协程中返回值，你就会发现这可以有多么强大。
Posting to the UI Thread 推送到 UI 线程
目前为止，你所看到的协程的绝大部分功能都是内置于语言本身的，这些都相对简单。向 UI 线程推送信息也并不复杂，简而言之便是，启动一个新的协程，以 UI 调度器作为其线程的上下文即可。
由于我们讨论的是具有可见用户界面的应用程序，你可以在 Android、Swing
和 JavaFx 应用程序中向主线程推送信息。你可以用
Dispatchers.Main 作为上下文，以如下方式实现。
GlobalScope.launch(Dispatchers.Main) { ... }不过，你需要小心，因为这还不够。你可能还需要设置以下依赖关系之一。
implementation ’org.jetbrains.kotlinx:kotlinx-coroutines-android:...’
implementation ’org.jetbrains.kotlinx:kotlinx-coroutines-swing:...’
implementation ’org.jetbrains.kotlinx:kotlinx-coroutines-javafx:...’否则将会发生…
Exception in thread "DefaultDispatcher-worker-3"
java.lang.IllegalStateException: Module with the Main dispatcher is missing. Add dependency providing the Main dispatcher, e.g. ’kotlinxcoroutines-android’你可以通过 Swing 来尝试这个例子，将下面这段代码加入
build.gradle
implementation ’org.jetbrains.kotlinx:kotlinx-coroutines-swing:$kotlin_coroutines_version'然后你可以写入如下代码
fun main() {
GlobalScope.launch {
val bgThreadName = Thread.currentThread().name
println("I’m Job 1 in thread $bgThreadName")
delay(200)
GlobalScope.launch(Dispatchers.Main) {
val uiThreadName = Thread.currentThread().name
println("I’m Job 2 in thread $uiThreadName")
}
}
Thread.sleep(1000)
}在最外部的第一个协程会打印出它所执行的线程的名称。而在短暂的延迟之后，你使用
Dispatchers.Main 作为 CoroutineContext
启动另一个协程，这意味着这段代码将运行在主线程。
所以如果你运行这段代码，你会得到这样的结果：
I’m Job 1 in thread DefaultDispatcher-worker-1
I’m Job 2 in thread AWT-EventQueue-0第一个 Job 已经由一个 worker
线程在后台执行了，而第二个是在 Swing 中的主线程。