上周我们把 Kotlin Coroutine 的基本 API 挨个讲了一下,也给出了一些简单的封装。

真是不要太给脸,就在前几天发布的 1.1 Beta 2 当中,所有协程的 API 包名后面都加了一个 experimental,这意味着 Kotlin 官方在 1.1 当中还是倾向于将 Coroutine 作为一个实验性质的特性的,不过,这也没关系,我们学习的心不以外界的变化而变化不是?

这一篇我们基于前面的基础来了解一下 Kotlinx.coroutines 这个库的使用,如果大家对它的实现原理有兴趣,可以再读一读上一篇文章,我们也可以在后面继续写一些文章来给深入地大家介绍。

1. 准备工作

就像前面我们说到的,1.1 Beta 2 当中协程相关的基础库的包名都增加了 experimental,所以我们在选择 kotlinx.coroutines 的版本的时候也一定要对应好编译器的版本,不然。。。你自己想哈哈。

我们强调一下,kotlin 的版本选择 1.1.0-beta-38,kotlinx.coroutines 的版本选择 0.6-beta,如果你恰好使用 gradle,那么告诉你一个好消息,我会直接告诉你怎么配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
buildscript {
ext.kotlin_version = '1.1.0-beta-38'
 
repositories {
jcenter()
 
maven {
url "http://dl.bintray.com/kotlin/kotlin-eap-1.1"
}
}
 
...
}
 
repositories {
jcenter()
 
maven {
url "http://dl.bintray.com/kotlin/kotlin-eap-1.1"
}
}
 
kotlin {
    experimental {
        coroutines 'enable'
    }
}
 
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
compile 'org.jetbrains.kotlinx:kotlinx-coroutines-core:0.6-beta'
}

2. 一个基本的协程的例子

这个例子是 kotlinx.coroutines 的第一个小例子。

1
2
3
4
5
6
7
8
fun main(args: Array<String>) {
launch(CommonPool) { // create new coroutine in common thread pool
delay(1000L) // non-blocking delay for 1 second (default time unit is ms)
println("World!") // print after delay
}
println("Hello,") // main function continues while coroutine is delayed
Thread.sleep(2000L) // block main thread for 2 seconds to keep JVM alive
}

这个例子的运行结果是:

1
2
Hello,
World!

其实有了上一篇文章的基础我们很容易知道,launch 方法启动了一个协程,CommonPool 是一个有线程池的上下文,它可以负责把协程的执行分配到合适的线程上。所以从线程的角度来看,打印的这两句是在不同的线程上的。

1
2
20170206-063015.015 [main] Hello,
20170206-063016.016 [ForkJoinPool.commonPool-worker-1] World!

这段代码的执行效果与线程的版本看上去是一样的:

1
2
3
4
5
6
thread(name = "MyThread") {
Thread.sleep(1000L)
log("World!")
}
log("Hello,")
Thread.sleep(2000L)

3. 主线程上的协程

我们刚才通过 launch 创建的协程是在 CommonPool 的线程池上面的,所以协程的运行并不在主线程。如果我们希望直接在主线程上面创建协程,那怎么办?

1
2
3
4
5
6
7
8
fun main(args: Array<String>) = runBlocking<Unit> {
launch(CommonPool) {
delay(1000L)
println("World!")
}
println("Hello,")
delay(2000L)
}

这个还是 kotlinx.coroutines 的例子,我们来分析一下。runBlocking 实际上也跟 launch 一样,启动一个协程,只不过它传入的 context 不会进行线程切换,也就是说,由它创建的协程会直接运行在当前线程上。

在 runBlocking 当中通过 launch 再创建一个协程,显然,这段代码的运行结果与上一个例子是完全一样的。需要注意的是,尽管我们可以在协程中通过 launch 这样的方法创建协程,但不要再协程当中通过 runBlocking 再来创建协程,因为这样做虽然一般来说不会导致程序异常,不过,这样的程序也没有多大意义:

