likes
comments
collection
share

Kotlin 协程之取消与异常处理探索之旅(下)

作者站长头像
站长
· 阅读数 17

前言

协程系列文章:

上篇分析了线程异常&取消操作以及协程Job相关知识,有了这些基础知识,我们再来看协程的取消与异常处理就比较简单了。 通过本篇文章,你将了解到:

  1. 协程取消的几种方式
  2. 协程异常处理几种方式
  3. 协程异常传递原理

1. 协程取消的几种方式

非阻塞状态时取消

先看Demo:

class CancelDemo {
    fun testCancel() {
        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                println("job1 start")
                Thread.sleep(200)
                var count = 0
                while (count < 1000000000) {
                    count++
                }
                println("job1 end count:$count")
            }
            Thread.sleep(100)
            println("start cancel job1")
            //取消job(取消协程)
            job1.cancel()
            println("end cancel job1")
        }
    }
}

fun main(args: Array<String>) {
    var demo = CancelDemo()
    demo.testCancel()
    Thread.sleep(1000000)
}

先启动一个子协程,它返回Job对象,当子协程成功运行后再取消它。 结果如下:

Kotlin 协程之取消与异常处理探索之旅(下)

该打印反馈出两个信息:

  1. 子协程启动并运行后才开始取消它。
  2. 子协程并没有终止运行,而是正常运行到结束。

你可能对第2点比较困惑,为啥取消没效果呢? 还记得我们上篇分析的线程的终止吗?在非阻塞状态下,通过Thread.interrupt()调用下仅仅只是唤醒线程并且设置标记位。 与线程类似,协程Job.cancel()函数仅仅只是将state值改变而已,当然我们可以主动获取协程当前的状态。

        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                println("job1 start")
                Thread.sleep(80)
                var count = 0
                //判断协程的状态,若是活跃则继续循环
                //isActive = coroutineContext[Job]?.isActive ?: true
                while (count < 1000000000 && isActive) {
                    count++
                }
                println("job1 end count:$count")
            }
            Thread.sleep(100)
            println("start cancel job1")
            //取消job(取消协程)
            job1.cancel()
            println("end cancel job1")
        }
    }

运行结果:

Kotlin 协程之取消与异常处理探索之旅(下)

从打印结果可以看出:

协程确实被取消了,可以通过Job.isActive 判断取消是否成功,若Job.isActive = false 则表示协程被取消了。

阻塞状态时取消

说到阻塞状态,你可能会说:"简单,我几行代码就给你演示了:"

    fun testCancel3() {
        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                Thread.sleep(3000)
                println("coroutine isActive:$isActive")//①
            }
            Thread.sleep(100)
            println("start cancel job1")
            //取消job(取消协程)
            job1.cancel()
            println("end cancel job1")
        }
    }

先猜猜①会打印吗?有同学说不会打印,因为Thread.sleep(xx)方法会抛出异常。 实际结果却是:①会打印。 认为不会打印的同学可能将线程的阻塞与协程的阻塞(挂起)混淆了,Thread.sleep(xx)是阻塞协程所在的线程,它是线程的专属方法,因此它会响应线程的中断:Thread.interrupt()并抛出异常,而不会响应协程的Job.cancel()函数。 协程阻塞(挂起)并不会阻塞其所在的线程,改造Demo如下:

    fun testCancel4() {
        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                //协程挂起
                println("job1 start")
                delay(3000)
                println("coroutine isActive:$isActive")//①
            }
            Thread.sleep(100)
            println("start cancel job1")
            //取消job(取消协程)
            job1.cancel()
            println("end cancel job1")
        }
    }

观察打印结果,我们发现①始终无法打印出来,我们有理由相信协程执行到delay(xx)时抛出了异常,导致后续的代码无法执行,接着验证猜想。

    fun testCancel4() {
        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                //协程挂起
                println("job1 start")
                try {
                    delay(3000)
                } catch (e : Exception) {
                    println("delay exception:$e")
                }
                println("coroutine isActive:$isActive")//①
            }
            Thread.sleep(100)
            println("start cancel job1")
            //取消job(取消协程)
            job1.cancel()
            println("end cancel job1")
        }
    }

如上,给delay(xx)函数加了异常处理,打印结果如下:

Kotlin 协程之取消与异常处理探索之旅(下)

果然不出所料,Job.cancel(xx)引发了delay(xx)异常,它抛出的异常为: JobCancellationException,该异常在JVM平台继承自CancellationException。

如何"优雅"地取消协程

