2.4-结构化并发：协程的结构化异常管理

已于 2024-08-03 01:35:06 修改
阅读量893 收藏 19
点赞数 19
分类专栏： 协程 文章标签： android
于 2024-08-03 01:27:16 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_31339141/article/details/140726558
版权

文章目录

协程的异常很多人都觉得很难，[难] 主要体现在两个地方，表面原因是它很复杂，深层原因是大多数人没有理解协程的异常结构化管理有什么用。

所以接下来我们就从这两个 [难] 的原因由浅到深的讲解协程的结构化异常管理。

下面的内容将会在 协程的结构化取消 的基础上讲解，建议提前了解才能更好掌握协程结构化异常流程。

协程结构化异常流程

协程结构化异常流程和取消流程的区别

了解结构化流程我们直接上示例代码：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	scope.launch {
		println("Parent started")
		launch {
			println("Child started")
			throw RuntimeException()
			println("Child finished")
		}
		println("Parent finished")
	}
	delay(10000)
}

输出结果：
Parent started
Parent finished
Child started
// 抛出异常

上面的代码在子协程抛出了异常，会导致父协程也被取消。更具体的说，当协程抛出异常时（除了 CancellationException），它往上、往下的整个父子协程树全都会因为这个异常而被取消掉。

实际上协程的异常处理和协程的取消用的是同一套逻辑。我们可以通过打印协程的状态验证：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	var childJob: Job? = null
	val parentJob = scope.launch {
		childJob = launch {
			println("Child started")
			delay(3000)
			println("Child done")
		}
		delay(1000)
		throw IllegalStateException("Wrong user!")
	}
	// 抛异常前打印状态
	delay(500)
	println("before, isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
	println("before, isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
	// 抛异常后打印状态
	delay(1000)
	println("after, isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
	println("after, isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
	delay(10000)
}

输出结果：
Child started // 子协程只打印了一行
before, isActive: parent - true, child - true
before, isCancelled: parent - false, child - false
// 抛出异常
after, isActive: parent - false, child - false
after, isCancelled: parent - true, child - true // 抛异常会导致协程都取消

上面的代码会延时 500ms 时打印父子协程的状态，在父协程 1s 后抛出异常，抛异常后再打印状态。可以看到父协程抛出了异常，父子协程的 isActive 都打印为 false，isCancelled 都打印为 true，说明父子协程都被取消了。

如果我们把异常换成了 CancellationException：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	var childJob: Job? = null
	val parentJob = scope.launch {
		childJob = launch {
			println("Child started")
			delay(3000)
			println("Child done")
		}
		delay(1000)
		throw CancellationException("Wrong user!")
	}
	// 抛异常前打印状态
	delay(500)
	println("before, isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
	println("before, isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
	// 抛异常后打印状态
	delay(1000)
	println("after, isActive: parent - ${parentJob.isActive}, child - ${childJob?.isActive}")
	println("after, isCancelled: parent - ${parentJob.isCancelled}, child - ${childJob?.isCancelled}")
	delay(10000)
}

输出结果：
Child started
before, isActive: parent - true, child - true
before, isCancelled: parent - false, child - false
after, isActive: parent - false, child - false
after, isCancelled: parent - true, child - true

可以看到除了 CancellationException 不会导致打印异常之外，父子协程状态 isActive 都打印 false，isCancelled 都打印 true，父子协程的状态更改都是一样的，也能印证异常流程和取消流程用的是同一套逻辑。

也可以理解为 当在协程抛出的是 CancellationException 时，协程会走简化版的异常流程，也就是取消流程。

那么取消流程比异常流程简化掉了什么呢？

  • 取消流程的连带取消只是向内的，即协程取消只会连带性的取消它的子协程

  • 异常流程的连带取消是双向的，不仅会向内取消它的子协程，还会向外取消它的父协程，每一个被取消的父协程序也会把它们的每个子协程取消，直到整个协程树都被取消

每个协程被取消时，它的父协程都会调用 childCancelled 函数：

JobSupport.kt

public open class JobSupport constructor(active: Boolean) : Job, ChildJob, ParentJob {
	// 每个协程被取消的时候，它的父协程都会调用这个函数
	// cause：触发子协程取消的那个异常
	// cancelImpl(cause) 就是取消父协程自己
	public open fun childCancelled(cause: Throwable): Boolean {
		if (cause is CancellationException) return true // 协程取消不会取消父协程
		return cancelImpl(cause) && handlesException // 普通异常会取消父协程
	}
}

在 childCancelled 函数判断异常类型为 CancellationException 时，协程取消不会连带性把父协程取消直接返回 true；如果是其他异常时，它会执行父协程的取消流程 cancelImpl。

用一个简单的示例验证下：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	scope.launch {
		launch {
			// 开启一个孙子协程
			launch {
				println("Grand child started")
				delay(3000)
				println("Grand child done")
			}
			delay(1000)
			// 在子协程取消
			throw CancellationException("Child cancelled!")
			// throw IllegalStateException("User invalid!")
		}
		println("Parent started")
		delay(3000)
		println("Parent done")
	}
	delay(500)
	delay(10000)
}

输出结果：
// 子协程抛出 CancellationException
Parent started
Grand child started
Parent done // 子协程取消，孙子协程没有打印，父协程有打印没有被取消

// 子协程抛出其他异常
Parent started
Grand child started
// 父协程和孙子协程都没有打印，都被取消了

上面的代码在子协程抛出 CancellationException 时，也就是子协程被取消了，可以看到父协程还是正常打印，但在子协程启动的孙子协程后续没有再打印了；而抛出其他异常时，父协程和孙子协程都没有再打印。

总结下结构化异常流程和结构化取消流程的区别：

  • 异常流程的子协程抛异常会导致父协程被取消；取消流程只会取消子协程

  • 异常流程只有内部抛异常的方式触发（也很好理解，调用函数触发异常也太奇怪了）；取消流程可以从外部 job.cancel() 或者内部抛 CancellationException 取消

  • 异常流程抛的异常除了用来取消协程，还会把这个异常暴露给线程世界；取消流程抛 CancellationException 只用来取消

子协程异常为什么要连带取消父协程？

或许看了上面的代码和示例代码验证后你会很疑惑：为什么异常流程除了取消子协程还要取消父协程？子协程抛出异常就只会影响它的子协程取消？

因为子协程一旦抛异常，影响了外部大流程的执行，让其他协程的执行失去了意义，父协程的执行也失去了意义。

协程的结构化有两个特性：

  • 父子协程连带性取消的性质：从正常逻辑来讲，当一个大流程都被取消的时候，它内部的子流程也就直接没用

  • 父协程等待子协程的性质：父协程会等待所有子协程都完成之后才完成自己，这也是子流程都完成了，整个大流程才能算是完成

子流程被取消，对外部大流程来说可能是一个正常的事件而已，所以子协程的取消并不会导致父协程取消。

但如果子协程是抛异常了（非 CancellationException 的异常），这通常被理解为子协程坏掉了，导致大流程无法完成，也就相当于父协程也坏掉了。所以协程因为普通异常而被取消，它的父协程也被以这个异常为原因而取消。

简单理解就是，子协程的异常通常意味着父协程的损坏，所以干脆把父协程取消。

CoroutineExceptionHandler

当我们在协程抛出异常时，和在线程内抛异常一样最终会导致崩溃，但在协程世界和线程世界之间如果还想捕获异常，还有一个方法：CoroutineExceptionHandler。

异常协程异常的最后一道拦截：CoroutineExceptionHandler

有一些协程的初学者在写协程代码的时候可能会这么写：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	try {
		scope.launch {
			throw RuntimeException()
		}
	} catch (e: Exception) {
		//
	}
	delay(10000)
}

输出结果：
// 抛出异常

上面的代码很简单，用 try-catch 包住协程的执行，想要捕获协程的异常，但是最终发现并没有捕获到。

为什么按上面这么写无法捕获到里面的异常呢？我把上面的代码换一下你就明白了：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	try {
		// 换成了线程，线程内部抛异常，也是没法捕获
		thread {
			throw RuntimeException()
		}
	} catch (e: Exception) {
		//
	}
	delay(10000)
}

我们把协程换成了线程，在线程内部抛异常，外部的 try-catch 也是无法捕获异常的，都在不同的线程了肯定不能捕获到异常。

那么刚才的协程也是同理，try-catch 只能捕获协程启动的代码，协程启动结束了 try-catch 代码块也就结束了。

协程太简洁了让我们产生了错觉，觉得 launch 的大括号里面和外面是同一套流程，但实际上协程都是并行的流程是无法互相 try-catch。

当然这也是因为协程是可以套着写启动子协程，写多了就会有一个错觉能用 try-catch 捕获异常，在线程我们很少像协程一样套着启动线程所以没这个想法：

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

如果我们想捕获协程的异常，可以用 CoroutineExceptionHandler 传给最外面的父协程：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	val handler = CoroutineExceptionHandler { _, exception -> 
		println("Caught $exception")
	}
	// CoroutineExceptionHandler 设置给最外层的协程
	scope.launch(handler) {
		launch {
			throw RuntimeException("Error!")
		}
	}
	delay(10000)
}

