Kotlin协程崩溃了,我也崩溃了-协程异常原理入门

Kotlin 协程异常处理机制

一直以为协程的异常机制很复杂,网上讲的术语一大堆,什么传播机制、结构化并发、协程作用域......看得我脑壳疼。但最近我研究了一下,也自己写代码测了一下,发现其实没有那么难。

简单入门,如有错误,欢迎指正

下面介绍几个核心的概念

1. 一个协程崩了,默认会把整个协程组都崩掉

为什么要强调这个呢,在Android里面线程不也是这样的吗?我们在开发Android的时候,一个线程崩了,整个应用就挂了。比如下面的代码:

kotlin 复制代码
// Android Studio中运行,应用启动就崩了
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        thread {
            throw new RuntimeException("子线程崩了 ❌");
        }
    }
}

一启动就崩了,所以我一直以为子线程崩溃了整个应用就会崩,直到我在IDEA中运行了同样的代码,如下:

kotlin 复制代码
fun main() {
    thread {
        Thread.sleep(100)
        throw RuntimeException("线程 A 崩了 ❌")
    }
    thread {
        Thread.sleep(1000)
        println("线程 B 还活着 ✅")
    }
    Thread.sleep(1000)
    println("主线程也活着 ✅")
}

会发现一个线程崩了之后,主线程和其他的子线程竟然都还活着,于是我查了一下相关的资料,终于搞明白了。

原来是因为:在Java中线程未捕获的异常会由UncaughtExceptionHandler处理,而Java默认是没有实现的,而Android实现了这个UncaughtExceptionHandler。

看看Android是怎么实现的(在RuntimeInit中的KillApplicationHandler)

java 复制代码
public void uncaughtException(Thread t, Throwable e) {
    try {
                        ...
    } catch (Throwable t2) {
        ...
    } finally {
        // Try everything to make sure this process goes away.
        Process.killProcess(Process.myPid());
        System.exit(10);
    }
}

Android在finally中执行了Process.killProcess(Process.myPid())和System.exit(10),杀掉了线程,所以Android中线程异常应用是会崩溃的。

那么协程呢,运行下面这段代码:

kotlin 复制代码
import kotlinx.coroutines.*

fun main() {
    runBlocking {
        coroutineScope {
            launch {
                delay(100)
                throw RuntimeException("协程 A 崩了 ❌")
            }
            launch {
                delay(1000)
                println("协程 B 应该活着 ❌,但没机会执行")
            }
        }
    }
}

运行之后发现,一个协程崩了,其他的协程也没有继续执行了。

原来在Kotlin中 由此我们可以总结下:

  • 在线程中一个线程崩,不会影响其他线程。
  • 在Android中由于系统的处理,无论哪个线程崩,整个应用都会退出。(除非自己调用了setDefaultUncaughtExceptionHandler)
  • 而协程和线程是不一样的。如果在同一个 coroutineScope 里跑多个协程,只要一个出错,其他协程也会被一起取消。

2. 如果不想都崩掉,就用 supervisorScope

Kotlin 提供了一个 supervisorScope(或者 SupervisorJob()),它的意思是:

"我只管我自己,我崩了不管别人,别人崩了也别来拉我下水。"

kotlin 复制代码
fun main() {
    runBlocking {
        supervisorScope {
            launch {
                delay(100)
                throw RuntimeException("协程 A 崩了 ❌")
            }
            launch {
                delay(1000)
                println("协程 B 仍然正常 ✅")
            }
        }
    }
}

或者用SupervisorJob

kotlin 复制代码
fun main() {
    runBlocking {
        val supervisor = SupervisorJob()
        val scope = CoroutineScope(Dispatchers.Default + supervisor)

        scope.launch {
            delay(100)
            throw RuntimeException("协程 A 崩了 ❌")
        }

        scope.launch {
            delay(1000)
            println("协程 B 仍然正常 ✅")
        }

        delay(2000) // 等待所有子协程完成
    }
}

这段代码就能明显看出来:一个崩了,另一个还能活得好好的。


3. 最后的兜底:CoroutineExceptionHandler

如果忘了 try-catch,协程崩了可以用这个兜底。它会在 launch 抛异常时触发,但对 async 是无效的。

kotlin 复制代码
val handler = CoroutineExceptionHandler { _, exception ->
    println("捕获到异常:${exception.message} ✅")
}

fun main() = runBlocking {
    val job = launch(handler) {
        throw RuntimeException("我崩了 ❌")
    }
    job.join()
}

但下面这种 async 是不会被 handler 处理的:

kotlin 复制代码
val handler = CoroutineExceptionHandler { _, exception ->
    println("Handler 触发了:${exception.message}")
}

fun main() {
    runBlocking {
        val scope = CoroutineScope(handler)
        scope.launch {
            throw RuntimeException("协程 A 崩了 ❌")
        }
        val deferred = scope.async {
            throw RuntimeException("async 崩了 ❌")
        }
        scope.launch {
            delay(1000)
            println("协程 B 应该活着 ❌,但没机会执行")
        }
        deferred.await()
        // 必须用 try-catch,否则照样崩
//    try {
//        deferred.await()
//    } catch (e: Exception) {
//        println("自己捕获 async 异常 ✅")
//    }
        Unit
    }
}

5. viewModelScope 和 lifecycleScope

  • viewModelScope 内部使用了 SupervisorJob,所以其中的子协程是互不影响的,崩一个不会带崩其他。
kotlin 复制代码
return setTagIfAbsent(
            JOB_KEY,
            CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
        )
  • lifecycleScope ,也是 supervisor。
kotlin 复制代码
val newScope = LifecycleCoroutineScopeImpl(
    this,
    SupervisorJob() + Dispatchers.Main.immediate
)

总结一下

  • 一个线程崩了,默认不会影响其他线程,但是Android做了特殊处理,会将应用杀掉
  • 一个协程崩了,默认会 cancel同scope里的全部协程(不像线程那么"独立");
  • 用 supervisorScope(或 SupervisorJob)可以避免"崩一个全挂";
  • CoroutineExceptionHandler 可以兜住 launch 异常,但兜不了 async,async 要自己 try-catch。
  • Android 中 viewModelScope 和 lifecycleScope 都用了 SupervisorJob。

相关推荐
撩得Android一次心动4 小时前
Jetpack Compose 知识点整理2【个人用】
android·笔记·学习·kotlin·compose
是真的小外套5 小时前
2024年软考中级信息安全工程师|选择题考点+案例分析真题解析(含答案)
android·网络
用户2018792831678 小时前
一文讲透 Android Native Heap 监控原理:一间"只进不出"的仓库,和总部派来的侦探
android
YB13758 小时前
Jetpack Compose 动画animate*AsState
android
高晶9 小时前
Android 通讯录应用开发实战:从零搭建 SQLite 数据持久化完整项目
android·设计模式·前端框架
隐擎fox9 小时前
深入 Android 移动端风控与协议层对抗:内核级虚拟环境检测、网络堆栈特征伪装与住宅 IP 协同实战
android·网络·python·网络协议·tcp/ip
换元不配限11 小时前
从 AsyncTask 到现代并发:Android 异步方案的演进与替代实践
android·asynctask·异步编程·方案对比·asynctask替代方案
用户20187928316711 小时前
你的 App 为什么是「电量刺客」?——从一条 WakeLock 追到 Linux 内核的 Android 省电原理全解
android
mmsx11 小时前
Android 安全校验下沉到原生层:防 patch 与构建期自动化
android·安全·自动化