阿里P7大佬教你破解 Kotlin 协程(5) - 协程取消篇

关注

原创最新推荐文章于 2026-08-24 10:53:38 发布 535 阅读 AI 写同款· GEO 优化 ›

[译] 2019 年的 Android 网络 —— Retrofit 与 Kotlin 协程 //Kotlin Coroutines implementation “org.jetbrains.kotlinx:kotlinx-coroutines-android:kotlinCoroutineVersion"implementation"org.jetbrains.kotlinx:kotlinx−coroutines−core:kotlinCoroutineVersion" implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:k 阅读详情

破解 Kotlin 协程(5) - 协程取消篇

在这里插入图片描述

关键词：Kotlin 协程协程取消任务停止

协程的任务的取消需要靠协程内部调用的协作支持，这就类似于我们线程中断以及对中断状态的响应一样。

1. 线程的中断

我们先从大家熟悉的话题讲起。线程有一个被废弃的 stop 方法，这个方法会让线程立即死掉，并且释放它持有的锁，这样会让它正在读写的存储处于一个不安全的状态，因此 stop 被废弃了。如果我们启动了一个线程并让它执行一些任务，但很快我们就后悔了， stop 还不让用，那该怎么办？

val thread = thread {
    ...
}
thread.stop() // !!! Deprecated!!!

我们应该想办法让线程内部正在运行的任务跟我们合作把任务停掉，这样线程内部的任务停止之前还有机会清理一些资源，比如关闭流等等。

val thread = thread {
    try {
        Thread.sleep(10000)
    } catch (e: InterruptedException) {
        log("Interrupted, do cleaning stuff.")
    }
}
thread.interrupt()

像 sleep 这样的方法调用，文档明确指出它支持 InterruptedException，因此当线程被标记为中断状态时，它就会抛出 InterruptedException ，那么我们自然就可以捕获异常并做资源清理了。

所以请注意所谓的协作式的任务终止，协程的取消也就是 cancel 机制的思路也是如此。

2. 协程类似的例子

我们来看一个协程取消的例子：

fun main() = runBlocking {
    val job1 = launch { // ①
        log(1)
        delay(1000) // ②
        log(2)
    }
    delay(100)
    log(3)
    job1.cancel() // ③
    log(4)
}

这次我们用了一个不一样的写法，我们没有用 suspend main，而是直接用 runBlocking 启动协程，这个方法在 Native 上也存在，都是基于当前线程启动一个类似于 Android 的 Looper 的死循环，或者叫消息队列，可以不断的发送消息给它进行处理。 runBlocking 会启动一个 Job，因此这里也存在默认的作用域，不过这对于我们今天的讨论暂时没有太大影响。

这段代码 ① 处启动了一个子协程，它内部先输出 1，接着开始 delay， delay 与线程的 sleep 不同，它不会阻塞线程，你可以认为它实际上就是触发了一个延时任务，告诉协程调度系统 1000ms 之后再来执行后面的这段代码（也就是 log(2)）；而在这期间，我们在 ③ 处对刚才启动的协程触发了取消，因此在 ② 处的 delay还没有回调的时候协程就被取消了，因为 delay 可以响应取消，因此 delay 后面的代码就不会再次调度了，不调度的原因也很简单，② 处的 delay 会抛一个 CancellationException：

...
log(1)
try {
    delay(1000)
} catch (e: Exception) {
    log("cancelled. $e")
}
log(2)
...

那么输出的结果就不一样了：

06:54:56:361 [main] 1
06:54:56:408 [main] 3
06:54:56:411 [main] 4
06:54:56:413 [main] cancelled. kotlinx.coroutines.JobCancellationException: Job was cancelled; job=StandaloneCoroutine{Cancelling}@e73f9ac
06:54:56:413 [main] 2

大家看，这与线程的中断逻辑是不是非常的类似呢？

3. 完善我们之前的例子

之前我们有个例子，上一篇文章已经加入了异常处理逻辑，那么这次我们给它加上取消逻辑。之前是这样：

suspend fun getUserCoroutine() = suspendCoroutine<User> { continuation ->
    getUser(object : Callback<User> {
        override fun onSuccess(value: User) {
            continuation.resume(value)
        }

        override fun onError(t: Throwable) {
            continuation.resumeWithException(t)
        }
    })
}

加取消逻辑，那需要我们的 getUser 回调版本支持取消，我们看下我们的 getUser 是怎么实现的：