输出结果：
Caught java.lang.RuntimeException: Error!

对于一个多层结构的协程树，只要给它们最外层的父协程设置一个 CoroutineExceptionHandler，它里面所有子协程包括最外层父协程的异常都会集中到它这里来统一处理。

需要注意的是，CoroutineExceptionHandler 只能设置到最外面的父协程，设置到内层协程是没用的。

CoroutineExceptionHandler 为什么只能设置给最外层协程才有效？

在上面我们有提到使用 CoroutineExceptionHandler 必须将它设置给最外层的父协程才能生效捕获到子协程抛出的异常。

为什么只能设置给最外层呢？在讲解这个原理之前，我们先了解下 Java 提供的 UncaughtExceptionHandler。

fun main() = runBlocking {
	// 对所有线程异常都捕获的 UncaughtExceptionHandler
	Thread.setDefaultUncaughtExceptionHandler { t, e -> 
		println("Caught default: $e")
		// 记录异常日志收尾后将程序杀死或重启
	}
	val thread = Thread {
		throw RuntimeException("Thread error!")
	}
	// 针对单个线程的 UncaughtExceptionHandler
	// 优先级比 Thread.setDefaultUncaughtExceptionHandler 高
	// 如果线程处理的东西比较独立也可以针对线程设置
	// 但大多数时候都是用通用的设置
//	thread.setUncaughtExceptionHandler { t, e -> 
//	  println("Caught $e")
//	}
	thread.start()
}

