序言
如果对协程没有概念，不了解使用协程的好处，请参考《异步编程
》系列文章
引入协程库
kotlin协程是以一个lib包的形式引入的，参考： kotlinx.coroutines
这里摘录gradle方式的协程库引入
dependencies {
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.3'
}
请确认使用了最新版本的kotlin
buildscript {
ext.kotlin_version = '1.3.61'
}
语法讲解
此部分翻译至 https://kotlinlang.org/docs/reference/coroutines/basics.html，作了微调
第一个协程程序
我们使用协程来写一个helloworld程序
fun main() {
GlobalScope.launch { // 启动并后台运行一个协程
delay(1000L) // 非阻塞的暂停1s
println("World!")
}
println("Hello,") // 主线程继续执行
Thread.sleep(2000L) // 主线程睡眠2秒钟，保持当前jvm进程存活
}
输出：
Hello,
World!
本质上，协程是一种轻量级的线程。通过launch关键字启动，launch是一个协程构建器，携带一种CoroutineScope的上下文。上面的代码中，我们在Global Scope中启动了协程，这意味着，被启动的协程的生命周期与整个进程保持一致。
我们可以通过把GlobalScope.launch { ... }替换为thread { ... }并把delay(...)替换为Thread.sleep(...)来实现同样的效果（去试试吧！）
如果你把 GlobalScope.launch 替换为 thread（译者：还没来得及替换delay）, 编译器会报如下的错：
Error: Kotlin: Suspend functions are only allowed to be called from a coroutine or another suspend function
这是因为delay是一个suspending function并不会阻塞线程但是会阻塞协程，而且他只能在协程中被调用。
阻塞和非阻塞世界的桥梁
上面的例子在同一段代码中混用了 non-blocking delay(...) 和 blocking Thread.sleep(...) . 这样很容易让我们混淆哪些是blocking哪些不是blocking的代码. 让我们通过 runBlocking 协程构建器来提出阻塞的代码吧:
fun main() {
GlobalScope.launch { // 启动并在后台运行协程
delay(1000L)
println("World!")
}
println("Hello,") // 主线程直接继续执行
runBlocking { // 会阻塞主线程的执行
delay(2000L) // 保持jvm的持续运行
}
}
上面的代码执行结果是一样的，但是只用了非阻塞的delay。主线程执行了runBlocking代码块，并且主线程在其代码块内部执行完成之前会被阻塞。
上面例子里的代码可以被重写成更加通用的方式：
fun main() = runBlocking { // 启动主协程
GlobalScope.launch { // 启动新协程并在后台允许
delay(1000L)
println("World!")
}
println("Hello,") // 主协程此处直接继续执行
delay(2000L) // 睡两秒保持jvm运行
}
这里使用了runBlocking作为一个适配器，用来在最顶层启动主协程，我们声明了Unit作为他的返回值类型，因为main函数需要如此。
这也是对suspending函数做单元测试的一种方法：
class MyTest {
@Test
fun testMySuspendingFunction() = runBlocking {
// here we can use suspending functions using any assertion style that we like
}
}
等待一个任务的执行
上面几个例子里，都是通过主函数最后睡几秒来保持jvm进程的运行状态，这并不是很好，让我们来更精确的控制时间：
val job = GlobalScope.launch { //此处获得一个job的引用
delay(1000L)
println("World!")
}
println("Hello,")
job.join() // 主协程等待，直到job执行完毕
现在，执行结果依然相同，但代码好看多了！
结构化并发
如果想要在实际中使用协程，还需要考虑一些其他的事情。当我们使用GlobalScope.launch时，我们就创建了top-level的协程。虽然协程是轻量的，但协程运行时毕竟还是要消耗一些内存的。如果我们对新创建的协程没有保持引用，而协程恰巧hangs住了，如果我们跑了海量的协程并发生内存溢出...必须要手动管理已启动协程的引用，join 这些协程是容易出错的。
有更好的解决方案，我们可以在代码里使用结构化并发：基于当前操作的scope创建所需的协程，而不是使用GlobalScope。
在我们的例子里我们的main函数通过runBlocking协程构建器转换成一个协程函数。包括runBlocking在内的每一个协程构造器都会给它对应的代码块附加一个CoroutineScope实例。
我们可以基于这个scope创建新的协程，而不需显示的
join，因为外层的协程在这个scope内的所有协程介绍之前不会结束。所以我们可以让我们的例子更加简单：
fun main() = runBlocking { // this: CoroutineScope
launch { // launch a new coroutine in the scope of runBlocking
delay(1000L)
println("World!")
}
println("Hello,")
}
scope构建器
上文讲到每一个协程构建器会自动创建一个自己的scope，这节给大家介绍一下我们可以通过coroutineScope自定义创建scope。scope的作用就是scope不会结束在scope内部代码和内部launch的所有协程结束之前。
fun main() = runBlocking { // this: CoroutineScope
launch {
delay(200L)
println("Task from runBlocking")
}
coroutineScope { // Creates a coroutine scope
launch {
delay(500L)
println("Task from nested launch")
}
delay(100L)
println("Task from coroutine scope") // This line will be printed before the nested launch
}
println("Coroutine scope is over") // 在我们自定义的coroutineScope结束之前，这一行不会执行
}
输出
Task from coroutine scope
Task from runBlocking
Task from nested launch
Coroutine scope is over
runBlocking 和 coroutineScope 比较相似，因为他们都会等待内部代码块执行完毕也会等待其内部创建的协程执行完毕。区别是一个阻塞当前线程一个阻塞当前协程，所以他们一个是普通方法，一个是suspend方法。
方法拆分重构
原文这个章节的意思没理解透，只记录理解的部分：
当我们做代码拆分，把一部分代码单独拆分到另一个函数里时，被拆分出来的函数需要以suspend修饰，只有suspend修饰的函数才能在协程里被调用。
fun main() = runBlocking {
launch { doWorld() }
println("Hello,")
}
// this is your first suspending function
suspend fun doWorld() {
delay(1000L)
println("World!")
}
总结
coroutine builder
GlobalScope.launch {}
runBlocking
join
CoroutineScope
Scope Builder
suspend
系列文章快速导航：
java程序员的kotlin课（一）：环境搭建
java程序员的kotlin课（N）：coroutines基础
java程序员的kotlin课（N+1）：coroutines 取消和超时
java程序员的kotlin课（N+2）：suspending函数执行编排