Kotlin 协程的取消机制超详细解读

在 Java 语言中供给了线程中止的才干，但并不是一切的线程都能够中止的，由于 interrupt 办法并不是实在的停止线程，而是将一个标志位标记为中止状况，当运转到下一次中止标志位查看时，才干触发停止线程。

但无论怎么，停止线程是一个糟糕的计划，由于在线程的销毁和重建，是要消耗系统资源的，造成了不必要的开支。Kotlin 协程供给了更优雅的撤销机制，这也是协程比较中心的功用之一。

协程的状况

在了解撤销机制之前咱们需求知道一些关于 Job 状况的内容：

State	isActive(是否活泼)	isCompleted（是否完结）	isCancelled（是否撤销）
New (可选初始状况)	false	false	false
Active (默许初始状况)	true	false	false
Completing (短暂态)	true	false	false
Cancelling (短暂态)	false	false	true
Cancelled (完结态)	false	true	true
Completed (完结态)	false	true	false

能够看出，在完结和撤销的过程中，会经过一个短暂的进行中的状况，然后才变成已完结/已撤销。

在这儿只关注一下撤销相关的状况：

• Cancelling

  抛出反常的 Job 会导致其进入 Cancelling 状况，也能够运用 cancel 办法来随时撤销 Job 使其立即转换为 Cancelling 状况。

• Cancelled

  当它递归撤销子项，并等待一切的子项都撤销后，该 Job 会进入 Cancelled 状况。

撤销协程的用法

协程在代码中笼统的类型是 Job ， 下面是一个官方的代码示例，用来展示怎么撤销协程的履行：