输出结果：
Caught default: java.lang.RuntimeException: Thread error!

示例代码分别提供了两种方式：

  • thread.setUncaughtExceptionHandler：指定线程单独设置，线程抛出异常时捕获异常

  • Thread.setDefaultUncaughtExceptionHandler：通用设置，对所有线程都捕获异常

设置 UncaughtExceptionHandler 能让线程在抛出异常时被捕获到，它主要的作用是在线程发生了意料之外的未知异常（线程内没有 try-catch 我们有意识处理的异常）时用于记录使用，而不是将异常捕获吞掉让程序运行在异常混乱的状态。

UncaughtExceptionHandler 是异常处理的最后一道拦截，此时线程已经结束执行无法修复，只能收尾后杀死应用或重启。

比如在 Android 抛出异常就会直接 force close，也是用的 UncaughtExceptionHandler 捕获异常记录后让应用停止运行。

说完 UncaughtExceptionHandler，现在我们说回 CoroutineExceptionHandler。

CoroutineExceptionHandler 其实和针对单个线程设置 thread.setUncaughtExceptionHandler 是一样的，没法像线程那样设置 Thread.setDefaultUncaughtExceptionHandler 对全局协程处理。

因为协程是在线程之上的，所以有未知异常设置了 CoroutineExceptionHandler 就会在它这里捕获到，如果没有设置那也会被线程的 UncaughtExceptionHandler 捕获：

fun main() = runBlocking {
	Thread.setDefaultUncaughtExceptionHandler { t, e -> 
		println("Caught default: $e")
	}
	val scope = CoroutineScope(EmptyCoroutineContext)
	val handler = CoroutineExceptionHandler { _, e -> 
		println("Caught in Coroutine: $e")
	}
	scope.launch(handler) {
		launch {
			throw RuntimeException("Error!")
		}
	}
	delay(10000)
}

