0x0、引言
上节《枯燥的Kotlin协程三部曲(上)——概念启蒙篇》，追根溯源，先了解并发相关的概念，尔后引出Kotlin协程：
真正的协程：
- 一种 非抢占式 / 协作式 的 任务调度模式，程序可 主动挂起或恢复执行；
- 基于线程，相对于线程轻量很多，可理解为 用户层 模拟线程操作；
- 上下文切换由用户去控制，避免大量中断参与，减少线程上下文切换与调度消耗的资源；
Kotlin中的「假协程」
语言级别并没有实现一种 同步机制(锁)，还是依靠Kotlin-JVM提供的Java关键字，锁的实现还是交给线程处理，因此Kotlin协程本质上只是一套「基于原生Java Thread API的封装」。只是这套API 隐藏了异步实现细节，让我们可以用「同步的方法来写异步操作」罢了。
关于Kotlin中的协程的分类有些争议：
没有分配函数调用栈，挂起点状态通过 状态机或闭包等语法实现，是 无栈协程 的无误，
但它又表现出 有栈协程 的特点：可在任意函数调用层及挂起，并转移调用权。
重要概念大概就这些，在学习Kotlin协程的具体API前，容笔者再给大家做些大有裨益的点思想工作。
0x1、思想工作
① 上下文环境
上下文环境 这个词你是怎么理解的？笔者的理解：完成某件事物时所需的前置资源。举个例子：
你周末早上起来，突然想吃韭菜猪肉饺，去市场买了饺子皮、韭菜和五花肉，把韭菜切好，肉绞好，准备开始 包饺子；突然基友夺命call，喊你出去 喝奶茶打王者，那么快乐的事情，怎么能不去。
不过材料都准备好了，晾着等变质或直接丢掉，显然不合理，咋能这样糟蹋粮食！ 可以把材料放冰箱，浪完回来再拿出来继续包，从例子中提炼一些东西：
- 1、包饺子和喝奶茶打王者，是两件 事物；
- 2、做包饺子这件事物的 前置条件 是准备好饺子皮，韭菜和肉馅这些材料（没有材料，包空气？）
- 3、换句话说包饺子这件事依赖一个 外部的环境(Context)，又称 上下文环境；
- 4、此时，基友喊你喝奶茶打王者，你需要停止包饺子这件事物；
- 5、暂停包饺子这件事物 和 把材料放冰箱里，这叫 挂起(suspend) 和 保存上下文环境。
- 6、浪完回来了继续包饺子 和 把冰箱的材料拿出来，这叫 恢复(resume) 和 恢复上下文环境。
注意：
这里的 挂起和恢复，是你的 主动行为，要和 堵塞 区分开来，堵塞是 被动行为，比如煮饺子，饺子包好了，但水还没烧开，此时只能 等待。
从例子里我们知道了，上下文环境 是 完成某件事务所需的前置资源，我再举一个例子：
你突然有了三个女友，她们也喜欢吃饺子，不过各有所好，
大桥未久喜欢玉米、三上悠亚喜欢白菜、桥本有菜喜欢香菜。
所以，在包韭菜馅的饺子时，你会把另外三种馅也包好，此时的事务变成四个：
包韭菜饺子、包玉米饺子、包白菜饺子、包香菜饺子
基友喊你奶茶王者，需要把这四种馅都放冰箱(挂起)，问题来了，该怎么放？
直接一把梭往冰箱里怼，肯定是不好的，不好拿是其次，最怕弄乱，毕竟以后你还会有
高橋聖子、山岸逢花、仲村美羽、小野六花、松下紗榮子、石原希望、葵司这些女友，是吧？一个简单的解决方法：用一个大袋子把对应的资源分别装好，而后贴个 写有女友名字的便利贴 以示区分，就不怕弄乱了~
我们通过写有女友名字的便利贴(不变性) 对 馅料资源 进行标记，以此保证了上下文环境的 唯一性。 对事物进行抽取，包饺子上下文环境如下：
女友名字的便利贴 + 肉馅 + 素馅 + 其他东西
扩展到 线程切换上下文环境，亦是如此：
线程Id + 线程状态 + 堆栈 + 寄存器状态等
扩展到Kotlin协程中的上下文环境 → CoroutineContext，以 键值对 的方式存储各种不同元素：
Job(协程唯一标识) + CoroutineDispatcher(调度器) +
ContinuationInterceptor(拦截器) + CoroutineName(协程名称，一般调试时设置)
妙啊~
② 结构化并发
了解完 上下文 是完成某项事务所需的 外部环境 后，我们再来说说 结构化并发，我们都知道：
多个线程间没有 级联关系，线程执行的上下文是整个进程，并发相对整个进程而非某个父线程。
这是 线程的非结构化，而从业务的角度看：
每个并发操作都是在处理一个任务，它可能属于某个父任务，也可能有自己的子任务。每个任务拥有自己的生命周期，子任务的生命周期理应继承父任务的生命周期。
这是 业务的结构化，Kotlin中的协程就是 结构化的并发：
在实际开发中，我们很少需要一个全局的协程，因为它总是跟程序中某个局部作用域相关，这个局部作用域是一个生命周期有限的实体，比如某次网络加载，新建的协程对象和父协程保持着「级联关系」。
具体表现
协程必须在作用域中才能启动，作用域中定义了一些父子协程的规则，Kotlin协程通过作用域来管控域中的所有协程。
作用域间可并列 或 包含，组成一个树状结构，这就是Kotlin协程中的结构化并发，说下规则：
先是作用域细分，有下述三种：
- 顶级作用域：没有父协程的协程所在的作用域；
- 协同作用域：协程中启动新协程(子协程)，此时子协程所在的作用域默认为协同作用域，子协程抛出的未捕获异常都将传递给父协程处理，父协程同时也会被取消；
- 主从作用域：与协同作用域父子关系一致，区别在于子协程出现未捕获异常时不会向上传递给父协程。
再接着是父子协程间的规则：
- 父协程被取消，所有子协程均被取消；
- 父协程需等待子协程执行完毕后才会最终进入完成状态，而不管父协程本身的协程体是否已执行完；
- 子协程会继承父协程上下文中的元素，如果自身有相同Key的成员，则覆盖对应Key，覆盖效果仅在自身范围内有效。
③ 协作式取消
在《Kotlin协程官方指南》中说到：取消是协作的，啥意思？ 线程的取消和协程的取消在原理上很类似，先从线程的取消说起，再过渡到协程的取消。
如果取消线程
读者的第一反应是不是调用Thread实例的 stop() 或 suspend()，可以是可以，不过不建议这样做。
前者过于粗暴，线程终止前没有对其做任何清除操作，具有固有的不安全性，而后者则具有固有的死锁倾向。
一种更好的方式：
在自己的Thread类中置入一个 标志-isAlive()，用于控制目标线程是活动还是停止。
如果该标志指示它要停止运行，可使其结束run()方法； 如果目标线程等待时间过长，则应使用interrupt()方法来中断该等待；
过渡到Kotlin协程，亦是如此，只是：
标志位isAlive() → isActive，中断方法interrput() → cancel()
就是这么简单，具体的取消操作详解，Job那里会讲解一波~
0x2、添加依赖
Kotlin标准库stdlib 中是不包含 Kotlin协程 的，需要 按需另外导入，如：
// 核心库：必要！公共API，使得协程在各个平台的接口得到统一 implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.8" // 平台库：当前平台对应的平台库，协程在具体平台的表现方式是有差异的(如Android) implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.8' // 测试库：协程的测试库，方便开发者在测试中使用协程 implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.3.8'
注：库的版本号必须一致，比如这里同为1.3.8，最新版本号及更多库信息可移步至官方Github仓库自行查阅：github.com/Kotlin/kotl…
附：IDEA使用Maven方式导入Kotlin协程依赖：
依次点击：File → Project Structure → Modules → + → Library... → From Maven...
输入库的关键词，点击OK，然后等待下载完毕即可。
