当前位置： 首页 > article >正文

Coroutine 基础三 —— 结构化并发（二）

article 2024/12/27 9:25:49

1、协程的结构化异常管理

如果一个协程抛异常，它所在的整个协程树上的其他协程（向上是父协程到根协程，向下是所有后代协程）都会被取消。因此协程发生异常的后果是十分严重的。

先讲原理，再说解决方案。

协程异常的处理与取消采用的是同一套逻辑。只不过取消协程抛出的是一个特殊异常 CancellationException，并进行特殊处理以取消协程。而协程异常是抛出其他普通的异常，

先查看抛出异常前后父子协程的状态：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    var childJob: Job? = null
    val parentJob = scope.launch {
        childJob = launch {
            println("Child started")
            delay(3000)
            println("Child finished")
        }
        delay(1000)
        throw IllegalStateException("Wrong User!")
    }
    // 抛异常之前打印两个协程的状态
    delay(500)
    println("isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
    println("isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
    // 抛异常之后打印两个协程的状态
    delay(1500)
    println("isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
    println("isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
    delay(10000)
}

运行结果：

Child started
isActive: parent - true, child - true
isCancelled: parent - false, child - false
Exception in thread "DefaultDispatcher-worker-1" java.lang.RuntimeException: Exception while trying to handle coroutine exception
	at kotlinx.coroutines.CoroutineExceptionHandlerKt.handlerException(CoroutineExceptionHandler.kt:33)
	at 
...
isActive: parent - false, child - false
isCancelled: parent - true, child - true

显而易见，在父协程抛出异常后，父协程被取消连带子协程一起被取消了。

注意，应用程序发生未被捕获的异常导致程序崩溃是 Android 的规则，而不是普通 JVM 的规则。JVM 中发生异常只会导致线程崩溃，而不会导致整个应用崩溃。因此上面的运行结果在崩溃后输出的父子协程状态数据也是正确的、可参考的。

假如让父协程抛出 CancellationException 代替 IllegalStateException，你会发现运行结果除了没有异常信息外，其余结果是一样的：

Child started
isActive: parent - true, child - true
isCancelled: parent - false, child - false
isActive: parent - false, child - false
isCancelled: parent - true, child - true

Process finished with exit code 0

这是因为，协程的取消与异常处理，在底层走的是同一套流程，只不过取消处理相对于较为完整的异常处理，过程有所简化。

二者的第一个不同是，取消的作用方向是单向的，只会取消自己与所有下层协程；而异常的作用方向是双向的，除了取消自己，也会向上取消所有上层协程，向下取消所有下层协程。

源码证据是在 Job 接口的实现类 JobSupport 中，该类作为所有 Job 的父类被继承。当取消子协程时：

    public open fun childCancelled(cause: Throwable): Boolean {
        if (cause is CancellationException) return true
        return cancelImpl(cause) && handlesException
    }

如果取消的原因是 CancellationException 就返回 true 不继续执行后续的 cancelImpl()，该函数内部正是处理取消父协程的代码。

为什么会有这种区别？这实际上体现了协程的设计思想。

两个协程之所以被写成父子协程的关系，是因为二者在逻辑上有相互包含的关系（当然，从运行角度，二者是并行关系），子协程执行的内容通常是父协程任务的子流程。

从正常的逻辑上讲，当一个大流程被取消时，它内部的子流程也就没用了。因此，才会给协程设计这种取消时连带的性质。类似的，父协程等待所有子协程完成后再结束，也是因为所有子流程完成后整个大流程才算完成，所以才有父协程等待子协程的性质。

子协程取消，对外部大流程而言可能只是一个正常的事件而已，因此子协程的取消不会导致父协程的取消。

但如果子协程抛异常了，通常意味着父协程被损坏，影响整个大流程。因此子协程抛异常，会导致父协程也以该异常为原因而取消。

二者的第二个不同，取消有两种方式，可以在协程内部抛 CancellationException，也可以在协程外部调用 cancel()；而异常流程的触发只有一种方式，就是在协程内抛异常。

当然，协程源码实际上也存在通过 cancel() 触发异常流程的函数：

    @Deprecated(level = DeprecationLevel.HIDDEN, message = "Since 1.2.0, binary compatibility with versions <= 1.1.x")
    public fun cancel(cause: Throwable? = null): Boolean

但是明显能看到该函数是 HIDDEN 的，不提供给开发者使用。实际上也很好理解，取消函数就触发取消流程，不要触发异常流程搞得逻辑混乱。

二者的第三个不同，用于取消的 CancellationException 除了用来处理取消协程之外就别无用处；而异常流程里抛出的异常对象除了用来取消协程，还会把该异常对象暴露给线程。直接体现就是本节举例的，协程抛出 IllegalStateException 导致线程崩溃输出 log 信息。

2、CoroutineExceptionHandler

先从一个例子看起：

// 示例代码 1
fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    scope.launch {
        try {
            throw RuntimeException()
        } catch (e: Exception) {
            
        }
    }
    delay(10000)
}

在协程内部将有可能抛出异常的代码用 try-catch 包起来，可以捕获异常。但倘若将 try-catch 挪到协程 launch 之外：

// 示例代码 2
fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)

    try {
        scope.launch {
            throw RuntimeException()
        }
    } catch (e: Exception) {

    }

    delay(10000)
}