输出结果：
// scope.launch 设置 CoroutineExceptionHandler
Caught in Coroutine: java.lang.RuntimeException: Error!

// scope.launch 没设置 CoroutineExceptionhandler
Caught default: java.lang.RuntimeException: Error!

通常我们使用协程可以独立的完成一个完整的功能，在某个子协程抛出异常时能取消掉整个协程树的条件下（这在线程是很麻烦的），又能将异常汇报到一个地方（CoroutineExceptionHandler），然后做一些善后工作就很方便。

CoroutineExceptionHandler 的作用就是针对单个协程树的未知异常做善后工作，因为注册 CoroutineExceptionHandler 的目的是做善后工作，那么自然的它就得在最外层的父协程设置是最方便处理。

async() 对异常的处理

启动协程有两种方式：launch 和 async。

在之前的讲解协程结构化异常都是用的 launch，不过 async 对异常的处理其实跟 launch 基本上是一致的，但还是有一些区别：

fun main() = runBlocking {
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, e ->
        println("Caught in Coroutine: $e")
    }
    scope.launch(handler) {
        val deferred = async {
            delay(1000)
            throw RuntimeException("Error!")
        }
        launch {
            // async 抛出了异常，await() 也会抛出异常
            // 进而在它调用所在的协程也会影响抛出异常
            try {
                deferred.await()
            } catch (e: Exception) {
                println("Caught in await: $e")
            }

            // 验证协程是否被取消
            try {
                delay(1000)
            } catch (e: Exception) {
                println("Caught in delay $e")
            }
        }
    }
    delay(10000)
}

输出结果：
// 先触发了 async 抛出的异常而不是 CancellationException
// 因为结构化的异常流程还没走完，就先提前触发了 RuntimeException
Caught in await: java.lang.RuntimeException: Error!
Caught in delay kotlinx.coroutines.JobCancellationException: Parent job is Cancelling; job=StandaloneCoroutine{Cancelling}@1924f17a
Caught in Coroutine: java.lang.RuntimeException: Error!

上面的例子用 async 启动了一个协程，然后在另一个协程调用 await()，当 async 抛异常时，调用 deferred.await() 的位置也会抛异常，进而让所在的协程也被取消，最终最外层协程设置的 CoroutineExceptionHandler 捕获了异常。

但看输出的日志打印，deferred.await() 并不是抛出的 CancellationException，而是在 async 抛出的 RuntimeException。按照我们对结构化异常流程的理解，为什么在 deferred.await() 的 try-catch 捕获的不是 CancellationException？

实际上 在 async 里面抛异常时是有 [双重影响] 的：它不仅会用这个异常来触发它所在的协程树的结构化异常处理流程取消协程，还会直接让它的 await() 调用也抛出这个异常。

async 和 launch 的另一个异常流程的区别是，即使 async 作为最外层父协程，对 async 设置 CoroutineExceptionHandler 也是没有效果的：

fun main() = runBlocking {
    Thread.setDefaultUncaughtExceptionHandler { _, e ->
        println("Caught default: $e")
    }
    val scope = CoroutineScope(EmptyCoroutineContext)
    val handler = CoroutineExceptionHandler { _, e ->
        println("Caught in Coroutine: $e")
    }
    val deferred = scope.async (handler) {
        launch {
            throw RuntimeException("Error!")
        }
    }
    deferred.await()
    delay(10000)
}

输出结果：
// 异常被抛到线程世界，没有被 CoroutineExceptionHandler 拦截
Caught default: java.lang.RuntimeException: Error!

** async 不会往线程世界抛异常，因为 async 抛出的异常要给 await()，await() 还是运行在协程的；而 launch 会把内部的异常抛给线程世界是因为它已经是整个流程的终点了，CoroutineExceptionHandler 只能用在 launch 启动的最外层的父协程**。

SupervisorJob

在了解协程结构化异常管理机制后，我们知道子协程在抛出异常时，整个协程树都会被连带性的取消：

JobSupport.kt

public open class JobSupport constructor(active: Boolean) : Job, ChildJob, ParentJob {
	// 每个协程被取消的时候，它的父协程都会调用这个函数
	// cause：触发子协程取消的那个异常
	// cancelImpl(cause) 就是取消父协程自己
	public open fun childCancelled(cause: Throwable): Boolean {
		if (cause is CancellationException) return true // 协程取消不会取消父协程
		return cancelImpl(cause) && handlesException // 普通异常会取消父协程
	}
}