1
2
3
4
5
6
7
fun main(args: Array<String>) = runBlocking<Unit> {
runBlocking {
delay(1000L)
println("World!")
}
println("Hello,")
}

运行结果:

1
2
World!
Hello,

大家看到了,嵌套的 runBlocking 实际上仍然只是一段顺序代码而已。

那么,让我们再仔细看看前面的例子,不知道大家有没有问题:如果我在 launch 创建的协程当中多磨叽一会儿,主线程上的协程 delay(2000L) 好像也没多大用啊。有没有什么方法保证协程执行完?

4. 外部控制协程

我们在上一篇文章当中只是对内置的基础 API 进行了简单的封装,而 kotlinx.coroutines 却为我们做了非常多的事情。比如,每一个协程都看做一个 Job,我们在一个协程的外部也可以控制它的运行。

1
2
3
4
5
6
7
8
fun main(args: Array<String>) = runBlocking<Unit> {
val job = launch(CommonPool) {
delay(1000L)
println("World!")
}
println("Hello,")
job.join()
}

job.join 其实就是要求当前协程等待 job 执行完成之后再继续执行。

其实,我们还可以取消协程,让他直接停止执行:

1
2
3
4
5
6
7
8
fun main(args: Array<String>) = runBlocking<Unit> {
val job = launch(CommonPool) {
delay(1000L)
println("World!")
}
println("Hello,")
job.cancel()
}

job.cancel 会直接终止 job 的执行。如果 job 已经执行完毕,那么 job.cancel 的执行时没有意义的。我们也可以根据 cancel 的返回值来判断是否取消成功。

另外,cancel 还可以提供原因:

1
job.cancel(IllegalAccessException("World!"))

如果我们提供了这个原因,那么被取消的协程会将它打印出来。

1
2
3
4
5
Hello,
Exception in thread "main" java.lang.IllegalAccessException: World!
at example13.Example_13Kt$main$1.doResume(example-13.kt:14)
at kotlin.coroutines.experimental.jvm.internal.CoroutineImpl.resume(CoroutineImpl.kt:53)
at kotlinx.coroutines.experimental.DispatchedContinuation$resume$1.run(CoroutineDispatcher.kt:57)

其实,如果你自己做过对线程任务的取消,你大概会知道除非被取消的线程自己去检查取消的标志位,或者被 interrupt,否则取消是无法实现的,这有点儿像一个人执意要做一件事儿,另一个人说你别做啦,结果人家压根儿没听见,你说他能停下来吗?那么我们前面的取消到底是谁去监听了这个 cancel 操作呢?

当然是 delay 这个操作了。其实所有 kotlinx.coroutines 当中定义的操作都可以做到这一点,我们对代码稍加改动,你就会发现异常来自何处了:

1
2
3
4
5
6
7
8
9
10
11
12
val job = launch(CommonPool) {
try {
delay(1000L)
println("World!")
} catch(e: Exception) {
e.printStackTrace()
}finally {
println("finally....")
}
}
println("Hello,")
job.cancel(IllegalAccessException("World!"))

是的,你没看错,我们居然可以在协程里面对 cancel 进行捕获,如果你愿意的话,你甚至可以继续在这个协程里面运行代码,但请不要这样做,下面的示例破坏了 cancel 的设计本意,所以请勿模仿:

1
2
3
4
5
6
7
8
val job = launch(CommonPool) {
try {
...
}finally {
println("finally....")
}
println("I'm an EVIL!!! Hahahaha")
}

说这个是什么意思呢?在协程被 cancel 掉的时候,我们应该做的其实是把战场打扫干净,比如:

1
2
3
4
5
6
7
8
val job = launch(CommonPool) {
val inputStream = ...
try {
...
}finally {
inputStream.close()
}
}

 
我们再来考虑下面的情形:
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
fun main(args: Array<String>) = runBlocking<Unit> {
val job = launch(CommonPool) {
var nextPrintTime = 0L
var i = 0
while (true) { // computation loop
val currentTime = System.currentTimeMillis()
if (currentTime >= nextPrintTime) {
println("I'm sleeping ${i++} ...")
nextPrintTime = currentTime + 500L
}
}
}
delay(1300L) // delay a bit
println("main: I'm tired of waiting!")
job.cancel() // cancels the job
delay(1300L) // delay a bit to see if it was cancelled....
println("main: Now I can quit.")
}

