转载

深入理解 Kotlin Coroutine(二)

上周我们把 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,那么告诉你一个好消息,我会直接告诉你怎么配置:

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 的第一个小例子。

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 
 }

这个例子的运行结果是:

Hello, 
 World!

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

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

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

thread(name = "MyThread") {  
     Thread.sleep(1000L)  
     log("World!")   
 } 
 log("Hello,")  
 Thread.sleep(2000L)  

3. 主线程上的协程

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

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 再来创建协程,因为这样做虽然一般来说不会导致程序异常,不过,这样的程序也没有多大意义:

fun main(args: Array<String>) = runBlocking<Unit> { 
     runBlocking { 
         delay(1000L) 
         println("World!") 
     } 
     println("Hello,") 
 }

运行结果:

World! 
 Hello,

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

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

4. 外部控制协程

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

fun main(args: Array<String>) = runBlocking<Unit> { 
     val job = launch(CommonPool) {  
         delay(1000L) 
         println("World!") 
     } 
     println("Hello,") 
     job.join()   
 }

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

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

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 还可以提供原因:

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

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

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 当中定义的操作都可以做到这一点,我们对代码稍加改动,你就会发现异常来自何处了:

    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 的设计本意,所以请勿模仿:

val job = launch(CommonPool) {  
     try { 
        ... 
     }finally { 
         println("finally....") 
     } 
     println("I'm an EVIL!!! Hahahaha") 
 }

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

val job = launch(CommonPool) { 
    val inputStream = ...
    try {
        ...
    }finally {
        inputStream.close()
    }
}

我们再来考虑下面的情形: kotlin 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 显然有点儿失败。如果你想要在类似这种耗时计算当中检测当前协程是否被取消的话,你可以这么写:

... 
 while (isActive) { // computation loop 
    ... 
 } 
 ...      

isActive 会在 cancel 之后被置为 false。

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

5. 轻量级线程

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

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

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 当中的线程池的线程数量基本上维持在三四个就足够了,如果我们用线程来写上面的代码会是什么感觉?

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 多个线程之后,就抛出了异常:

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

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

6. 携带值的 Job

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

suspend fun loadImage(url: String): Bitmap { 
     ... 
     return ... 
 }

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

val imageA = loadImage(urlA) 
 val imageB = loadImage(urlB) 
 onImageGet(imageA, imageB)

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

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

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:

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

7. 生成器

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

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

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 在添加了协程这个功能之后,也可以这么搞了:

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 这个变量的类型如下:

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 作为官方的框架,自然要实现得完善一些,但也是万变不离其宗。

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

原文  http://mp.weixin.qq.com/s/ZffDC_w4IPh0SNlo4hPKiQ
正文到此结束
Loading...