那么是否会有一种需求：子协程在抛出异常时不希望父协程也被连带性取消。为此协程也提供了 SupervisorJob。

SupervisorJob 中的 [Supervisor] 就是主管的意思，它和 Job 的区别是它重写了 childCancelled() 直接返回 false：

Supervisor.kt

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

SupervisorJob 的作用是，它的子协程因为非 CancellationException 异常取消时，父协程不会连带性的被取消。简单说就是 [取消你的时候是你的父协程，你抛异常的时候不是你的父协程]。

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	val supervisorJob = SupervisorJob()
	// supervisorJob 作为父协程
	scope.launch(supervisorJob) {
		throw RuntimeException("Error!")
	}
	delay(1000)
	println("Parent Job cancelled: ${supervisorJob.isCancelled}")
	delay(10000)
}

输出结果：
// 打印异常
Parent Job cancelled: false // 父协程没有被取消

SupervisorJob 在实际使用场景会有两种常见方式。

第一种常见的方式是 SupervisorJob 作为子协程和父协程之间的桥梁，类似半链条的方式：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	val parentJob = scope.launch {
		// 加上 coroutineContext.job 是为了让 SupervisorJob 和外部协程是父子关系
		// 此时 SupervisorJob 是外面协程的子协程，也是里面协程的父协程
		// 这时 SupervisorJob 子协程抛出异常不会影响外部父协程被取消
		// 外部父协程取消时又能正常取消子协程，SupervisorJob 半链条的写法很常用
		launch(SupervisorJob(coroutineContext.job)) {
			throw RuntimeException("Error!")
		}
	}
	delay(1000)
	println("Parent Job cancelled: ${parentJob.isCancelled}")
	delay(10000)
}

输出结果：
Parent Job cancelled: false

将 SupervisorJob 传给子协程作为它的父协程，同时为了不断开和外部协程的关系，SupervisorJob 也传入 coroutineContext.job 让外部协程取消时能正常取消子协程。

第二种方式是将 SupervisorJob 提供给 CoroutineScope：

val scope = CoroutineScope(SupervisorJob())
scope.launch {}

用这个 scope 启动的所有协程在抛异常时，都不会触发外面的 CoroutineScope 的取消；一旦外面的 CoroutineScope 取消，scope 启动的所有协程都会被取消。这也符合 SupervisorJob 的特性。

SupervisorJob 在异常管理时也会完全像一个 [最外层父协程] 一样工作：

fun main() = runBlocking {
	val scope = CoroutineScope(EmptyCoroutineContext)
	val parentJob = scope.launch {
		val handler = CoroutineExceptionHandler { _, e -> 
			println("Caught in handler: $e")
		}
		// 按照结构化异常管理机制，不是最外层父协程设置 CoroutineExceptionHandler 是无效的
		// 但在这里却生效能捕获了，说明 SupervisorJob 充当了 [最外层的父协程]
		launch(SupervisorJob(coroutineContext.job) + handler) {
			launch {
				throw RuntimeException("Error!")
			}
		}
	}
	delay(1000)
	println("Parent Job cancelled: ${parentJob.isCancelled}")
	delay(10000)
}

输出结果：
Caught java.lang.RuntimeException: Error!
Parent Job cancelled: false

当子协程抛出异常时，SupervisorJob 充当了 [最外层的父协程] 的角色，设置 CoroutineExceptionHandler 捕获子协程异常生效了。

SupervisorJob 就是一个 [会取消子协程，但不会被子协程取消] 的 Job。

总结

一、协程结构化异常流程

协程的异常处理和协程的取消用的是同一套逻辑：

  • 取消流程的连带取消只是向内的，即协程取消只会连带性的取消它的子协程

  • 异常流程的连带取消是双向的，不仅会向内取消它的子协程，还会向外取消它的父协程，每一个被取消的父协程序也会把它们的每个子协程取消，直到整个协程树都被取消