这个异常就无法被捕获。这种形式类似于：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)

    try {
        thread {
            throw RuntimeException()
        }
    } catch (e: Exception) {

    }

    delay(10000)
}

子线程内抛出的异常，在主线程去捕获，肯定是捕获不到的。对于协程也是一样的，像示例代码 2 那样，try-catch 只能捕获到协程启动阶段可能抛出的异常，也就是 scope.launch 如果抛异常了，在它外面的 try-catch 可以捕获到。但对于协程运行阶段的代码，也就是 launch 大括号里面的代码，它是运行在 Default 线程池的，与 try-catch 都不在一个线程中，因此无法被捕获。想要捕获协程运行阶段的代码，可以像示例代码 1 那样把 try-catch 放在协程内部。

那么真的就没办法在协程外部捕获协程内部的异常了吗？答案是有，可以使用 CoroutineExceptionHandler，将其对象传给最外层协程：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught $exception")
    }
    // 这个 try-catch 无法捕获到 launch 内的异常
    try {
        scope.launch(handler) {
            throw RuntimeException()
        }
    } catch (e: Exception) {

    }

    delay(10000)
}

运行输出结果，异常没有抛出：

Caught java.lang.RuntimeException

使用 CoroutineExceptionHandler 一定要注意的是，CoroutineExceptionHandler 对象只能设置给最外层协程，这样最外层协程本身及其所有子协程所抛出的异常才可被捕获。如果设置给内层的某个子协程，即便是该子协程抛出异常也无法被捕获：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught $exception")
    }

    scope.launch(/*handler*/) {
        // 这样还是会抛异常
        launch(handler) {
            throw RuntimeException()
        }
    }

    delay(10000)
}

3、异常结构化管理本质

3.1 UncaughtExceptionHandler

捕获线程异常，除了 try-catch，还可以使用 UncaughtExceptionHandler：

fun main() = runBlocking<Unit> {
    val thread = Thread {
        throw RuntimeException("Thread error!")
    }
    // 在线程启动之前设置 UncaughtExceptionHandler
    thread.setUncaughtExceptionHandler { _, e -> println("Caught $e") }
    thread.start()
}

在线程启动之前，可以调用 setUncaughtExceptionHandler() 给该线程设置异常捕获，运行结果如下：

Caught java.lang.RuntimeException: Thread error!

除了给单个线程设置，也可以给所有线程设置默认的 UncaughtExceptionHandler：

fun main() = runBlocking<Unit> {
    Thread.setDefaultUncaughtExceptionHandler { _, e -> println("Default caught: $e") }

    val thread = Thread {
        throw RuntimeException("Thread error!")
    }
    thread.setUncaughtExceptionHandler { _, e -> println("Caught $e") }
    thread.start()

    thread {
        throw IllegalStateException("Wrong User!")
    }
}

运行结果：

Caught java.lang.RuntimeException: Thread error!
Default caught: java.lang.IllegalStateException: Wrong User!

结果显示，对于单独设置了 UncaughtExceptionHandler 的线程，会使用单独设置的 UncaughtExceptionHandler 捕获异常。未设置的线程会使用默认的 UncaughtExceptionHandler 捕获异常。

对于异常处理要有一些深入的思考。比如对于 Android 应用而言，发生未捕获的异常会发生 FC 导致应用崩溃关闭。为了避免 FC 的发生，在写代码的时候，对于可能发生异常的代码，我们会用 try-catch 把它包起来，在 catch 代码块中做一些补救工作，比如尝试解决问题（函数重新执行或者重置变量值等等）或重启应用 Todo。而不是单单只为了通过 catch 吞掉这个异常而不发生 FC，因为即便不 FC，抛异常也意味着你的应用没有正常工作。盲目的吞掉异常让软件在异常状态下继续运行，可能会产生无法预料的结果。

对于能提前预料的异常，可以使用 try-catch。但是往往会有没有预判的异常出现，跑出 catch 的捕获，最终被 UncaughtExceptionHandler 接收到。此时线程已经运行结束了，没有机会做补救工作了，只能做一些善后工作，使用通用的解决方案优雅地结束应用。一般有两步：收尾工作（如记录崩溃日志）以及重启或杀死应用：