结合阻塞/非阻塞状态下取消协程的分析,与线程处理方式类似:对于阻塞状态的协程,我们可以捕获异常,对于非阻塞的地方我们使用状态判断。 根据不同的结果来决定协程被取消后代码的处理逻辑。

    fun testCancel5() {
        runBlocking() {
            var job1 = launch(Dispatchers.IO) {
                try {
                    //挂起函数
                } catch (e : Exception) {
                    println("delay exception:$e")
                }
                if (!isActive) {
                    println("cancel")
                }
            }
        }
    }

2. 协程异常处理几种方式

try...catch异常

上面提及了协程的取消异常,它是比较特殊的异常,我们先来看看普通的异常处理。

    fun testException() {
        runBlocking {
            try {
                var job1 = launch(Dispatchers.IO) {
                    println("job1 start")
                    //异常
                    1 / 0
                    println("job1 end")
                }
            } catch (e: Exception) {
            }
        }
    }

先猜猜这样能够捕获异常吗?根据我们上篇线程异常捕获的经验,此处的子协程运行在子线程里,在子线程里发生的异常,主线程当然无法通过try 捕获到。 当然,万能的方式是在子协程里捕获:

    fun testException2() {
        runBlocking {
            var job1 = launch(Dispatchers.IO) {
                try {
                    println("job1 start")
                    //异常
                    1 / 0
                    println("job1 end")
                } catch (e : Exception) {
                    println("e=$e")
                }
            }
        }
    }

全局捕获异常

与线程类似,协程也可以全局捕获异常。

    //创建处理异常对象
    val exceptionHandler = CoroutineExceptionHandler { _, exception ->
        println("handle exception:$exception")
    }
    fun testException3() {
        runBlocking {
            //声明协程作用域
            var scope = CoroutineScope(Job() + exceptionHandler)
            var job1 = scope.launch(Dispatchers.IO) {
                println("job1 start")
                //异常
                1 / 0
                println("job1 end")
            }
        }
    }

如上Demo,先定义一个异常处理对象,然后将它与协程作用域关联起来。 当子协程发生了异常,这个异常往上抛给父Job,最后交给CoroutineExceptionHandler 处理。

Kotlin 协程之取消与异常处理探索之旅(下)

此时,ArithmeticException 异常被CoroutineExceptionHandler 捕获了。 注,虽然能够捕获异常,但是发生异常的协程还是不能往下执行了。

3. 协程异常传递原理

协程对异常的再加工

launch{}

花括号里的内容即为协程体,而执行这部分的逻辑在BaseContinuationImpl.resumeWith()函数里:

Kotlin 协程之取消与异常处理探索之旅(下)

你可发现此处的重点? 这里将协程体的执行加了try...catch 捕获了,也就是说不论协程体里发生了什么异常,在这里都能够被捕获。 你可能会问了,既然能够捕获,为啥还会有异常抛出呢?我们有理由相信,协程内部一定记录了这个异常,然后在某个地方再次将它抛出。 此处捕获了异常之后,将它构造为Result,并记录在变量outcome里,接着看看后续对这个值的处理。 流程有点长,直接看调用栈:

Kotlin 协程之取消与异常处理探索之旅(下)

重点看红色框里的两个函数。

#handleCoroutineExceptionImpl.kt
public fun handleCoroutineException(context: CoroutineContext, exception: Throwable) {
    try {
        //从context里取出异常处理对象,对应外部设置的全局捕获回调对象
        context[CoroutineExceptionHandler]?.let {
            //具体处理
            it.handleException(context, exception)
            //处理ok,直接退出
            return
        }
    } catch (t: Throwable) {
        handleCoroutineExceptionImpl(context, handlerException(exception, t))
        return
    }
    //再次尝试处理
    handleCoroutineExceptionImpl(context, exception)
}

internal actual fun handleCoroutineExceptionImpl(context: CoroutineContext, exception: Throwable) {
    // 尝试handler处理
    // 从当前线程抛出异常
    val currentThread = Thread.currentThread()
    currentThread.uncaughtExceptionHandler.uncaughtException(currentThread, exception)
}

如果我们定义了CoroutineExceptionHandler,那么使用该Handler处理异常,如果没有定义,则直接抛出异常。 以上即为协程对异常的再加工处理过程。

异常在协程之间的传递(Job)

先看Demo:

    fun testException4() {
        runBlocking {
            //声明协程作用域
            var rootJob = Job()
            var scope = CoroutineScope(rootJob)
            var job1 = scope.launch(Dispatchers.IO + exceptionHandler) {
                println("job1 start")
                //异常
                1 / 0
                println("job1 end")
            }

            job1.join()
            //检查父Job 状态
            println("rootJob isActive:${rootJob.isActive}")
        }
    }