fun getUser(callback: Callback<User>) {
    val call = OkHttpClient().newCall(
            Request.Builder()
                    .get().url("https://api.github.com/users/bennyhuo")
                    .build())

    call.enqueue(object : okhttp3.Callback {
        override fun onFailure(call: Call, e: IOException) {
            callback.onError(e)
        }

        override fun onResponse(call: Call, response: Response) {
            response.body()?.let {
                try {
                    callback.onSuccess(User.from(it.string()))
                } catch (e: Exception) {
                    callback.onError(e) // 这里可能是解析异常
                }
            }?: callback.onError(NullPointerException("ResponseBody is null."))
        }
    })
}

我们发了个网络请求给 Github，让它把一个叫 bennyhuo 的用户信息返回来，我们知道 OkHttp 的这个 Call是支持 cancel 的，取消后，网络请求过程中如果读取到这个取消的状态，就会把请求给停止掉。既然这样，我们干脆直接改造 getUser 好了，这样还能省掉我们自己的 Callback 回调过程：

suspend fun getUserCoroutine() = suspendCancellableCoroutine<User> { continuation ->
    val call = OkHttpClient().newCall(...)

    continuation.invokeOnCancellation { // ①
        log("invokeOnCancellation: cancel the request.")
        call.cancel()
    }

    call.enqueue(object : okhttp3.Callback {
        override fun onFailure(call: Call, e: IOException) {
            log("onFailure: $e")
            continuation.resumeWithException(e)
        }

        override fun onResponse(call: Call, response: Response) {
            log("onResponse: ${response.code()}")
            response.body()?.let {
                try {
                    continuation.resume(User.from(it.string()))
                } catch (e: Exception) {
                    continuation.resumeWithException(e)
                }
            } ?: continuation.resumeWithException(NullPointerException("ResponseBody is null."))
        }
    })
}

我们这里用到了 suspendCancellableCoroutine，而不是之前的 suspendCoroutine，这就是为了让我们的挂起函数支持协程的取消。该方法将获取到的 Continuation 包装成了一个 CancellableContinuation，通过调用它的 invokeOnCancellation 方法可以设置一个取消事件的回调，一旦这个回调被调用，那么意味着 getUserCoroutine 调用所在的协程被取消了，这时候我们也要相应的做出取消的响应，也就是把 OkHttp 发出去的请求给取消掉。

那么我们在调用它的时候，如果遇到了取消，会怎么样呢？

val job1 = launch { //①
    log(1)
    val user = getUserCoroutine()
    log(user)
    log(2)
}
delay(10)
log(3)
job1.cancel()
log(4)

注意我们启动 ① 之后仅仅延迟了 10ms 就取消了它，网络请求的速度一般来讲还不会这么快，因此取消的时候大概率 getUserCoroutine 被挂起了，因此结果大概率是：