suspendfunmain():Unit=coroutineScope{
valjob=launch{
repeat(1000){i->
println("job:I'msleeping$i...")
delay(500L)
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancel()//cancelsthejob
job.join()//waitsforjob'scompletion
println("main:NowIcanquit.")
}

它的输出是：

job:I'msleeping0...
job:I'msleeping1...
job:I'msleeping2...
main:I'mtiredofwaiting!
main:NowIcanquit.

一旦 mian 办法中调用了 job.cancel() ，咱们就看不到其他协程的任何输出，由于它已被撤销了。

协程撤销的有效性

协程代码有必要经过与挂起函数的合作才干被撤销。kotlinx.coroutines 中一切挂起函数（带有 suspend 关键字函数）都是能够被撤销的。suspend 函数会查看协程是否需求撤销并在撤销时抛出 CancellationException 。

可是，假如协程在运转过程中没有挂起点，则不能撤销协程，如下例所示：

suspendfunmain():Unit=coroutineScope{
valstartTime=System.currentTimeMillis()
valjob=launch(Dispatchers.Default){
varnextPrintTime=startTime
vari=0
while(i<5){//computationloop,justwastesCPU
//printamessagetwiceasecond
if(System.currentTimeMillis()>=nextPrintTime){
println("job:I'msleeping${i++}...")
nextPrintTime+=500L
}
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")
}

在这个 job 中，并没有履行任何 suspend 函数，所以在履行过程中并没有对协程是否需求撤销进行查看，自然也就无法触发撤销。

同样的问题也能够在经过 捕获 CancellationException 而且不抛出的状况下 观察到：

suspendfunmain():Unit=coroutineScope{
valjob=launch(Dispatchers.Default){
repeat(5){i->
try{
//printamessagetwiceasecond
println("job:I'msleeping$i...")
delay(500)
}catch(e:Exception){
//logtheexception
println(e)
}
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")
}

打印成果是：

job:I'msleeping0...
job:I'msleeping1...
job:I'msleeping2...
main:I'mtiredofwaiting!
kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@614acfe9
job:I'msleeping3...
kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@614acfe9
job:I'msleeping4...
kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@614acfe9
main:NowIcanquit.

从打印成果来看，循环 5 次悉数履行了，如同撤销并没有起到效果。但实践上不是这样的，为了便于观察加上时刻戳：

1665217217682:job:I'msleeping0...
1665217218196:job:I'msleeping1...
1665217218697:job:I'msleeping2...
1665217218996:main:I'mtiredofwaiting!
1665217219000:kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@3a1efc0d
1665217219000:job:I'msleeping3...
1665217219000:kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@3a1efc0d
1665217219000:job:I'msleeping4...
1665217219000:kotlinx.coroutines.JobCancellationException:StandaloneCoroutinewascancelled;job=StandaloneCoroutine{Cancelling}@3a1efc0d
1665217219001:main:NowIcanquit.

加上时刻能够看出，抛出第一次反常后的两次循环和反常捕获都是在同一瞬间完结的。这阐明了捕获到反常后，仍然会履行代码，可是一切的 delay 办法都没有收效，即该 Job 的一切子 Job 都失效了。但该 Job 仍在继续循环打印。原因是，父 Job 会等一切子 Job 处理完毕后才干完结撤销。

而假如咱们不运用 try-catch 呢？

suspendfunmain():Unit=coroutineScope{
valjob=launch(Dispatchers.Default){
repeat(5){i->
//printamessagetwiceasecond
println("job:I'msleeping$i...")
delay(500)
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")
}

打印成果：

job:I'msleeping0...
job:I'msleeping1...
job:I'msleeping2...
main:I'mtiredofwaiting!
main:NowIcanquit.

很顺利的撤销了，这是由于协程抛出 Exception 直接停止了。

“

留意协程抛出 CancellationException 并不会导致 App Crash 。

运用 try-catch 来捕获 CancellationException 时需求留意，在挂起函数前的代码逻辑仍会屡次履行，然后导致这部分代码似乎没有被撤销相同。

怎么写出能够撤销的代码

有两种办法能够使代码是可撤销的。第一种办法是定期调用挂起函数，查看是否撤销，便是上面的比如中的办法；另一个是显式查看撤销状况：

suspendfunmain():Unit=coroutineScope{
valstartTime=System.currentTimeMillis()
valjob=launch(Dispatchers.Default){
varnextPrintTime=startTime
vari=0
while(isActive){//cancellablecomputationloop
//printamessagetwiceasecond
if(System.currentTimeMillis()>=nextPrintTime){
println("job:I'msleeping${i++}...")
nextPrintTime+=500L
}
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")
}

将上面的循环 5 次经过运用 while (isActive) 进行替换，完结显现查看撤销的代码。isActive 是经过 CoroutineScope 目标在协程内部可用的扩展特点。

在 finally 中开释资源

在前面的比如中咱们运用 try-catch 捕获 CancellationException 发现会产生父协程等待一切子协程完结后才干完结，所以主张不用 try-catch 而是 try{…} finally{…} ，让父协程在被撤销时正常履行终结操作:

valjob=launch{
try{
repeat(1000){i->
println("job:I'msleeping$i...")
delay(500L)
}
}finally{
println("job:I'mrunningfinally")
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")

join 和 cancelAndJoin 都要等待一切终结操作完结，所以上面的比如产生了以下输出:

job:I'msleeping0...
job:I'msleeping1...
job:I'msleeping2...
main:I'mtiredofwaiting!
job:I'mrunningfinally
main:NowIcanquit.

运用不行撤销的 block

假如在在上面的示例的 finally 代码块中运用 suspend 函数，会导致抛出 CancellationException 。

由于运转这些代码的协程已经被撤销了。一般状况下这不会有任何问题，但是，在极少数状况下，假如你需求在 finally 中运用一个挂起函数，你能够经过运用 withContext(NonCancellable) { ... } ：

valjob=launch{
try{
repeat(1000){i->
println("job:I'msleeping$i...")
delay(500L)
}
}finally{
withContext(NonCancellable){
println("job:I'mrunningfinally")
delay(1000L)
println("job:AndI'vejustdelayedfor1secbecauseI'mnon-cancellable")
}
}
}
delay(1300L)//delayabit
println("main:I'mtiredofwaiting!")
job.cancelAndJoin()//cancelsthejobandwaitsforitscompletion
println("main:NowIcanquit.")

CancellationException

在上面的内容中，咱们知道协程的撤销是经过抛出 CancellationException 来进行的，奇特的是抛出 Exception 并没有导致运用程序 Crash 。

CancellationException 的实在完结是 j.u.c. 中的 CancellationException ：

publicactualtypealiasCancellationException=java.util.concurrent.CancellationException

“

假如协程的 Job 被撤销，则由可撤销的挂起函数抛出 CancellationException 。它表明协程的正常撤销。在默许的 CoroutineExceptionHandler 下，它不会打印到控制台/日志。

上面引证了这个类的注释，看来处理抛出反常的逻辑在 CoroutineExceptionHandler 中：

publicinterfaceCoroutineExceptionHandler:CoroutineContext.Element{
/**
*Keyfor[CoroutineExceptionHandler]instanceinthecoroutinecontext.
*/
publiccompanionobjectKey:CoroutineContext.Key<CoroutineExceptionHandler>
/**
*Handlesuncaught[exception]inthegiven[context].Itisinvoked
*ifcoroutinehasanuncaughtexception.
*/
publicfunhandleException(context:CoroutineContext,exception:Throwable)
}

一般，未捕获的 Exception 只能由运用协程构建器的根协程产生。一切子协程都将反常的处理托付给他们的父协程，父协程也托付给它自身的父协程，直到托付给根协程处理。所以在子协程中的 CoroutineExceptionHandler 永久不会被运用。

运用 SupervisorJob 运转的协程不会将反常传递给它们的父协程，SupervisorJob 被视为根协程。

运用 async 创立的协程总是捕获它的一切反常经过成果 Deferred 目标回调出去，因而它不能导致未捕获的反常。

CoroutineExceptionHandler 用于记载反常、显现某种类型的过错消息、停止和/或重新启动运用程序。

假如需求在代码的特定部分处理反常，主张在协程中的相应代码周围运用 try-catch。经过这种办法，您能够阻挠反常协程的完结(反常现在被捕获)，重试操作，和/或采取其他恣意操作。 这也便是咱们前面论证的在协程中运用 try-catch 导致的撤销失效。

默许状况下，假如协程没有配置用于处理反常的 Handler ，未捕获的反常将按以下办法处理:

• 假如 exception 是 CancellationException ，那么它将被忽略(由于这是撤销正在运转的协程的假定机制)。

• 其他状况：

  • 假如上下文中有一个 Job，那么调用 job.cancel() 。
  • 否则，经过 ServiceLoader 找到的 CoroutineExceptionHandler 的一切实例并调用当前线程的 Thread.uncaughtExceptionHandler 来处理反常。

超时撤销

撤销协程履行的最合适的运用场景是它的履行时刻超过了规则的最大时刻时主动撤销任务。在 Kotlin 协程库中供给了 withTimeout 办法来完结这个功用：

withTimeout(1300L){
repeat(1000){i->
println("I'msleeping$i...")
delay(500L)
}
}

履行成果：

I'msleeping0...
I'msleeping1...
I'msleeping2...
Exceptioninthread"main"kotlinx.coroutines.TimeoutCancellationException:Timedoutwaitingfor1300ms

TimeoutCancellationException 是 CancellationException 的子类，TimeoutCancellationException 经过 withTimeout 函数抛出。

在本例中，咱们在main函数中运用了withTimeout ，运转过程中会导致 Crash 。

有两种处理办法，便是运用 try{…} catch (e: TimeoutCancellationException){…} 代码块；另一种办法是运用在超时的状况下不是抛出反常而是回来 null 的 withTimeoutOrNull 函数：

valresult=withTimeoutOrNull(1300L){
repeat(1000){i->
println("I'msleeping$i...")
delay(500L)
}
"Done"//willgetcancelledbeforeitproducesthisresult
}
println("Resultis$result")

打印成果：

I'msleeping0...
I'msleeping1...
I'msleeping2...
Resultisnull

异步的超时和资源

withTimeout 中的超时事情相对于在其块中运转的代码是异步的，而且或许在任何时刻产生，甚至在从超时块内部回来之前。假如你在块内部翻开或获取一些资源，需求封闭或开释到块外部。

例如，在这儿，咱们用 Resource 类模仿一个可封闭资源，它只是经过对取得的计数器递增，并对该计数器从其封闭函数递减来盯梢创立次数。让咱们用小超时运转很多的协程，尝试在一段延迟后从withTimeout块内部获取这个资源，并从外部开释它。

varacquired=0
classResource{
init{acquired++}//Acquiretheresource
funclose(){acquired--}//Releasetheresource
}
funmain(){
runBlocking{
repeat(100_000){//Launch100Kcoroutines
launch{
valresource=withTimeout(60){//Timeoutof60ms
delay(50)//Delayfor50ms
Resource()//AcquirearesourceandreturnitfromwithTimeoutblock
}
resource.close()//Releasetheresource
}
}
}
//OutsideofrunBlockingallcoroutineshavecompleted
println(acquired)//Printthenumberofresourcesstillacquired
}

假如运转上面的代码，您将看到它并不总是打印 0，尽管它或许取决于您的机器的时刻，在本例中您或许需求调整超时以实践看到非零值。

要处理这个问题，能够在变量中存储对资源的引证，而不是从withTimeout块回来它。

funmain(){
runBlocking{
repeat(100_000){//Launch100Kcoroutines
launch{
varresource:Resource?=null//Notacquiredyet
try{
withTimeout(60){//Timeoutof60ms
delay(50)//Delayfor50ms
resource=Resource()//Storearesourcetothevariableifacquired
}
//Wecandosomethingelsewiththeresourcehere
}finally{
resource?.close()//Releasetheresourceifitwasacquired
}
}
}
}
//OutsideofrunBlockingallcoroutineshavecompleted
println(acquired)//Printthenumberofresourcesstillacquired
}

这样这个比如总是输出0。资源不会泄漏。

撤销查看的底层原理

在探究协程撤销的有效性时，咱们知道协程代码有必要经过与挂起函数的合作才干被撤销。

“

kotlinx.coroutines 中一切挂起函数（带有 suspend 关键字函数）都是能够被撤销的。suspend 函数会查看协程是否需求撤销并在撤销时抛出 CancellationException 。

关于协程的撤销机制，很明显和 suspend 关键字有关。为了测验 suspend 关键字的效果，完结下面的代码：

classSolution{
suspendfunfunc():String{
return"测验suspend关键字"
}
}

作为对照组，另一个是不加 suspend 关键字的 func 办法：

classSolution{
funfunc():String{
return"测验suspend关键字"
}
}

两者反编译成 Java ：

//一般的办法
publicfinalclassSolution{
publicstaticfinalint$stable=LiveLiterals$SolutionKt.INSTANCE.Int$class-Solution();
@NotNull
publicfinalStringfunc(){
returnLiveLiterals$SolutionKt.INSTANCE.String$fun-func$class-Solution();
}
}
//带有suspend关键字的办法
publicfinalclassSolution{
publicstaticfinalint$stable=LiveLiterals$SolutionKt.INSTANCE.Int$class-Solution();
@Nullable
publicfinalObjectfunc(@NotNullContinuation<?superString>$completion){
returnLiveLiterals$SolutionKt.INSTANCE.String$fun-func$class-Solution();
}
}

suspend 关键字润饰的办法反编译后默许生成了带有 Continuation 参数的办法。阐明 suspend 关键字的玄机在 Continuation 类中。

Continuation 是 Kotlin 协程的中心思维 Continuation-Passing Style 的完结。原理参阅简述协程的底层完结原理 。

经过在一般函数的参数中添加一个 Continuation 参数，这个 continuation 的性质类似于一个 lambda 目标，将办法的回来值类型传递到这个 lambda 代码块中。

什么意思呢？便是本来这个办法的回来类型直接 return 出来的：

vala:String=func()
print(a)

而经过 suspend 润饰，代码变成了这个样子：

func{a->
print(a)
}

Kotlin 协程便是经过这样的包装，将比如 launch 办法，实践上是 launch 最终一个参数接纳的是 lambda 参数。也便是把外部逻辑传递给函数内部履行。

回过头来再来了解 suspend 关键字，咱们知道带有 suspend 关键字的办法会对协程的撤销进行查看，然后撤销协程的履行。从这个才干上来看，我了解他应该会主动生成类似下面的逻辑代码：

生成的函数{
if(!当前协程.isActive){
throwCancellationException()
}
//...这儿是函数实在逻辑
}

suspend 润饰的函数，会主动生成一个挂起点，来查看协程是否应该被挂起。

显然 Continuation 中声明的函数也证明了挂起的功用：

publicinterfaceContinuation<inT>{
/**
*Thecontextofthecoroutinethatcorrespondstothiscontinuation.
*/
publicvalcontext:CoroutineContext
/**
*康复相应协程的履行，将成功或失利的成果作为最终一个挂起点的回来值传递。
*/
publicfunresumeWith(result:Result<T>)
}

协程实质上是产生了一个 switch 句子，每个挂起点之间的逻辑都是一个 case 分支的逻辑。参阅 协程是怎么完结的 中的比如：

Function1lambda=(Function1)(newFunction1((Continuation)null){
intlabel;
@Nullable
publicfinalObjectinvokeSuspend(@NotNullObject$result){
bytetext;
@BlockTag1:{
Objectresult;
@BlockTag2:{
result=IntrinsicsKt.getCOROUTINE_SUSPENDED();
switch(this.label){
case0:
ResultKt.throwOnFailure($result);
this.label=1;
if(SuspendTestKt.dummy(this)==result){
returnresult;
}
break;
case1:
ResultKt.throwOnFailure($result);
break;
case2:
ResultKt.throwOnFailure($result);
break@BlockTag2;
case3:
ResultKt.throwOnFailure($result);
break@BlockTag1;
default:
thrownewIllegalStateException("callto'resume'before'invoke'withcoroutine");
}
text=1;
System.out.println(text);
this.label=2;
if(SuspendTestKt.dummy(this)==result){
returnresult;
}
}
text=2;
System.out.println(text);
this.label=3;
if(SuspendTestKt.dummy(this)==result){
returnresult;
}
}
text=3;
System.out.println(text);
returnUnit.INSTANCE;
}
@NotNull
publicfinalContinuationcreate(@NotNullContinuationcompletion){
Intrinsics.checkNotNullParameter(completion,"completion");
Function1funcation=new<anonymousconstructor>(completion);
returnfuncation;
}
publicfinalObjectinvoke(Objectobject){
return((<undefinedtype>)this.create((Continuation)object)).invokeSuspend(Unit.INSTANCE);
}
});

能够看出，在每个分支都会履行一次 ResultKt.throwOnFailure($result); ，从姓名上就知道，这便是查看是否需求撤销并抛出反常的代码所在：

@PublishedApi
@SinceKotlin("1.3")
internalfunResult<*>.throwOnFailure(){
if(valueisResult.Failure)throwvalue.exception
}

这儿的 Result 类是一个包装类，它将成功的成果封装为类型 T 的值，或将失利的成果封装为带有恣意Throwable反常的值。

@Suppress("INAPPLICABLE_JVM_NAME")
@InlineOnly
@JvmName("success")
publicinlinefun<T>success(value:T):Result<T>=
Result(value)
/**
*Returnsaninstancethatencapsulatesthegiven[Throwable][exception]asfailure.
*/
@Suppress("INAPPLICABLE_JVM_NAME")
@InlineOnly
@JvmName("failure")
publicinlinefun<T>failure(exception:Throwable):Result<T>=
Result(createFailure(exception))

成功和失利的办法类型是不相同的，证明了这一点，success 办法接纳类型为 T 的参数；failure 接纳 Throwable 类型的参数。

到这儿 suspend 办法挂起的原理就明了了：在协程的状况机中，经过挂起点会分割出不同的状况，对每一个状况，会先进行挂起成果的查看。 这会导致以下成果：

• 协程的撤销机制是经过挂起函数的挂起点查看来进行撤销查看的。证明了为什么假如没有 suspend 函数（实质是挂起点），协程的撤销就不会收效。
• 协程的撤销机制是需求函数合作的，便是经过 suspend 函数来添加撤销查看的机遇。
• 父协程会履行完一切的子协程（挂起函数），由于代码的实质是一个循环履行 switch 句子，当一个子协程（或挂起函数）履行完毕，会继续履行到下一个分支。可是最终一个挂起点后续的代码并不会被履行，由于最终一个挂起点查看到失利，不会继续跳到最终的 label 分支。