rootJob 作为父Job,通过launch(xx)函数创建了子Job:job1。 等待job1执行完毕后,再检查父Job 状态。 打印结果如下:

Kotlin 协程之取消与异常处理探索之旅(下)

此时我们发现:

当子Job 发生异常时,会取消父Job。

除了对父Job 有影响,对其它兄弟Job 是否有影响呢? 继续做尝试:

    fun testException5() {
        runBlocking {
            //声明协程作用域
            var rootJob = Job()
            var scope = CoroutineScope(rootJob)
            var job1 = scope.launch(Dispatchers.IO + exceptionHandler) {
                println("job1 start")
                Thread.sleep(100)
                //异常
                1 / 0
                println("job1 end")
            }

            var job2 = scope.launch {
                println("job2 start")
                Thread.sleep(200)
                //检查jo2状态
                println("jo2 isActive:$isActive")
            }

            job1.join()
            //检查父Job 状态
            println("rootJob isActive:${rootJob.isActive}")
        }
    }

如上,父Job 分别创建了两个子Job:job1、job2,当job1 发生异常时,分别检测父Job与job2的状态,打印结果如下:

Kotlin 协程之取消与异常处理探索之旅(下)

很明显得出结论:

当子Job 发生异常时,会将异常传递给父Job,父Job 先将自己名下的所有子Job都取消,然后将自己取消,最后继续将异常往上抛。

这部分的传递依靠Job 链完成,上篇文章我们有深入分析过Job 结构:

Kotlin 协程之取消与异常处理探索之旅(下)

从源码分析其传递流程,先看调用栈:

Kotlin 协程之取消与异常处理探索之旅(下)

重点看notifyCancelling(xx)函数:

#JobSupport.kt
//list == 子Job 链表
private fun notifyCancelling(list: NodeList, cause: Throwable) {
    //回调,忽略
    onCancelling(cause)
    //取消所有子Job
    notifyHandlers<JobCancellingNode>(list, cause)//①
    //取消父Job
    cancelParent(cause) //②
}

分为两个要点:

#JobSupport.kt
private inline fun <reified T: JobNode> notifyHandlers(list: NodeList, cause: Throwable?) {
    var exception: Throwable? = null
    list.forEach<T> { node ->
        try {
            //遍历list,调用node
            node.invoke(cause)
        } catch (ex: Throwable) {
            //...
        }
    }
    //..
}

调用至此,实际上是job1.notifyCancelling(xx),因为job1没有子Job,因此①处list 里没有节点。

#JobSupport.kt
private fun cancelParent(cause: Throwable): Boolean {
    val isCancellation = cause is CancellationException
    val parent = parentHandle
    if (parent === null || parent === NonDisposableHandle) {
        //没有父Job,无法继续往上,停止
        return isCancellation
    }
    //取消父Job
    return parent.childCancelled(cause) || isCancellation
}

如果你看过上篇文章的分析,再看此处就比较容易了,此处再贴一下Node 结构:

#JobSupport.kt
//主要有2个成员变量
//childJob: ChildJob 表示当前node指向的子Job
//parent: Job 表示当前node 指向的父Job
internal class ChildHandleNode(
    @JvmField val childJob: ChildJob
) : JobCancellingNode(), ChildHandle {
    override val parent: Job get() = job
    //父Job 取消其所有子Job
    override fun invoke(cause: Throwable?) = childJob.parentCancelled(job)
    //子Job向上传递,取消父Job
    override fun childCancelled(cause: Throwable): Boolean = job.childCancelled(cause)
}

对于①来说,list 里的node 为ChildHandleNode,node.invoke(cause)其实调用的就是childJob.parentCancelled(job),而childJob 表示每个子Job。

    #JobSupport.kt
    public final override fun parentCancelled(parentJob: ParentJob) {
        //遍历Job 下的子Job,取消它们
        cancelImpl(parentJob)
    }

就这么层层遍历下去,直至取消完所有层级的子Job。

而对于②而言,parent.childCancelled(cause)==job.childCancelled(cause),而job 表示的是当前job 的父Job。

    #JobSupport.kt
    public open fun childCancelled(cause: Throwable): Boolean {
        //如果是取消异常,则忽略
        if (cause is CancellationException) return true
        //取消父Job
        return cancelImpl(cause) && handlesException
    }

