Kotlin协程取消与异常处理策略
Kotlin 协程取消机制
协程取消的基本概念
在 Kotlin 协程中，取消（Cancellation）是一种重要的机制，用于停止一个正在执行的协程。当一个协程被取消时，它应该尽快停止执行，并释放相关资源。协程取消并不等同于线程终止，它是一种更为优雅和可控的方式来结束协程的执行。
Kotlin 协程库提供了一套 API 来支持协程的取消操作。每个协程都有一个与之关联的 Job 对象，通过操作这个 Job 对象，我们可以对协程进行取消、启动等控制。例如，以下代码创建了一个简单的协程，并通过 job.cancel() 方法取消它：
import kotlinx.coroutines.*
fun main() = runBlocking {
val job = launch {
repeat(1000) { i ->
println("I'm sleeping $i ...")
delay(500L)
}
}
delay(1300L) // 等待一段时间
println("main: I'm tired of waiting!")
job.cancel() // 取消这个协程
job.join() // 等待协程真正结束
println("main: Now I can quit.")
}
在上述代码中，launch 启动了一个新的协程，并返回一个 Job 对象。主线程等待 1300 毫秒后，调用 job.cancel() 取消协程，然后通过 job.join() 等待协程完全停止。
取消的协作性
Kotlin 协程的取消是协作性的（Cooperative），这意味着协程需要主动检查取消请求，并在适当的时候响应取消。协程库提供了 isActive 属性来检查协程是否处于活动状态（未被取消）。例如：
import kotlinx.coroutines.*
fun main() = runBlocking {
val job = launch {
var i = 0
while (isActive) {
println("I'm still active $i ...")
delay(500L)
i++
}
}
delay(1300L)
println("main: I'm tired of waiting!")
job.cancel()
job.join()
println("main: Now I can quit.")
}
在这个例子中，协程通过 while (isActive) 循环不断检查是否被取消。只有当 isActive 为 true 时，才会继续执行循环体中的代码。当 job.cancel() 被调用后，isActive 变为 false，循环终止，协程停止执行。
取消的状态机
Kotlin 协程的 Job 对象有一个状态机来跟踪其状态。主要状态包括：
- New：协程刚创建，但尚未启动。
- Active：协程正在执行。
- Completing：协程正在结束执行，但尚未完全结束。例如，当一个协程调用了
delay等挂起函数，并且在挂起期间收到取消请求，它会进入Completing状态。 - Cancelling：协程正在被取消的过程中。
- Cancelled：协程已被取消。
- Completed：协程已正常完成执行。
可以通过 job.state 属性来获取 Job 的当前状态。例如：
import kotlinx.coroutines.*
fun main() = runBlocking {
val job = launch {
delay(1000L)
}
println("Job state: ${job.state}") // 输出 New
job.start()
println("Job state: ${job.state}") // 输出 Active
delay(500L)
job.cancel()
println("Job state: ${job.state}") // 输出 Cancelling 或 Cancelled，具体取决于取消的时机
job.join()
println("Job state: ${job.state}") // 输出 Cancelled
}
取消与挂起函数
许多挂起函数，如 delay，在挂起期间会检查取消请求。如果协程在调用这些挂起函数时被取消，挂起函数会立即抛出 CancellationException 并停止挂起。例如：
import kotlinx.coroutines.*
fun main() = runBlocking {
val job = launch {
try {
delay(10000L)
} catch (e: CancellationException) {
println("Caught CancellationException: $e")
}
}
delay(1300L)
println("main: I'm tired of waiting!")
job.cancel()
job.join()
println("main: Now I can quit.")
}
在上述代码中，delay(10000L) 会在协程被取消时抛出 CancellationException，我们可以在 try - catch 块中捕获它。
Kotlin 协程异常处理策略
未捕获异常的默认行为
在 Kotlin 协程中，如果一个协程抛出未捕获的异常，默认情况下，该异常会向上传播到它的父协程。如果父协程也没有处理这个异常，异常会继续向上传播，直到到达 CoroutineScope 的根节点。如果根节点也没有处理异常，默认行为是将异常打印到标准错误输出，并取消所有相关的子协程。
例如：
import kotlinx.coroutines.*
fun main() = runBlocking {
launch {
throw RuntimeException("This is an uncaught exception")
}
delay(1000L)
println("main: This line will be printed after delay")
}
在这个例子中，launch 启动的协程抛出了一个 RuntimeException，由于没有进行异常处理，这个异常会导致整个 runBlocking 作用域被取消，delay(1000L) 之后的代码不会执行，并且异常会被打印到标准错误输出。
try - catch 块处理异常
在协程内部，我们可以使用常规的 try - catch 块来捕获和处理异常。例如：
import kotlinx.coroutines.*
fun main() = runBlocking {
launch {
try {
throw RuntimeException("This is an exception")
} catch (e: RuntimeException) {
println("Caught exception: $e")
}
}
delay(1000L)
println("main: This line will be printed after delay")
}
在这个代码中，try - catch 块捕获了协程抛出的 RuntimeException，并进行了处理，因此不会影响 runBlocking 作用域内其他代码的执行。
CoroutineExceptionHandler
CoroutineExceptionHandler 是 Kotlin 协程提供的一种更灵活的异常处理机制。它可以在 CoroutineScope 级别设置，用于捕获该作用域内所有未处理的异常。
import kotlinx.coroutines.*
val handler = CoroutineExceptionHandler { _, exception ->
println("Caught $exception")
}
fun main() = runBlocking(handler) {
launch {
throw RuntimeException("This is an exception")
}
delay(1000L)
println("main: This line will be printed after delay")
}
在上述代码中，CoroutineExceptionHandler 被传递给 runBlocking，它会捕获 launch 协程抛出的未处理异常。这样，即使协程内部没有使用 try - catch 块，异常也能得到处理，不会导致整个作用域被取消。
SupervisorJob 与异常处理
SupervisorJob 是一种特殊类型的 Job，它在处理子协程异常时有不同的行为。与普通的 Job 不同，当一个使用 SupervisorJob 的父协程的子协程抛出异常时，其他子协程不会自动被取消。
import kotlinx.coroutines.*
fun main() = runBlocking {
val supervisor = SupervisorJob()
with(CoroutineScope(supervisor + Dispatchers.Default)) {
val job1 = launch {
delay(200L)
println("Job1: I'm working")
}
val job2 = launch {
delay(100L)
throw RuntimeException("Job2: I'm crashing")
}
job1.join()
job2.join()
}
println("main: All jobs are completed")
}
在这个例子中，job2 抛出了异常，但 job1 仍然会继续执行，因为它们的父协程使用了 SupervisorJob。如果使用普通的 Job，job2 抛出异常会导致 job1 也被取消。
异常处理与取消的关系
当一个协程抛出异常时，通常会导致它及其父协程被取消（除非使用了 SupervisorJob 等特殊情况）。异常处理和取消机制是紧密相关的。例如，在捕获到 CancellationException 时，通常不需要进行额外的取消操作，因为协程已经在取消过程中。
import kotlinx.coroutines.*
fun main() = runBlocking {
val job = launch {
try {
delay(10000L)
} catch (e: CancellationException) {
println("Caught CancellationException: $e")
}
}
delay(1300L)
println("main: I'm tired of waiting!")
job.cancel()
job.join()
println("main: Now I can quit.")
}
在这个例子中，delay 被取消时抛出 CancellationException，协程捕获并处理了这个异常，但协程本身已经处于取消过程中。
复杂场景下的协程取消与异常处理
嵌套协程的取消与异常处理
在嵌套协程的场景中，取消和异常处理会变得更加复杂。当外层协程被取消时，内层协程也应该相应地被取消。同样，内层协程抛出的异常会传播到外层协程。
import kotlinx.coroutines.*
fun main() = runBlocking {
val outerJob = launch {
val innerJob = launch {
try {
repeat(10) { i ->
println("Inner job: $i")
delay(500L)
}
} catch (e: Exception) {
println("Inner job caught exception: $e")
}
}
delay(1300L)
println("Outer job: Canceling inner job")
innerJob.cancel()
innerJob.join()
println("Outer job: Inner job is cancelled")
}
outerJob.join()
println("main: Outer job is completed")
}
在这个例子中，外层协程启动了一个内层协程。外层协程在等待 1300 毫秒后取消内层协程。内层协程通过 try - catch 块捕获可能的异常。
多个协程并发执行时的异常处理
当多个协程并发执行时，异常处理需要考虑如何处理不同协程抛出的异常。如果一个协程抛出异常，可能需要根据业务需求决定是否取消其他协程。
import kotlinx.coroutines.*
fun main() = runBlocking {
val job1 = launch {
delay(1000L)
throw RuntimeException("Job1: I'm crashing")
}
val job2 = launch {
delay(1500L)
println("Job2: I'm working")
}
try {
job1.join()
job2.join()
} catch (e: Exception) {
println("Caught exception: $e")
job2.cancel()
}
println("main: All jobs are either completed or cancelled")
}
在这个例子中，job1 在延迟 1000 毫秒后抛出异常，job2 继续执行。try - catch 块捕获 job1 抛出的异常，并在捕获到异常后取消 job2。
异步任务链中的取消与异常处理
在异步任务链中，一个任务的取消或异常可能会影响后续任务的执行。例如，当一个任务被取消时，后续任务可能也需要被取消。
import kotlinx.coroutines.*
fun main() = runBlocking {
val job1 = async {
delay(1000L)
println("Job1: Completed")
42
}
val job2 = async {
try {
val result1 = job1.await()
delay(1000L)
println("Job2: Using result from job1: $result1")
result1 * 2
} catch (e: Exception) {
println("Job2: Caught exception: $e")
-1
}
}
try {
val result2 = job2.await()
println("Final result: $result2")
} catch (e: Exception) {
println("Caught exception: $e")
}
}
在这个例子中，job2 依赖于 job1 的结果。如果 job1 抛出异常，job2 可以捕获并处理这个异常。如果 job1 被取消，job2 的 await 调用也会抛出 CancellationException，可以在 try - catch 块中进行处理。
资源管理与协程取消和异常处理
在协程执行过程中，可能会涉及到资源的获取和释放。当协程被取消或抛出异常时，需要确保资源能够正确释放。例如，打开的文件、数据库连接等资源。
import kotlinx.coroutines.*
import java.io.File
fun main() = runBlocking {
val job = launch {
val file = File("test.txt")
try {
file.writeText("Some data")
delay(1000L)
} catch (e: Exception) {
println("Caught exception: $e")
} finally {
file.delete()
}
}
delay(500L)
job.cancel()
job.join()
println("main: Job is cancelled")
}
在这个例子中，协程创建并写入一个文件，在 try - catch - finally 块中，无论协程是正常完成、取消还是抛出异常，finally 块中的代码都会执行，确保文件被删除，从而正确释放资源。
最佳实践与常见问题
最佳实践
- 主动检查取消：在协程内部，特别是在长时间运行的循环中，要主动使用
isActive属性检查协程是否被取消，以确保协程能够及时响应取消请求。 - 合理使用异常处理：根据业务需求，在协程内部使用
try - catch块捕获和处理特定类型的异常。对于整个CoroutineScope级别的异常处理，可以使用CoroutineExceptionHandler。 - 选择合适的 Job 类型：如果希望子协程之间的异常互不影响，可以使用
SupervisorJob。否则，使用普通的Job来确保异常能够正确传播和导致相关协程的取消。 - 资源管理：在协程中涉及资源操作时，要使用
try - finally块确保资源在协程结束（包括取消和异常）时能够正确释放。
常见问题
- 未处理的异常导致程序崩溃：忘记在协程内部或
CoroutineScope级别处理异常，可能会导致未捕获的异常向上传播，最终导致程序崩溃。要养成在协程中处理异常的习惯。 - 协程取消不彻底：如果协程内部没有正确检查取消请求，可能会导致协程在被取消后仍然继续执行某些操作。确保在长时间运行的操作中定期检查
isActive。 - 异常处理与取消的混淆：在处理
CancellationException时，不要进行额外的不必要的取消操作，因为协程已经在取消过程中。同时，要注意异常处理和取消机制之间的相互影响，根据业务需求正确处理。
通过深入理解 Kotlin 协程的取消与异常处理策略，并遵循最佳实践，我们能够编写出更加健壮和可靠的异步代码。在实际开发中，需要根据具体的业务场景，灵活运用这些机制，以确保程序的稳定性和性能。无论是简单的并发任务，还是复杂的异步任务链和资源管理场景，都能通过合理的协程取消与异常处理策略来实现高效、可靠的编程。