结构化异常流程和结构化取消流程的区别：

  • 异常流程的子协程抛异常会导致父协程被取消；取消流程只会取消子协程

  • 异常流程只有内部抛异常的方式触发；取消流程可以从外部 job.cancel() 或者内部抛 CancellationException 取消

  • 异常流程抛的异常除了用来取消协程，还会把这个异常暴露给线程世界；取消流程抛 CancellationException 只用来取消

二、子协程异常为什么要连带取消父协程？

子协程一旦抛异常，影响了外部大流程的执行，让其他协程的执行失去了意义，父协程的执行也失去了意义：

  • 子流程被取消，对外部大流程来说可能是一个正常的事件而已，所以子协程的取消并不会导致父协程取消

  • 子协程抛异常（非 CancellationException 的异常），这通常被理解为子协程坏掉了，导致大流程无法完成，也就相当于父协程也坏掉了。所以协程因为普通异常而被取消，它的父协程也被以这个异常为原因而取消

一句话总结：子协程的异常通常意味着父协程的损坏，所以干脆把父协程取消。

三、CoroutineExceptionHandler

1、UncaughtExceptionHandler 和 CoroutineExceptionHandler 的类比

在线程分别提供了两种方式拦截异常：

  • thread.setUncaughtExceptionHandler：指定线程单独设置，线程抛出异常时捕获异常

  • Thread.setDefaultUncaughtExceptionHandler：通用设置，对所有线程都捕获异常

UncaughtExceptionHandle 的作用是在线程发生了意料之外的未知异常（线程内没有 try-catch 我们有意识处理的异常）时用于记录使用，而不是将异常捕获吞掉让程序运行在异常混乱的状态。

UncaughtExceptionHandler 是异常处理的最后一道拦截，此时线程已经结束执行无法修复，只能收尾后杀死应用或重启。

CoroutineExceptionHandler 和针对单个线程设置 thread.setUncaughtExceptionHandler 是一样的，没法像线程那样设置 Thread.setDefaultUncaughtExceptionHandler 对全局协程处理。

对于一个多层结构的协程树，只要给它们最外层的父协程设置一个 CoroutineExceptionHandler，它里面所有子协程包括最外层父协程的异常都会集中到它这里来统一处理。

2、为什么 CoroutineExceptionHandler 只能设置在最外层协程才有效？

CoroutineExceptionHandler 的作用就是针对单个协程树的未知异常做善后工作，又因为协程结构化异常会有连带性的特性（异常流程双向取消并抛异常），最终异常会走到最外层的协程，让它从协程世界将异常抛到线程世界，那么自然的它就得在最外层的父协程设置是最方便处理。

四、async 的异常处理

  • 在 async 里面抛异常时是有 [双重影响] 的：它不仅会用这个异常来触发它所在的协程树的结构化异常处理流程取消协程，还会直接让它的 await() 调用也抛出这个异常。

  • async 作为最外层父协程，对 async 设置 CoroutineExceptionHandler 也是没有效果的。async 不会往线程世界抛异常，因为 async 抛出的异常要给 await()，await() 还是运行在协程的；而 launch 会把内部的异常抛给线程世界是因为它已经是整个流程的终点了，CoroutineExceptionHandler 只能用在 launch 启动的最外层的父协程

五、SupervisorJob

SupervisorJob 的作用是，它的子协程因为非 CancellationException 异常取消时，父协程不会连带性的被取消。简单说就是 [取消你的时候是你的父协程，你抛异常的时候不是你的父协程]。

当子协程抛出异常时，SupervisorJob 充当了 [最外层的父协程] 的角色，设置 CoroutineExceptionHandler 捕获子协程异常会生效。

一句话总结：SupervisorJob 就是一个 [会取消子协程，但不会被子协程取消] 的 Job。

