协程生命周期的最后一步---协程取消

任何对象都有生命周期，协程也不例外，其生命周期很简单启动->运行->结束。而每个生命周期的状态转换都是需要触发条件的，比如启动->运行，需要协程构建器launch{}，运行期间需要续体，线程池等，最后结束的直接触发条件就是本文要探讨的内容

线程的取消

因为协程的取消和线程的取消在原理上是非常相近的，而线程又是读者比较容易接受的知识，所以在探讨协程的取消前，先来看线程是如何取消的。

如何取消线程

stop和suspend：在底层上存在严重的缺陷，应该避免使用此类方式停止线程
中断interrupted方法：这是一种协作机制，简言之就是线程A设置一个线程B的中断的flag，B在耗时循环体内检查该flag，true则放弃该循环，则线程B会自行停止。提供如下实例代码，简单说明其协作原理：

public class MyThread extends Thread {
    @Override
    public void run() {
        super.run();
        try {
            for (int i = 0; i < 500000; i++) {
                // check中断标志位
                if (this.isInterrupted()) {
                    System.out.println("stop");
                    // 异常法，使线程自行停止
                    throw new InterruptedException();
                }
            }
        } catch (InterruptedException e) {
            System.out.println("run catch");
            // to do someThing
        }
    }

    public static void main(String[] args) {
        try {
            Thread.sleep(2000);
            MyThread thread = new MyThread();
            thread.start();
            // 停止线程，设置中断标志位
            thread.interrupt();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

附：这样我们就知道官方协程指南中提到"取消是协作的”是什么意思了，其实原理和这个类似。

协程的取消

和线程的取消一样，协程的取消也是协作机制，类似线程的interrupt()函数，协程可以调用cancel()函数取消，或者cancelAndJoin()。类似isInterrupted(), 协程可以check isActive的值去判断协程是否取消。

`cancel`与`cancelAndJoin()`

cancel直接取消协程，即在耗时循环体内抛CancellationException异常，不会等待耗时循环体后面的代码执行完成, 如下例子可表明

 suspend fun test2() {
    coroutineScope {
        val job = launch(Dispatchers.Default) {
            log("1")
            val file = File("E:\\Opera_64.0.3417.54_Setup_x64.exe")
            val bufferedReader = BufferedReader(FileReader(file))
            // 耗时循环体：大多数IO耗时操作都会有一个循环的
            while (isActive) {
                bufferedReader.readLine() ?: break
            }
            log("2")
        }
        delay(100L) // 等待一段时间
        job.cancel()
        log("3")
    }
}
// output
Thread[DefaultDispatcher-worker-1,5,main]1
Thread[main,5,main]3
Thread[DefaultDispatcher-worker-1,5,main]2
Thread[main,5,main]end

cancelAndJoin()是会等待耗时循环体后面的代码执行完成的，这个一般不会花太多时间，因为最耗时的操作已经通过判断isActive跳过了。一般会使用这个函数去处理。如下代码的输出顺序可证明该结论：

suspend fun test2() {
    coroutineScope {
        val job = launch(Dispatchers.Default) {
            log("1")
            val file = File("E:\\Opera_64.0.3417.54_Setup_x64.exe")
            val bufferedReader = BufferedReader(FileReader(file))
            while (isActive) {
                bufferedReader.readLine() ?: break
            }
            log("2")
        }
        delay(100L) // 等待一段时间
        job.cancelAndJoin()
        log("3")
    }
}
// output
Thread[DefaultDispatcher-worker-1,5,main]1
Thread[DefaultDispatcher-worker-1,5,main]2
Thread[main,5,main]3
Thread[main,5,main]end

可能到这里有人会说了，那cancel和cancelJoin这两个api有什么用呢？协作式的停止协程需要自己去写判断条件呀？我的回答是yes，你需要自己写，不过幸运的是，耗时操作一般是网络+文件读取，其实说白了就是IO，这两种场景都有现成的框架，比如网络有Retrofit等，这些经典的框架对cancel这样的操作是做了适配的。即使没有做适配，你也可以自己简单的写一个带取消协程。步骤如下：

首先你需要理解suspendCancellableCoroutine：类似上篇讲的suspendCoroutineUninterceptedOrReturn其回调也会返回一个续体

suspend fun test4() = suspendCancellableCoroutine<String> { cont ->
    // 定义一个取消回调事件
    cont.invokeOnCancellation {
        // 在这里可以做一些耗时操作的cancel处理
    }
}

以OkHttp为例，就可以在invokeOnCancellation回调中调用call.cancel去真正的取消该请求。

suspend fun test4() = suspendCancellableCoroutine<String> { cont ->
    val call = OkHttpClient().newCall(...)
    // 定义一个取消回调事件
    cont.invokeOnCancellation {
        // 取消请求
        call.cancel()
    }
}

这就完成了，我们在主函数的调用代码如下

val job = launch { //①
    log(1)
    val res = test4()
    log(res)
    log(2)
}
delay(10)
log(3)
job1.cancel()
log(4)

(附：Retrofit从2.6.0版，已经对其做了适配, 也是类似上面的原理。后面的协程实践篇我会详细介绍)

上面可能表述有点乱，所以现在总结一下cancel和cancelJoin()到底做了什么

小结

取消协程主要有两个方法cancel()和cancelJoin(),前者立即停止协程执行并执行后面代码，后者需要等待协程执行完成后在执行后面的代码。其中cancel主要做了两件事

状态转移：即设置状态flag： isActive = false
处理回调：通知各个观察者（订阅者）
而join主要就是干了一件事，即等待设置了isActive=false的协程执行完成。

思考与总结

很多对象的生命周期结束的问题会使程序设计和实现等过程变得复杂，比如在应用层你可能需要在结束时释放资源，在框架层你需要考虑内部的状态迁移和资源释放的问题。但是该步骤又是非常重要的，比如在android开发中就可能因为此造成内存泄漏等现象。所以在应用层设计的时候一定要考虑取消的情况，本文开篇通过引入线程的取消机制（协作机制）为后文描述协程的取消做铺垫，因为两者非常类似，

线程的interrupt()等同于协程中的cancel()方法
线程中判断是否中断的方法isInterrupted()等同于协程中的isActive

但是由于协作机制的复杂性（需要协作）导致在很多情况下需要自己在协程A中取消，在协程B中需要手动判断协程是否取消来跳过循环耗时函数。这就需要某些异步框架中对该机制做适配，比如Retrofit对RxJava做了适配，当然retrofit也对协程做了适配。对于没有做适配的框架，本文也给出了一个的简单demo自己去做适配。

最后略显遗憾的是，没有对cancel进行源码级的分析，后面有机会补上。