这段代码透露出两个意思:

  1. 取消时候产生的异常称为"取消异常",该异常比较特殊,当某个job 发生异常时,它不会往上传递。
  2. 如果不是取消异常,则调用cancelImpl(xx)函数,该函数取消当前Job的所有子Job 与自己。

因为Job 链类似树的结构,因此异常传递是递归形式的。

Job 发生异常时,不仅取消自己名下的所有Job,也会取消父Job,往上递归直至根Job。

SupervisorJob 作用与原理

作用

子协程发生异常后,会取消父协程、兄弟协程的执行,这在有些场景是不合理的,因为伤害范围太广,明明是一个子协程的锅,非得所有协程来背。 还好官方考虑过这个问题,提供了SupervisorJob 来解决该问题。

    fun testException6() {
        runBlocking {
            //声明协程作用域
            var rootJob = SupervisorJob()
            var scope = CoroutineScope(rootJob)
            var job1 = scope.launch(Dispatchers.IO + exceptionHandler) {
                println("job1 start")
                Thread.sleep(100)
                //异常
                1 / 0
                println("job1 end")
            }
            var job2 = scope.launch {
                println("job2 start")
                Thread.sleep(200)
                //检查jo2状态
                println("jo2 isActive:$isActive")
            }

            job1.join()
            //检查父Job 状态
            println("rootJob isActive:${rootJob.isActive}")
        }
    }

仅仅改动了一个地方:将Job()换为SupervisorJob()。 结果如下:

Kotlin 协程之取消与异常处理探索之旅(下)

job1 发生异常的时候,job2 和父job都没受到影响。

原理 当需要取消父Job 时,势必会调用到:job.childCancelled(cause) 而SupervisorJob 重写了该函数:

#Supervisor.kt
private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
    override fun childCancelled(cause: Throwable): Boolean = false
}

不做任何处理,当然就不能取消父Job了,不能取消父Job,也就不能取消父Job 下的子Job。

对比Job()与SupervisorJob() 可知:

Kotlin 协程之取消与异常处理探索之旅(下)

取消异常的传递

job.childCancelled(cause) 表示要取消父Job,而该函数实现里有对取消异常进行了特殊处理,因此取消异常不会往上传递。

    fun testException7() {
        runBlocking {
            //声明协程作用域
            var rootJob = SupervisorJob()
            var scope = CoroutineScope(rootJob)
            var job1 = scope.launch(Dispatchers.IO + exceptionHandler) {
                println("job1 start")
                Thread.sleep(2000)
                println("job1 end")
            }

            var job2 = scope.launch {
                println("job2 start")
                Thread.sleep(1000)
                //检查jo2状态
                println("jo2 isActive:$isActive")
            }

            Thread.sleep(300)
            job1.cancel()
            //检查父Job 状态
            println("rootJob isActive:${rootJob.isActive}")
        }
    }

取消job1,不会影响父Job,也不会影响子Job。

当取消父Job时,查看子Job 是否受影响。

    fun testException8() {
        runBlocking {
            //声明协程作用域
            var rootJob = SupervisorJob()
            var scope = CoroutineScope(rootJob)
            var job1 = scope.launch(Dispatchers.IO + exceptionHandler) {
                println("job1 start")
                Thread.sleep(2000)
                println("jo1 isActive:$isActive")
            }

            var job2 = scope.launch {
                println("job2 start")
                Thread.sleep(1000)
                //检查jo2状态
                println("jo2 isActive:$isActive")
            }

            Thread.sleep(300)
            rootJob.cancel()
            //检查父Job 状态
            println("rootJob isActive:${rootJob.isActive}")
        }
    }

当父Job 取消时,子Job 都会被取消。

至此,所有内容分析完毕,小结一下之前的内容:

  1. 协程的异常会沿着Job链传递,子协程发生异常会导致父协程(祖父协程...)、兄弟协程的取消。
  2. 若要防止上述情况,需要使用SupervisorJob作为父Job,它将忽略子Job产生的异常,不将它传递出去。
  3. 取消异常不会向上传递,父协程的取消会导致其下所有的子协程被取消。

关于协程的取消与异常处理到此分析完毕,下篇将分析launch/async/delay/runBlocking 的使用、原理以及异同点。

本文基于Kotlin 1.5.3,文中完整Demo请点击

您若喜欢,请点赞、关注、收藏,您的鼓励是我前进的动力

持续更新中,和我一起步步为营系统、深入学习Android/Kotlin

转载自:https://juejin.cn/post/7128218056882389028
评论
请登录