VincentWei95
关注
专栏目录
Python中的并发与协程：从asyncio到aiohttp
AI天才研究院
09-15 1993
异步编程（Asynchronous Programming）是一种提高编程效率的方法，可以有效避免线程切换造成的资源浪费、等待延迟等问题。随着计算机硬件性能的不断提升，越来越多的应用程序开始采用异步编程模式。协程（Coroutine）是一种比线程更轻量级的执行体，它可以让任务在运行时状态保存上下文信息，并且可以在不同点继续执行。协程通过“yield from”或者其他类似关键字实现控制流转移，能够减少栈空间开销。
《Concurrency in Go》阅读笔记 -- 第三章：Go语言并发组件
Shiina_Orez的博客
06-14 1018
《Concurrency in Go》 本章节从goroutine入手，讲解go语言的各种并发原语。在讲解完goroutine之后，对于传统的内存同步访问的并发原语：sync包中的Mutex，RWMutex，Cond，Once，WaitGroup，Pool等进行了分析。在此之后着重讲了go语言的另一大特色：channel。在最后，讲解了如何结合channel的语法：select语句。 插一...
Golang_13: Go语言 并发编程：协程(goroutine)、通道(chan)、同步锁(Mutex)、WaitGroup、上下文(context)
谢TS的博客
05-26 1075
Go 语言的并发编程使用 协程（goroutine）实现。Go 语言的每一个并发执行的任务称为 goroutine，也包括执行 main() 函数的任务。Go 启动一个 goroutine 非常简单，在任何函数或方法调用前面加上 go 关键字，该函数或方法的调用即异步执行。
2-进程、线程、协程
wang_zhao_的博客
12-05 161
进程、线程进程为什么要引入进程进程的定义进程的组织链接方式索引方式进程的特征进程的状态及转化进程控制==进程通信==线程线程带来的变化==线程的好处==线程的状态 进程 为什么要引入进程       在早期的单道批处理系统中，内存中仅能有一道程序运行，只有该程序运行结束之后，才能调入下一道程序。CPU有大量的时间是在空闲等待 I/O 完成...
Go-知识并发控制WaitGroup
a18792721831的博客
06-01 1150
WaitGroup 通常用于等待一组“工作协程”结束的场景，其内部维护两个计数器，可以称为“工作协程”计数器和“等待协程”计数器。Add(delta int) 方法用于增加“工作协程”计数，通常在启动新的“工作协程”之前调用。Done 方法用于减少“工作协程”计数，每次调用递减1，通常在“工作协程”内部且在临近返回之前调用。Wait 方法用于增加“等待协程”计数，通常在所有“工作协程”全部启动之后调用。
图解Python 【第八篇】：网络编程-进程、线程和协程
weixin_30507481的博客
09-26 146
本节内容一览图： 本章内容： 同步和异步 线程（线程锁、threading.Event、queue 队列、生产者消费者模型、自定义线程池） 进程（数据共享、进程池） 协程 一、同步和异步 你叫我去吃饭，我听到了就立刻和你去吃饭，如果我没听到，你就一直叫我，直到我听见和你一起去吃饭，这个过程叫同步；异步过程指你叫我去吃饭，然后你就...
协程原理与设计
j简说Linux的博客
11-16 821
为了综合上述各种方案的优缺点，也即兼顾易用性和实用性，取得一种折中平衡的效果，我们可以考虑在协程中引入“Work-Stealing”机制，也即M:N协程（M个用户协程对应N个系统线程，为了区别于上述的N:1协程）。在更高的层次看，fiber和线程其实是类似的，所以fiber也提供了一套同步原语：Mutex，ConditionVariable，Latch。但是也有一个明显的缺点，各个线程之间无法均衡任务，导致一个线程中的某个协程运行过久，会影响到本线程的其他协程，也即不适合CPU-Bound型业务。
python（40）- 进程、线程、协程及IO模型
anglu0752的博客
05-08 337
一、操作系统概念 操作系统位于底层硬件与应用软件之间的一层。工作方式：向下管理硬件，向上提供接口。 操作系统进行进程切换：1.出现IO操作；2.固定时间。 固定时间很短，人感受不到。每一个应用层运行起来的程序都是进程。 二、进程与线程的概念 2.1 进程 程序仅仅只是一堆代码而已，而进程指的是程序的运行过程。需要强调的是：同一个程序执行两次，那也是两个进程。 ...
【并发基础】线程，进程，协程的详细解释
小七的博客
02-28 3067
一文带你彻底搞懂线程，进程，协程之间的区别和特点。
composite-jackson-2.4.zip
09-25
标题 "composite-jackson-2.4.zip" 暗示我们关注的是一个与Jackson库相关的项目，特别是关于数据序列化和反序列化的组件。Jackson是Java中广泛使用的JSON处理库，2.4版本可能指的是该项目的一个特定稳定版本。在开发...
【Python】基于协程的并发WebSocket通信实践
pupilxmk的博客
05-29 5428
目录1 什么是WebSocket2 并发通信的实现2.1 WebSockets库2.2 协程（Asyncio）2.3 功能描述2.4 具体实现2.4.1 客户端2.4.2 服务端2.5 效果 1 什么是WebSocket WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。 WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以
android 全面屏最底部栏沉浸式
sdaujz的博客
10-04 436
Android 系统 Bar 沉浸式完美兼容方案自 Android 5.0 版本，Android 带来了沉浸式系统 ba - 掘金 (juejin.cn)Activity的onCreate方法中添加。
在 Windows 11 安卓子系统中安装 APK 的操作指南
ailbj的博客
10-11 150
本指南旨在帮助用户在 Windows 11 上安装并运行带有 Google 框架的原生 Android 环境中的 APK。如果网络设置导致连通性检测失败，可能会出现“VirtWifi的连接受限”的提示。这样设置后，即使关闭所有应用窗口，WSA 也会继续运行，防止代理中断。安卓子系统上成功安装和运行带有 Google 框架的 APK。直接在已安装的 WSA 子系统中安装所需的代理应用程序。软件中好像有网络功能，不过无论如何，以下内容不是必要的。
Android Framework AMS（05）startActivity分析-2(ActivityThread启动到Activity拉起)
最新发布
wangdsh的博客
10-11 526
说明：本章节主要解读AMS通过startActivity启动Activity的整个流程的整个流程的第二阶段：从ActivityThread启动到Activity拉起。Android Framework AMS（04）startActivity分析-1(am启动到ActivityThread启动)
PHP简单登录系统
2301_79431343的博客
10-08 915
这是注销过程的第一步，确保会话中的所有数据都被清除。函数会删除服务器端与会话相关的文件或数据库记录，但不会删除客户端的Cookie（这就是为什么前面需要使用。：这是一个属性，用来关联标签与具体的表单控件。函数创建一个过期的Cookie，其名称与会话名称相同，有效期设置为过去的某个时间点（函数开始一个新的会话或者重新启动一个已存在的会话。：这是一个标签元素，用于为表单中的输入字段提供描述性的标签。这行代码开始一个新的会话或者恢复一个已经存在的会话。：定义了两个输入字段，一个是用户名，一个是密码。
20241004给荣品RD-RK3588-AHD开发板刷Rockchip原厂的Android12【HDMI0显示】
南岭笑笑生之家
10-04 1832
Z:\82临时了evb4+rp3588s_android12\kernel-5.10\arch\arm64\boot\dts\rockchip\rd-rk3588s-AHD.dts。Z:\82临时了evb4+rp3588s_android12\kernel-5.10\arch\arm64\boot\dts\rockchip\rp-lcd-hdmi0.dtsi。1、配置RK3588S的默认DTS为：rk3588s-evb4-lp4x-v10.dts。【Android12需要】配置为默认HDMI0显示。
Android app 上线google商店 sdk 需要升级到34 遇到 Android Gradle build error
qq_37069091的博客
10-11 97
笔记
20241004给荣品RD-RK3588-AHD开发板刷Rockchip原厂的Android12时永不休眠的步骤
南岭笑笑生之家
10-04 1342
20241004给荣品RD-RK3588-AHD开发板刷Rockchip原厂的Android12时永不休眠的步骤。【可以/可选尝试在DTS配置suspend的状态为：disabled】切换到dream_timeout资源，这里边有永不休眠的选项；RK3588-ANDROID12-永不息屏，不锁屏。Android11 设置菜单添加永不休眠选项。3、【改两个地方，但是只修改这里无效！RK3568-ANDROID11-不息屏。rk平台Android12屏幕永不休眠。
Linux内核2.4-7函数手册：驱动基础与原子操作
在Linux内核2.4-7版本中，驱动程序开发是核心部分，它涉及到与硬件交互和系统资源的管理。以下是一些关键知识点： 1. **驱动程序基础** - **Driver Entry and Exit Points**：每个驱动程序都有初始化和退出的入口...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值