Thread.setDefaultUncaughtExceptionHandler { _, e ->
    // 记录崩溃日志
    println("Default caught: $e")
    // 结束或重启应用
    exitProcess(1)
}

对于为单个线程设置的 UncaughtExceptionHandler，如果该线程只是在内部完成自己的工作，其崩溃不影响其他线程，那么可以在 UncaughtExceptionHandler 中尝试重启线程。当然，一个线程独立完成一件事的场景比较少见。

3.2 CoroutineExceptionHandler

让我们再回头看协程，如果没有捕获协程的异常，它最终会抛到线程的环境中，通过默认的 UncaughtExceptionHandler 可以捕获协程抛出的异常：

fun main() = runBlocking<Unit> {
    // 协程异常会被线程的 DefaultUncaughtExceptionHandler 捕获
    Thread.setDefaultUncaughtExceptionHandler { _, e ->
        println("Caught in DefaultUncaughtExceptionHandler: $e")
    }

    val scope = CoroutineScope(EmptyCoroutineContext)
	// 协程没有捕获异常
    val job = scope.launch {
        launch {
            throw RuntimeException()
        }
    }

    job.join()
}

使用 CoroutineExceptionHandler 为 job 这个协程树添加异常捕获处理，可以实现类似于为单个线程设置 UncaughtExceptionHandler 的效果：

fun main() = runBlocking<Unit> {
    Thread.setDefaultUncaughtExceptionHandler { _, e ->
        println("Caught in DefaultUncaughtExceptionHandler: $e")
    }

    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught in CoroutineExceptionHandler: $exception")
    }

    val job = scope.launch(handler) {
        launch {
            throw RuntimeException()
        }
    }

    job.join()
}

异常会被 CoroutineExceptionHandler 捕获：

Caught in CoroutineExceptionHandler: java.lang.RuntimeException

上一节我们说，很多任务都是通过多个线程完成的，因此在单个线程的 UncaughtExceptionHandler 做重启线程的适用场景并不多。但是我们看 CoroutineExceptionHandler 正是为一个协程树做异常善后工作所用的，将一个任务放在协程树中去执行，当某一个协程发生异常后，可以在 CoroutineExceptionHandler 中重启整个协程树，这就具有更广泛的实际意义了。

当然，CoroutineExceptionHandler 并不能替代 DefaultUncaughtExceptionHandler 去对整个应用做未知异常的善后工作，它只能针对一棵协程树。即便是纯协程应用，也是要通过 DefaultUncaughtExceptionHandler 来做通用拦截。

现在再来考虑，子协程的异常为什么要交到最外层父协程那里去注册 CoroutineExceptionHandler？因为注册 CoroutineExceptionHandler 的目的是善后，不管是哪个协程发生了异常，都是对整个协程树进行善后。因此设置给最外层协程最方便。

协程异常的结构化管理的本质，是针对协程发生的未知异常的善后方案。因为已知异常，直接通过在协程内部 try-catch 就可以修复，只有未知异常才会走到结构化异常处理流程。

4、async 的异常处理

async 的异常处理与 launch 的大致相同，但是因为 async 启动的协程，往往需要通过 await() 获取结果，会有两点比较明显的差异：

  1. 如果在 async 内发生异常，那么调用 await() 的协程会受到双重影响
  2. async 启动的协程在 await() 抛出异常，这个异常往往在协程内部就被 try-catch 捕获了。因此 async 作为最外层父协程存在时，不会向内部异常抛出到线程世界，给最外层的 async 设置 CoroutineExceptionHandler 也就没有作用了

先来看第一点，示例代码：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught in CoroutineExceptionHandler: $exception")
    }

    val job = scope.launch(handler) {
        val deferred = async {
            delay(1000)
            throw RuntimeException()
        }
        launch {
            // await 也会抛出 async 内抛出的 RuntimeException
            try {
                deferred.await()
            } catch (e: Exception) {
                println("Caught in await: $e")
            }

            // delay 用来验证 async 抛出的异常触发了结构化取消，导致
            // async -> job -> 当前协程被取消
            try {
                delay(1000)
            } catch (e: Exception) {
                println("Caught in delay: $e")
            }
        }
    }

    job.join()
}

运行结果：

Caught in await: java.lang.RuntimeException
Caught in delay: kotlinx.coroutines.JobCancellationException: Parent job is Cancelling; job=StandaloneCoroutine{Cancelling}@6463030a
Caught in CoroutineExceptionHandler: java.lang.RuntimeException

观察结果：

  • 因为 await 也会抛出 async 相同的异常，所以它的 try-catch 先捕获到异常
  • 然后由于 async 抛的异常先让自己，也就是 deferred 被取消，进而导致父协程 job 被取消，进一步导致 delay 所在的协程也要被取消，所以 delay 抛出 CancellationException
  • async 与 await 抛出的异常最终会被最外层协程的 CoroutineExceptionHandler 捕获