不得不说,kotlinx.coroutines 在几天前刚刚更新的文档和示例非常的棒。我们看到这个例子,while(true) 会让这个协程不断运行来模拟耗时计算,尽管外部调用了 job.cancel(),但由于内部并没有 care 自己是否被 cancel,所以这个 cancel 显然有点儿失败。如果你想要在类似这种耗时计算当中检测当前协程是否被取消的话,你可以这么写:

1
2
3
4
5
...
while (isActive) { // computation loop
...
}
...

isActive 会在 cancel 之后被置为 false。

其实,通过这几个示例大家就会发现协程的取消,与我们通常取消线程操作的思路非常类似,只不过人家封装的比较好,而我们呢,每次还得自己搞一个 CancelableTask 来实现 Runnable 接口去承载自己的异步操作,想想也是够原始呢。

5. 轻量级线程

协程时轻量级的,它拥有自己的运行状态,但它对资源的消耗却非常的小。其实能做到这一点的本质原因,我们已经在上一篇文章当中提到过,一台服务器开 1k 线程和 1k 协程来响应服务,前者对资源的消耗必然很大,而后者可能只是基于很少的几个或几十个线程来工作的,随着请求数量的增加,协程的优势可能会体现的更加明显。

我们来看个比较简单的例子:

1
2
3
4
5
6
7
8
9
fun main(args: Array<String>) = runBlocking<Unit> {
val jobs = List(100_000) {
launch(CommonPool) {
delay(1000L)
print(".")
}
}
jobs.forEach { it.join() } //这里不能用 jobs.forEach(Job::join),因为 Job.join 是 suspend 方法
}

通过 List 这个方法,我们可以瞬间创建出很多对象放入返回的 List,注意到这里的 jobs 其实就是协程的一个 List。

运行上面的代码,我们发现 CommonPool 当中的线程池的线程数量基本上维持在三四个就足够了,如果我们用线程来写上面的代码会是什么感觉?

1
2
3
4
5
6
7
8
9
fun main(args: Array<String>) = runBlocking<Unit> {
val jobs = List(100_000) {
thread {
Thread.sleep(1000L)
log(".")
}
}
jobs.forEach(Thread::join) // Thread::join 说起来也是 1.1 的新特性呢!
}

运行时,在创建了 1k 多个线程之后,就抛出了异常:

1
2
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)

嗯,又多了一个用协程的理由,对不对?

6. 携带值的 Job

我们前面说了,通过携程返回的 Job,我们可以控制携程的运行。可有时候我们更关注协程运行的结果,比如从网络加载一张图片:

1
2
3
4
suspend fun loadImage(url: String): Bitmap {
...
return ...
}

没错,我们更关注它的结果,这种情况我们该怎么办呢?如果 loadImage 不是 suspend 方法,那么我们在非 UI 线程当中直接获取他们:

1
2
3
val imageA = loadImage(urlA)
val imageB = loadImage(urlB)
onImageGet(imageA, imageB)

这样的操作有什么问题?顺序获取两张图片,耗时,不经济。所以传统的做法就是开两个线程做这件事儿,这意味着你会看到两个回调,并且还要同步这两个回调,想想都头疼。

不过我们现在有更好的办法:

1
2
3
val imageA = defer(CommonPool) { loadImage(urlA) }
val imageB = defer(CommonPool) { loadImage(urlB) }
onImageGet(imageA.await(),imageB.await())

代码量几乎没有增加,不过我们却做到了两张图片异步获取,并同时传给 onImageGet 以便继续后面的操作。