07:31:30:751 [main] 1
07:31:31:120 [main] 3
07:31:31:124 [main] invokeOnCancellation: cancel the request.
07:31:31:129 [main] 4
07:31:31:131 [OkHttp https://api.github.com/...] onFailure: java.io.IOException: Canceled

我们发现，取消的回调被调用了，OkHttp 在收到我们的取消指令之后，也确实停止了网络请求，并且回调给我们一个 IO 异常，这时候我们的协程已经被取消，在处于取消状态的协程上调用 Continuation.resume 、 Continuation.resumeWithException 或者 Continuation.resumeWith 都会被忽略，因此 OkHttp 回调中我们收到 IO 异常后调用的 continuation.resumeWithException(e) 不会有任何副作用。

4. 再谈 Retrofit 的协程扩展

4.1 Jake Wharton 的 Adapter 存在的问题

我在破解 Kotlin 协程 - 入门篇(https://www.bennyhuo.com/2019/04/01/basic-coroutines/) 提到了 Jake Wharton 大神为 Retrofit 写的协程 Adapter，

implementation 'com.jakewharton.retrofit:retrofit2-kotlin-coroutines-adapter:0.9.2'

它确实可以完成网络请求，不过有细心的小伙伴发现了它的问题：它怎么取消呢？我们把使用它的代码贴出来：

interface GitHubServiceApi {
    @GET("users/{login}")
    fun getUserCoroutine(@Path("login") login: String): Deferred<User>
}

定义好接口，创建 Retrofit 实例的时候传入对应的 Adapter：

val gitHubServiceApi by lazy {
    val retrofit = retrofit2.Retrofit.Builder()
            .baseUrl("https://api.github.com")
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(CoroutineCallAdapterFactory()) // 这里添加 Adapter
            .build()

    retrofit.create(GitHubServiceApi::class.java)
}

用的时候就这样：

val deferred = gitHubServiceApi.getUserCoroutine("bennyhuo")
try {
    showUser(deferred.await())
} catch (e: Exception) {
    showError(e)
}

如果要取消，我们可以直接调用 deferred.cancel()，例如：

log("1")
val deferred = gitHubServiceApi.getUserCoroutine("bennyhuo")
log("2")
withContext(Dispatchers.IO){
    deferred.cancel()
}
try {
    showUser(deferred.await())
} catch (e: Exception) {
    showError(e)
}

运行结果如下：

12:59:54:185 [DefaultDispatcher-worker-1] 1
12:59:54:587 [DefaultDispatcher-worker-1] 2
kotlinx.coroutines.JobCancellationException: Job was cancelled; job=CompletableDeferredImpl{Cancelled}@36699211

这种情况下，其实网络请求确实是被取消的，这一点我们可以看下源码的处理：

...
override fun adapt(call: Call<T>): Deferred<T> {
      val deferred = CompletableDeferred<T>()

      deferred.invokeOnCompletion { // ①
        if (deferred.isCancelled) {
          call.cancel()
        }
      }

      call.enqueue(object : Callback<T> {
        ...
      }     
}
...

注意 ① 处， invokeOnCompletion 在协程进入完成状态时触发，包括异常和正常完成，那么在这时候如果发现它的状态是已经取消的，那么结果就直接调用 Call 的取消即可。

这看上去确实很正常啊~ 不过 @阿永在公众号的评论里面提到了一个 Case，仔细一看还真是有问题。我们给出示例来复现这个 Case：

val job = GlobalScope.launch {
    log("1")
    val deferred = gitHubServiceApi.getUserCoroutine("bennyhuo")
    log("2")
    deferred.invokeOnCompletion {
        log("invokeOnCompletion, $it, ${deferred.isCancelled}")
    }
    try {
        showUser(deferred.await())
    } catch (e: Exception) {
        showError(e)
    }
    log(3)
}
delay(10)
job.cancelAndJoin()

我们启动一个协程，在其中执行网络请求，那么正常来说，这时候 getUserCoroutine 返回的 Deferred 可以当做一个子协程，它应当遵循默认的作用域规则，在父作用域取消时被取消掉，但现实却并不是这样：

13:06:54:332 [DefaultDispatcher-worker-1] 1
13:06:54:829 [DefaultDispatcher-worker-1] 2
kotlinx.coroutines.JobCancellationException: Job was cancelled; job=StandaloneCoroutine{Cancelling}@19aea38c
13:06:54:846 [DefaultDispatcher-worker-1] 3
13:06:56:937 [OkHttp https://api.github.com/...] invokeOnCompletion, null, false

我们看到在调用 deferred.await() 的时候抛了个取消异常，这主要是因为 await() 所在的协程已经被我们用 cancelAndJoin() 取消，但从随后 invokeOnCompletion 的回调结果来看， getUserCoroutine 返回的 Deferred 并没有被取消，再仔细一看，时间上这个回调比前面的操作晚了 2s，那必然是网络请求返回之后才回调的。

所以问题究竟在哪里？在 CoroutineCallAdapterFactory 的实现中，为了实现异步转换，手动创建了一个 CompletableDeferred：

override fun adapt(call: Call<T>): Deferred<T> {
  val deferred = CompletableDeferred<T>() // ①
  ...
}

这个 CompletableDeferred 本身就是一个 Job 的实现，它的构造可接受一个 Job 实例作为它的父协程，那么问题来了，这里并没有告诉它父协程究竟是谁，因此也就谈不上作用域的事儿了，这好像我们用 GlobalScope.launch 启动了一个协程一样。如果大家在 Android 当中使用 MainScope，那么同样因为前面说到的这个原因，导致 CompletableDeferred 没有办法被取消。

@阿永在公众号评论中提到这个问题，并提到了一个比较好的解决方案，下面我们为大家详细介绍。感谢 @阿永。

说到这里我们再简单回顾下，作用域主要有 GlobalScope、 coroutineScope、 supervisorScope，对于取消，除了 supervisorScope 比较特别是单向取消，即父协程取消后子协程都取消，Android 中 MainScope就是一个调度到 UI 线程的 supervisorScope； coroutineScope 的逻辑则是父子相互取消的逻辑；而 GlobalScope 会启动一个全新的作用域，与它外部隔离，内部遵循默认的协程作用域规则。

那么有没有办法解决这个问题呢？

直接解决还是比较困难的，因为 CompletableDeferred 构造所处的调用环境不是 suspend 函数，因而也没有办法拿到（很可能根本就没有！）父协程。

4.2 如何正确的将回调转换为协程

前面我们提到既然 adapt 方法不是 suspend 方法，那么我们是不是应该在其他位置创建协程呢？

其实我们前面在讲 getUserCoroutine 的时候就不断为大家展示了如何将一个回调转换为协程调用的方法：

suspend fun getUserCoroutine() = suspendCancellableCoroutine<User> { continuation ->
    ...
}

suspendCancellableCoroutine 跟最初我们提到的 suspendCoroutine 一样，都是要获取当前协程的 Continuation 实例，这实际上就相当于要继承当前协程的上下文，因此我们只需要在真正需要切换协程的时候再去做这个转换即可：

public suspend fun <T : Any> Call<T>.await(): T {
    return suspendCancellableCoroutine { continuation ->
        enqueue(object : Callback<T> {
            override fun onResponse(call: Call<T>?, response: Response<T?>) {
                continuation.resumeWith(runCatching { // ①
                    if (response.isSuccessful) {
                        response.body()
                            ?: throw NullPointerException("Response body is null: $response")
                    } else {
                        throw HttpException(response)
                    }
                })
            }

            override fun onFailure(call: Call<T>, t: Throwable) {
                if (continuation.isCancelled) return // ②
                continuation.resumeWithException(t)
            }
        })

        continuation.invokeOnCancellation {
            try {
                cancel()
            } catch (ex: Throwable) {  // ③
                //Ignore cancel exception 
            }
        }
    }
}

大家看着这段代码会不会很眼熟？这与我们 getUserCoroutine 的写法几乎如出一辙，不过有几处细节值得关注，我用数字标注了他们的位置：

① 处 runCatching 可以将一段代码的运行结果或者抛出的异常封装到一个 Result 类型当中，Kotlin 1.3 开始新增了Continuation.resumeWith(Result) 这个方法，这个点比起我们前面的写法更具 Kotlin 风格。
② 处在异常抛出时，判断了是否已经被取消。实际上如果网络请求被取消，这个回调确实会被调到，那么由于取消的操作是协程的由 Continuation 的取消发起的，因此这时候没必要再调用 continuation.resumeWithException(t) 来将异常再抛回来了。尽管我们前面其实也提到过，这时候继续调用 continuation.resumeWithException(t) 也没有任何逻辑上的副作用，但性能上多少还是会有一些开销。
③ 处，尽管 Call.cancel 的调用比较安全，但网络环境和状态难免情况复杂，因此对异常进行捕获会让这段代码更加健壮。如果 cancel 抛异常而没有捕获的话，那么等同于协程体内部抛出异常，具体如何传播看所在作用域的相关定义了。

需要指出的是，这段代码片段源自 gildor/kotlin-coroutines-retrofit(https://github.com/gildor/kotlin-coroutines-retrofit) ，大家也可以直接添加依赖进行使用：

compile 'ru.gildor.coroutines:kotlin-coroutines-retrofit:1.1.0'

这个框架代码量很少，但经过各路 Kotlin 协程专家的锤炼，逻辑手法很细腻，值得大家学习。

5. 小结
Kotlin 协程学习资料可以扫描下方二维码免费领取！

# 《**史上最详Android版kotlin协程入门进阶实战** **》**

第一章 Kotlin协程的基础介绍

● 协程是什么

● 什么是Job 、Deferred 、协程作用域

● Kotlin协程的基础用法

第二章 kotlin协程的关键知识点初步讲解

● 协程调度器

● 协程上下文

● 协程启动模式

● 协程作用域

● 挂起函数

第三章 kotlin协程的异常处理

● 协程异常的产生流程

● 协程的异常处理

第四章 kotlin协程在Android中的基础应用

● Android使用kotlin协程

● 在Activity与Framgent中使用协程

● ViewModel中使用协程

● 其他环境下使用协程

第五章 kotlin协程的网络请求封装

● 协程的常用环境

● 协程在网络请求下的封装及使用

● 高阶函数方式

● 多状态函数返回值方式

标签

#kotlin #android #开发语言

Kotlin 协程系列二：Coroutine取消和超时本系列为翻译和解读 Kotlin 协程的官方文档，对应官方文档版本1.5.3 时间是2021-10 约定：全部的正文均对应文档原文，个人解读以引用的形式插入官方文档链接 https://kotlinlang.org/docs/coroutines-guide.html 如果对协程完全没任何概念，强烈推荐先看这篇文章 https://xie.infoq.cn/article/351ddc94200d03948c41fbabd 如果你想写代码实操，可以参考这个配置环境 https://openxu.blog. 阅读详情