使用CoroutineScope(SupervisorJob())多次抛异常后协程不再启动

问题根源 #

你遇到的核心问题是每次调用everySecond()时都创建新的CoroutineScope(SupervisorJob())，这种做法会引发以下问题：

• 每个协程绑定到无父上下文的独立Scope，无法统一管理生命周期，可能触发隐式的协程调度限制或资源泄漏。
• 未指定明确的Dispatcher，协程会继承调用者的线程上下文（若在主线程执行，可能导致调度优先级冲突或阻塞问题）。
• 频繁创建的独立Scope累积到一定次数后，会触发协程内部的调度阈值，导致新协程无法被正常启动执行。

修复方案 #

1. 使用全局CoroutineScope统一管理协程 #

在Service中创建全局Scope，绑定Service生命周期，避免每次创建新Scope：

class YourService : Service() {
    // 全局Scope，绑定Service生命周期，指定IO线程处理网络操作
    private val serviceScope = CoroutineScope(SupervisorJob() + Dispatchers.IO)

    fun everySecond() {
        serviceScope.launch {
            Log.v("John", "Doe")
            try {
                aFunctionThatMayThrowToSignalNetworkErrors()
            } catch (e: Exception) {
                Log.e("John", "Doe ERROR", e) // 打印异常堆栈，方便排查问题
            }
        }
    }

    override fun onDestroy() {
        super.onDestroy()
        // Service销毁时取消所有协程，避免内存泄漏
        serviceScope.cancel()
    }
}

2. 明确指定Dispatcher #

网络操作应放在Dispatchers.IO线程，避免阻塞主线程或占用默认Dispatcher的线程资源。无论aFunctionThatMayThrowToSignalNetworkErrors是挂起函数还是阻塞操作，IO线程池都能更高效地处理这类任务。

3. 扩展异常捕获范围（可选） #

如果怀疑5次后抛出的是Error而非Exception，可扩展捕获范围确保所有异常都被处理：

catch (e: Throwable) {
    Log.e("John", "Doe ERROR", e)
}

关键说明 #

• SupervisorJob确保单个协程的异常不会影响其他协程的执行，符合你用异常做逻辑退避的需求。
• 在onDestroy()中取消Scope是必要操作，防止Service销毁后协程继续运行导致内存泄漏。
• 打印异常堆栈能帮你确认5次后抛出的异常类型，排查是否存在未预期的错误。

内容的提问来源于stack exchange，提问作者PsyTrxOps