defer 到底是个什么东西?其实大家大可不必看到新词就感到恐慌,这东西用法几乎跟 launch 一样,只不过它返回的 Deferred 功能比 Job 多了一样:携带返回值。我们前面看到的 imageA 其实就是一个 Deferred 实例,而它的 await 方法返回的则是 Bitmap 类型,也即 loadImage(urlA) 的返回值。

所以如果你对协程运行的结果感兴趣,直接使用 defer 来替换你的 launch 就可以了。需要注意的是,即便你不调用 await,defer 启动的协程也会立即运行,如果你希望你的协程能够按需启动,例如只有你调用 await 之后再启动,那么你可以用 lazyDefer:

1
2
3
val imageA = lazyDefer(CommonPool) { loadImage(urlA) }
val imageB = lazyDefer(CommonPool) { loadImage(urlB) }
onImageGet(imageA.await(),imageB.await()) //这时候才开始真正去加载图片

7. 生成器

不知道大家对 python 的生成器有没有了解,这个感觉就好似延迟计算一样。

假设我们要计算 fibonacci 数列,这个大家都知道,也非常容易写,你可能分分钟写出一个递归的函数来求得这个序列,不过你应该知道递归的层级越多,stackOverflow 的可能性越大吧?另外,如果我们只是用到其中的几个,那么递归的函数一下子都给求出来,而且每次调用也没有记忆性导致同一个值计算多次,非常不经济。大家看一个 python 的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
def fibonacci():
yield 1 # 直接返回 1, 并且在此处暂停
first = 1
second = 1
while True:
yield first
first, second = first + second, first
 
 
a = fibonacci()
for x in a:
print x
if x > 100: break

前面给出的这种计算方法,fibonacci 函数返回一个可迭代的对象,这个对象其实就是生成器,只有我们在迭代它的时候,它才会去真正执行计算,只要遇到 yield,那么这一次迭代到的值就是 yield 后面的值,比如,我们第一次调用 fibonacci 这个函数的时候,得到的值就是 1,后面依次类推。

Kotlin 在添加了协程这个功能之后,也可以这么搞了:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
val fibonacci = buildSequence {
yield(1) // first Fibonacci number
var cur = 1
var next = 1
while (true) {
yield(next) // next Fibonacci number
val tmp = cur + next
cur = next
next = tmp
}
}
...
for (i in fibonacci){
println(i)
if(i > 100) break //大于100就停止循环
}

可以这么说,这段代码与前面的 python 版本功能是完全相同的,在 yield 方法调用时,传入的值就是本次迭代的值。

fibonacci 这个变量的类型如下:

1
2
3
public interface Sequence<out T> {
public operator fun iterator(): Iterator<T>
}

既然有 iterator 方法,那么我们可以直接对 fibonacci 进行迭代也就没什么大惊小怪的了。这个 iterator 保证每次迭代的时候去执行 buildSequence 后面的 Lambda 的代码,从上一个 yield 之后开始到下一个 yield 结束,yield 传入的值就是 iterator 的 next 的返回值。

有了这个特性,我们就可以构造许多“懒”序列,只有在用到的时候才去真正计算每一个元素的值,而且运算状态可以保存,每次计算的结果都不会浪费。

注:这个特性是被 Kotlin 标准库收录了的,并不存在于 kotlinx.coroutines 当中,不过这也没关系啦,kotlinx.coroutines 的 API 会不会在不久的将来也作为 Kotlin 标准库的内容出现呢?

8. 小结

这一篇的内容其实相对上一篇要简单一些,面对 kotlinx.coroutines 这样的框架,我们直接通过分析案例,将 coroutine 这么理论化的东西投入实际场景,让大家从感性上对其有个更加深入的认识。

当然,我们并没有深入其中了解其原理,原因就是上一篇我们为此做了足够的准备 —— kotlinx.coroutines 作为官方的框架,自然要实现得完善一些,但也是万变不离其宗。

写到这里,我想,我们还是需要有一篇文章再来介绍一些协程使用的一些注意事项,那么我们下一篇再见吧。