以上过程能看出，调用 await 的协程实际上受到双重影响：一是 await 会抛出与 async 同样的异常导致该协程进入异常处理流程；二是 async 抛出异常使得父协程与兄弟协程都会被取消，await 所在协程还会触发取消流程

再看第二点差异，示例代码：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught in CoroutineExceptionHandler: $exception")
    }
    scope.async {
        val deferred = async {
            delay(1000)
            throw RuntimeException("Error!")
        }
        launch(Job()) {
            try {
                deferred.await()
            } catch (e: Exception) {
                println("Caught in await: $e")
            }
        }
    }

    delay(3000)
}

由于 await 抛异常会被 try-catch 捕获，因此 async 就不会向线程世界抛出异常。但倘若没有为 await 添加 try-catch，其异常还是会被最外层的 async 抛到线程世界，需要 CoroutineExceptionHandler：

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught in CoroutineExceptionHandler: $exception")
    }
    scope.async(handler) {
        val deferred = async {
            delay(1000)
            throw RuntimeException("Error!")
        }
        launch(Job()) {
            deferred.await()
        }
    }

    delay(3000)
}

运行结果：

Caught in Coroutine: java.lang.RuntimeException: Error!

如果不设置 handler 给最外层 async，程序就会红字异常信息。所以我才觉得这里它讲的不对，它的意思是说 async 就用不到 CoroutineExceptionHandler，因为 async 不会向线程世界抛异常。但实际测试结果表明，async 不向线程世界抛异常，是因为在协程内对 await 用了 try-catch 把异常捕获了。如果没有捕获，异常还是需要通过最外层的 CoroutineExceptionHandler 来捕获处理。

5、SupervisorJob

SupervisorJob

@Suppress("FunctionName")
public fun SupervisorJob(parent: Job? = null) : CompletableJob = SupervisorJobImpl(parent)

private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
    // 子协程被取消，父协程会调用 childCancelled
    override fun childCancelled(cause: Throwable): Boolean = false
}

子协程被取消，父协程会调用 childCancelled。但对于 SupervisorJob 而言，它直接返回 false 表示子协程发生一般异常（非 CancellationException）时，不取消父协程。也就是说，SupervisorJob 不会因为自己的子协程发生普通异常而被取消，只有在子协程被取消而发生 CancellationException 时才会被取消。

fun main() = runBlocking<Unit> {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val supervisorJob = SupervisorJob()
    scope.launch(supervisorJob) {
        throw RuntimeException("Error!")
    }
    delay(100)
    println("Parent job cancelled: ${supervisorJob.isCancelled}")
    delay(1000)
}

在抛出异常后仍然会输出：

Parent job cancelled: false

说明子协程的异常没有导致 supervisorJob 被取消。


http://www.kler.cn/a/453365.html

相关文章：

  • 【自留】Unity VR入门
  • 【服务端】灰度引擎的过程中如何保证数据的一致性？
  • 解决 vue3 中 echarts图表在el-dialog中显示问题
  • PyQt实战——随机涂格子的特色进度条（十一）
  • 企业销售人员培训系统｜Java｜SSM｜VUE｜ 前后端分离
  • QT-【常用容器类】-QList类 QLinkedList类
  • 机器学习之PCA降维
  • 【开发问题记录】使用 Docker+Jenkins+Jenkins + gitee 实现自动化部署前端项目 CI/CD（centos7为例）
  • 优化SEO策略的长尾关键词研究与应用指南
  • Linux电源管理——CPU Hotplug 流程
  • Java中的异常处理机制
  • 力扣——102. 二叉树的层序遍历
  • 青少年科普教学系统平台的设计与实现springboot
  • 零样本图像分类：用Python和CLIP模型轻松实现
  • 【AI系列】从零开始学习大模型GPT (1)- Build a Large Language Model (From Scratch)
  • 2025年湖南省各地市国际、国家、地方、行业、团体标准制定奖励补贴政策
  • TouchGFX 工程的移植步骤（LTDC RGB 接口 LCD）
  • 『大模型笔记』评估大型语言模型的指标：ELO评分，BLEU，困惑度和交叉熵介绍以及举例解释
  • 《CS2》提示mss32.dll丢失的根源与应对策略。《CS2》提示mss32.dll丢失是什么原因？mss32.dll丢失怎么办？
  • 包管理工具npm、yarn、pnpm、cnpm详解
  • 报表工具DevExpress Reporting v24.2亮点 - AI功能进一步强化
  • CTF MISC 简单的脚本的撰写 -- 进制转换篇
  • Git_撤销本地commit_查找仓库中大文件
  • 【ETCD】【实操篇（十七）】 etcd 集群定期维护指南
  • springai 简易聊天机器人设计
  • 矩阵碰一碰发视频源码技术解析，支持OEM