带着问题分析Kotlin协程原理

协程是一个较为复杂的东西，澄清协程的原理也不是简简单单的一篇文章就能讲的清，这个进程中需求做的便是运用、看源码、debug、总结、回顾。本节内容首要以澄清以下几个问题为主：

• 怎样创立一个协程
• 协程是怎样被创立出来的
• 发动战略是什么
• 发动战略完结了什么作业
• 协程是怎样被发动的
• 协程发动进程中的Dispatchers是什么
• 协程发动进程中的Dispatchers做了什么
• Worker是什么
• Worker中的使命被找到后是怎样履行的？
• 协程创立的时分CoroutineScope是什么
• 协程的结构化中父子联系是怎样树立的
• 结构化树立后又是怎样撤销的
• newCoroutineContext(context)做了什么

1.怎样创立一个协程

创立一个协程有三种办法

fun main() {
    CoroutineScope(Job()).launch(Dispatchers.Default) {
        delay(1000L)
        println("Kotlin")
    }
    println("Hello")
    Thread.sleep(2000L)
}
//履行成果：
//Hello
//Kotlin
fun main() = runBlocking {
    val deferred = CoroutineScope(Job()).async(Dispatchers.Default) {
        println("Hello")
        delay(1000L)
        println("Kotlin")
    }
    deferred.await()
}
//履行成果：
//Hello
//Kotlin
fun main() {
    runBlocking(Dispatchers.Default) {                
        println("launch started!")     
        delay(1000L)          
        println("Kotlin")         	   
    }
    println("Hello")            		
    Thread.sleep(2000L)          
    println("Process end!")            
}
//履行成果：
//launch started!
//Hello
//Kotlin

三者区别如下：

• launch：无法获取履行成果，回来类型Job，不会堵塞；
• async：可获取履行成果，回来类型Deferred，调用await()会堵塞，不调用则不会堵塞但也无法获取履行成果；
• runBlocking：可获取履行成果，堵塞当时线程的履行，多用于Demo、测试，官方推荐只用于连接线程与协程。

以launch为例，看一下它的源码

public fun CoroutineScope.launch(
    //①
    context: CoroutineContext = EmptyCoroutineContext,
    //②
    start: CoroutineStart = CoroutineStart.DEFAULT,
    //③
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

launch源码有三个参数分别对其解释一下：

• context： 协程的上下文，用于供给协程发动和运转时需求的信息，默许值是EmptyCoroutineContext，有默许值就能够不传，但是也能够传递Kotlin供给的Dispatchers来指定协程运转在哪一个线程中
• start： 协程的发动形式；
• block： 这个能够理解为协程的函数体，函数类型为suspend CoroutineScope.() -> Unit

经过对参数的阐明，上面关于launch的创立也能够这么写:

fun coroutineTest() {
    val scope = CoroutineScope(Job())
    val block: suspend CoroutineScope.() -> Unit = {
        println("Hello")
        delay(1000L)
        println("Kotlin")
    }
    scope.launch(block = block)
}

反编译成Java代码如下：

public final class CoroutineDemoKt {
    public static final void main() {
        coroutineTest();
        Thread.sleep(2000L);
    }
    // $FF: synthetic method
    public static void main(String[] var0) {
        main();
    }
    public static final void coroutineTest() {
        CoroutineScope scope = CoroutineScopeKt.CoroutineScope((CoroutineContext)JobKt.Job$default((Job)null, 1, (Object)null));
        //Function2 是Kotlin 为 block 变量生成的静态变量以及办法。
        //完结状况机的逻辑
        Function2 block = (Function2)(new Function2((Continuation)null) {
            int label;
            @Nullable
            public final Object invokeSuspend(@NotNull Object $result) {
                Object var3 = IntrinsicsKt.getCOROUTINE_SUSPENDED();
                String var2;
                switch(this.label) {
                    case 0:
                        ResultKt.throwOnFailure($result);
                        var2 = "Hello";
                        System.out.println(var2);
                        this.label = 1;
                        if (DelayKt.delay(1000L, this) == var3) {
                                return var3;
                        }
                        break;
                    case 1:
                        ResultKt.throwOnFailure($result);
                        break;
                    default:
                        throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
                }
                var2 = "Kotlin";
                System.out.println(var2);
                return Unit.INSTANCE;
            }
            @NotNull
            public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
                Intrinsics.checkNotNullParameter(completion, "completion");
                Function2 var3 = new <anonymous constructor>(completion);
                return var3;
            }
            public final Object invoke(Object var1, Object var2) {
                    return ((<undefinedtype>)this.create(var1, (Continuation)var2)).invokeSuspend(Unit.INSTANCE);
            }
        });
        BuildersKt.launch$default(scope, (CoroutineContext)null, (CoroutineStart)null, block, 3, (Object)null);
    }
}

2.协程是怎样被创立出来的

还是以launch的源码为例进行剖析

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
            LazyStandaloneCoroutine(newContext, block) else
            StandaloneCoroutine(newContext, active = true)
    //协程的创立看这儿
    coroutine.start(start, coroutine, block)
    return coroutine
}

coroutine.start为协程的创立与发动，这个start进入到了AbstractCoroutine，是一个抽象类，里边的start办法专门用于发动协程。

public abstract class AbstractCoroutine<in T>(
    parentContext: CoroutineContext,
    initParentJob: Boolean,
    active: Boolean
) : JobSupport(active), Job, Continuation<T>, CoroutineScope {
    ...
    /**
     * 用给定的block和start发动协程
     * 最多调用一次
     */
    public fun <R> start(start: CoroutineStart, receiver: R, block: suspend R.() -> T) {
        start(block, receiver, this)
    }
}

AbstractCoroutine中的start函数担任发动协程，一起发动是根据block和发动战略决议的，那么发动战略是什么? 以及发动战略完结了什么作业?

3.发动战略是什么

public enum class CoroutineStart {
   /**
    * 根据上下文当即调度协程履行。
    */ 
    DEFAULT
   /**
    * 延迟发动协程，只在需求时才发动。
    * 假如协程[Job]在它有机会开端履行之前被撤销，那么它根本不会开端履行
    * 而是以一个反常结束。
    */ 
    LAZY

   /**
    * 以一种不可撤销的办法，根据其上下文安排履行的协程；
    * 类似于[DEFAULT]，但是协程在开端履行之前不能撤销。
    * 协程在挂起点的可撤销性取决于挂起函数的详细完结细节，如[DEFAULT]。
    */ 
    ATOMIC
   /**
    * 当即履行协程，直到它在当时线程中的第一个挂起点；
    */ 
    UNDISPATCHED：
}

4.发动战略完结了什么作业

协程在承认发动战略之后就会开端履行它的使命，它的使命在invoke()函数中被分为不同的履行办法

/**
 * 用这个协程的发动战略发动相应的block作为协程
 */
public operator fun <T> invoke(block: suspend () -> T, completion: Continuation<T>): Unit =
    when (this) {
        DEFAULT -> block.startCoroutineCancellable(completion)
        ATOMIC -> block.startCoroutine(completion)
        UNDISPATCHED -> block.startCoroutineUndispatched(completion)
        LAZY -> Unit 
    }

这儿直接对block.startCoroutine(completion)进行剖析，block.startCoroutineCancellable和block.startCoroutineUndispatched也仅仅在startCoroutine的基础上添加了一些额定的功用，前者表明发动协程今后能够呼应撤销，后者表明协程发动今后不会被分发。

/**
 * 发动一个没有接收器且成果类型为[T]的协程。
 * 每次调用这个函数时，它都会创立并发动一个新的、可挂起核算实例。
 * 当协程以一个成果或一个反常完结时，将调用[completion]连续。
 */
public fun <T> (suspend () -> T).startCoroutine(completion: Continuation<T) {
    createCoroutineUnintercepted(completion).intercepted().resume(Unit)
}

先来看一下createCoroutineUnintercepted()做了哪些作业

//能够理解为一种声明
//	 ↓
public expect fun <T> (suspend () -> T).createCoroutineUnintercepted(completion: Continuation<T>
): Continuation<Unit>

expect的意思是希望、期盼，这儿能够理解为一种声明，希望在详细的平台中完结。

进入到createCoroutineUnintercepted()的源码中看到并没有什么完结，这首要是由于Kotlin是面向多个平台的详细的完结需求在特定平台中才干找到，这儿进入IntrinsicsJvm.kt中剖析。

//IntrinsicsJvm#createCoroutineUnintercepted
//actual代表的是createCoroutineUnintercepted在JVM平台上的详细完结      
//	↓
public actual fun <T> (suspend () -> T).createCoroutineUnintercepted(
    completion: Continuation<T>
): Continuation<Unit> {
    val probeCompletion = probeCoroutineCreated(completion)
    //	       难点
    //	        ↓
    return if (this is BaseContinuationImpl)
        //会进入这儿履行
        create(probeCompletion)
    else
        createCoroutineFromSuspendFunction(probeCompletion) {
            (this as Function1<Continuation<T>, Any?>).invoke(it)
        }
}

这儿的actual便是在详细品台上的完结。

上面的代码中有一个难点是【this】 这个this的含义假如仅仅在反编译代码或许源码中去看很难发现它是什么，这儿要经过源码、字节码、反编译的Java代码进行剖析，这儿我以截图进行展现

com/example/coroutines/CoroutineDemoKt$coroutineTest$block$1是block详细的完结类。它承继自kotlin/coroutines/jvm/internal/SuspendLambda

internal abstract class SuspendLambda(
    public override val arity: Int,
    completion: Continuation<Any?>?
) : ContinuationImpl(completion), FunctionBase<Any?>, SuspendFunction {
    constructor(arity: Int) : this(arity, null)
    public override fun toString(): String =
        if (completion == null)
            Reflection.renderLambdaToString(this) // this is lambda
        else
            super.toString() // this is continuation
}

internal abstract class ContinuationImpl(
    completion: Continuation<Any?>?,
    private val _context: CoroutineContext?
) : BaseContinuationImpl(completion) {
    constructor(completion: Continuation<Any?>?) : this(completion, completion?.context)
}

internal abstract class BaseContinuationImpl(
    public val completion: Continuation<Any?>?) : Continuation<Any?>, CoroutineStackFrame, Serializable {
    public open fun create(completion: Continuation<*>): Continuation<Unit> {
        throw UnsupportedOperationException("create(Continuation) has not been overridden")
    }
}

SuspendLambda是ContinuationImpl的子类，ContinuationImpl又是BaseContinuationImpl的子类， 所以能够得到定论if (this is BaseContinuationImpl)的成果为true， 然后会进入到 create(probeCompletion)函数中

这个create()函数抛出了一个反常，意思便是办法没有被重写，潜台词便是create()这个办法是要被重写的，假如不重写就会抛出反常。 那么create()办法又是在哪里重写的呢。答案就在反编译后的Java代码中的create办法

//这段代码来自launch创立的反编译后的Java代码
//create函数被重写
public final Continuation create(@Nullable Object value, @NotNull Continuation completion) {
    Intrinsics.checkNotNullParameter(completion, "completion");
    Function2 var3 = new <anonymous constructor>(completion);
    return var3;
}

这行代码，其实就对应着协程被创立的时刻。

剖析完了startContinue()再来剖析一下startCoroutineCancellable()做了什么，由于协程默许的发动战略是CoroutineStart.DEFAULT

//Cancellable#startCoroutineCancellable
/**
 * 运用此函数以可撤销的办法发动协程，以便它能够在等候调度时被撤销。
 */
public fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>): Unit = runSafely(completion) {
    createCoroutineUnintercepted(completion).intercepted().resumeCancellableWith(Result.success(Unit))
}
//Continuation#startCoroutine
public fun <T> (suspend () -> T).startCoroutine(completion: Continuation<T>) {
    createCoroutineUnintercepted(completion).intercepted().resume(Unit)
}

经过对比能够发现startCoroutineCancellable()和startCoroutine()的内部并没有太大区别，他们终究都会调用createCoroutineUnintercepted()，只不过前者在终究调用了resumeCancellableWith(),后者调用的是resume()，这个稍后剖析。

5.协程是怎样被发动的

协程的创立剖析完结后再来剖析一下协程是怎样发动的，再回过头看一下createCoroutineUnintercepted()之后做了什么

//Cancellable#startCoroutineCancellable 
/**
 * 运用此函数以可撤销的办法发动协程，以便它能够在等候调度时被撤销。 
 */ 
public fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>): Unit = runSafely(completion) {
//                                        现在看这儿   
//                                             ↓
   createCoroutineUnintercepted(completion).intercepted().resumeCancellableWith(Result.success(Unit))
}

进入到intercepted()，它也是需求找到对应平台上的详细完结，这儿还是以JVM平台进行剖析

//需求找到对应平台的详细完结
public expect fun <T> Continuation<T>.intercepted(): Continuation<T>
//JVM平台的完结
//IntrinsicsJvm.kt#intercepted
/**
 * 运用[ContinuationInterceptor]阻拦continuation。
 */
public actual fun <T> Continuation<T>.intercepted(): Continuation<T> =
    (this as? ContinuationImpl)?.intercepted() ?: this

在剖析协程的创立进程中现已剖析过上面的this代表的便是block变量，所以这儿的强转是树立的，那么这儿的intercepted()调用的便是ContinuationImpl目标中的函数

/**
 * 命名挂起函数的状况机扩展自这个类
 */
internal abstract class ContinuationImpl(
    completion: Continuation<Any?>?,
    private val _context: CoroutineContext?
) : BaseContinuationImpl(completion) {
    constructor(completion: Continuation<Any?>?) : this(completion, completion?.context)
    public override val context: CoroutineContext
        get() = _context!!
    @Transient
    private var intercepted: Continuation<Any?>? = null
    //要点看这儿
    public fun intercepted(): Continuation<Any?> =
        intercepted
            ?: (context[ContinuationInterceptor]?.interceptContinuation(this) ?: this)
                .also { intercepted = it }
}

首要intercepted()办法会判别它的成员变量intercepted是否为空，假如为空则调用context[ContinuationInterceptor]获取上下文当中的Dispatchers目标，这个Dispatchers目标又是什么呢？

6.协程发动进程中的Dispatchers是什么

这儿以launch的源码为主进行剖析

fun main() {
    CoroutineScope(Job()).launch(Dispatchers.Default) {
        delay(1000L)
        println("Kotlin")
    }
    println("Hello")
    Thread.sleep(2000L)
}
public fun CoroutineScope.launch(
//  传入的Dispatchers.Default表明的便是这个context
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

传入的Dispatchers.Default对应的是context参数，从源码可知这个参数不是必传的，由于它有默许值EmptyCoroutineContext，Kotlin官方用它来代替了null，这是Kotlin空安全思维。

传入Dispatchers.Default之后便是用它代替了EmptyCoroutineContext，那么这儿的Dispatchers的界说跟CoroutineContext有什么联系呢？看一下Dispatchers的源码

/**
* 对[CoroutineDispatcher]的各种完结进行分组。
*/
public actual object Dispatchers {
    /**
     * 用于CPU密集型使命的线程池，一般来说它内部的线程个数是与机器 CPU 中心数量保持一致的
     * 不过它有一个最小限制2，
     */
    public actual val Default: CoroutineDispatcher = DefaultScheduler
    /**
     * 主线程，在Android中才干够运用，首要用于UI的绘制，在一般JVM上无法运用
     */
    public actual val Main: MainCoroutineDispatcher get() = MainDispatcherLoader.dispatcher
    /**
     * 不局限于任何特定线程，会根据运转时的上下文环境决议
     */
    public actual val Unconfined: CoroutineDispatcher = kotlinx.coroutines.Unconfined
    /**
     * 用于履行IO密集型使命的线程池，它的数量会多一些，默许最大线程数量为64个
     * 详细的线程数量能够经过kotlinx.coroutines.io.parallelism装备
     * 它会和Default同享线程，当Default还有其他空闲线程时是能够被IO线程池复用。
     */
    public val IO: CoroutineDispatcher = DefaultIoScheduler
}

Dispatchers是一个单例目标，它里边的几个类型都是CoroutineDispatcher。

/**
 * 一切协程调度器完结扩展的基类。
 */
public abstract class CoroutineDispatcher :
    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor { }
/**
 * 标记阻拦协程连续的协程上下文元素。
 */
public interface ContinuationInterceptor : CoroutineContext.Element { }
/**
 * CoroutineContext的一个元素。协程上下文的一个元素自身便是一个单例上下文。
 */
public interface Element : CoroutineContext { }

CoroutineDispatcher自身又是CoroutineContext，从上面的源码就能够得出他们的联系能够这么表明：

7.协程发动进程中的Dispatchers做了什么

协程的运转是离不开线程的，Dispatchers的效果便是承认协程运转在哪个线程，默许是Default，然后它也能够运转在IO、Main等线程，它担任将使命调度的指定的现递上，详细的剖析后边再写。

经过前剖析在协程中默许的是Default线程池，因而这儿进入的便是Default线程池。 那么咱们回到intercepted()函数继续进行剖析，经过Debug进入到CoroutineDispatcher中的interceptContinuation()函数

public abstract class CoroutineDispatcher :
    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {
    /**
     * 回来一个封装了供给的[continuation]的continuation，然后阻拦一切的康复。
     * 这个办法通常应该是反常安全的。
     * 从此办法抛出的反常或许会使运用此调度程序的协程处于不一致且难以调试的状况。
     */
    public final override fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T> =
    DispatchedContinuation(this, continuation)
}

interceptContinuation()回来了一个DispatchedContinuation目标，其中的this便是默许的线程池Dispatchers.Default。

然后经过DispatchedContinuation调用它的resumeCancellableWith()函数，这个函数前面剖析过是从哪里进入的，这儿不再阐明。

internal class DispatchedContinuation<in T>(
	@JvmField val dispatcher: CoroutineDispatcher,
	@JvmField val continuation: Continuation<T>
) : DispatchedTask<T>(MODE_UNINITIALIZED), CoroutineStackFrame, Continuation<T> by continuation {
    ...
    public fun <T> Continuation<T>.resumeCancellableWith(
        result: Result<T>,
        onCancellation: ((cause: Throwable) -> Unit)? = null
    ): Unit = when (this) {
        is DispatchedContinuation -> resumeCancellableWith(result, onCancellation)
        else -> resumeWith(result)
    }
    //咱们内联它来保存仓库上的一个条目，在它显示的状况下(无限制调度程序)
    //它只在Continuation<T>.resumeCancellableWith中运用
    inline fun resumeCancellableWith(
        result: Result<T>,
        noinline onCancellation: ((cause: Throwable) -> Unit)?
    ) {
        val state = result.toState(onCancellation)
        if (dispatcher.isDispatchNeeded(context)) {
                _state = state
                resumeMode = MODE_CANCELLABLE
                dispatcher.dispatch(context, this)
            } else {
                executeUnconfined(state, MODE_CANCELLABLE) {
                    if (!resumeCancelled(state)) {
                        resumeUndispatchedWith(result)
                    }
                }
            }
        }
	...
}

DispatchedContinuation承继了DispatchedTask：

internal abstract class DispatchedTask<in T>(
    @JvmField public var resumeMode: Int
) : SchedulerTask() { }
internal actual typealias SchedulerTask = Task
internal abstract class Task(
    @JvmField var submissionTime: Long,
    @JvmField var taskContext: TaskContext
) : Runnable {
    constructor() : this(0, NonBlockingContext)
    inline val mode: Int get() = taskContext.taskMode // TASK_XXX
}

DispatchedTask承继了SchedulerTask，一起SchedulerTask还是Task的别号，Task又完结了Runnable接口，这意味着它能够被分发到Java的线程中去履行了。

一起能够得出一个定论：DispatchedContinuation是一个Runnable。

DispatchedContinuation还完结了Continuation接口，它还运用了类委托的语法将接口的详细完结交给了它的成员特点continuation，那么这儿对上面的定论进行弥补：DispatchedContinuation不仅是一个Runnable，还是一个Continuation。

DispatchedContinuation剖析完了进入它的resumeCancellableWith()函数剖析：

inline fun resumeCancellableWith(
    result: Result<T>,
    noinline onCancellation: ((cause: Throwable) -> Unit)?
) {
    val state = result.toState(onCancellation)
    //①
    if (dispatcher.isDispatchNeeded(context)) {
        _state = state
        resumeMode = MODE_CANCELLABLE
        //②
        dispatcher.dispatch(context, this)
    } else {
        //这儿便是Dispatchers.Unconfined状况，这个时分协程不会被分发到别的线程，只运转在当时线程中。
        executeUnconfined(state, MODE_CANCELLABLE) {
            if (!resumeCancelled(state)) {
                resumeUndispatchedWith(result)
            }
        }
    }
}

• 注释①： dispatcher来自CoroutineDispatcher，isDispatchNeeded便是它的成员函数

public abstract class CoroutineDispatcher :
AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {
    /**
     * 假如协程的履行应该运用[dispatch]办法履行，则回来' true '。
     * 大多数dispatchers的默许行为是回来' true '。
     */
    public open fun isDispatchNeeded(context: CoroutineContext): Boolean = true
}

isDispatchNeeded()默许回来true，且在大多数状况下都是true， 但是也有个破例便是在它的子类中Dispatchers.Unconfined会将其重写成 false。

internal object Unconfined : CoroutineDispatcher() {
    // 只有Unconfined会重写成false 
    override fun isDispatchNeeded(context: CoroutineContext): Boolean = false
}

由于默许是true，所以接下来会进入注释②

• 注释②： 注释②调用了CoroutineDispatcher中的dispatch()办法将block代码块调度到另一个线程上，这儿的线程池默许值是Dispatchers.Default所以使命被分发到Default线程池，第二个参数是Runnable，这儿传入的是this，由于DispatchedContinuation间接的完结了Runnable接口。

public abstract class CoroutineDispatcher :
AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {
    /**
     * 在给定的[上下文]中，将一个可运转的block调度到另一个线程上。
     * 这个办法应该保证给定的[block]终究会被调用，不然体系或许会到达死锁状况而且永久不会终止。
     */ 
    public abstract fun dispatch(context: CoroutineContext, block: Runnable)
}

由于默许线程池是Dispatchers.Default，所以这儿的dispatch()其实调用的是Dispatchers.Default.dispatch，这儿的Dispatchers.Default的本质是一个单例目标DefaultScheduler， 它承继了SchedulerCoroutineDispatcher：

//承继了SchedulerCoroutineDispatcher
internal object DefaultScheduler : SchedulerCoroutineDispatcher(
    CORE_POOL_SIZE, MAX_POOL_SIZE,
    IDLE_WORKER_KEEP_ALIVE_NS, DEFAULT_SCHEDULER_NAME
) {
    // 封闭调度程序，仅用于Dispatchers.shutdown()
    internal fun shutdown() {
        super.close()
    }
    //重写 (Dispatchers.Default as ExecutorCoroutineDispatcher).close()
    override fun close() {
        throw UnsupportedOperationException("Dispatchers.Default cannot be closed")
    }
    override fun toString(): String = "Dispatchers.Default"
}
internal open class SchedulerCoroutineDispatcher(
    private val corePoolSize: Int = CORE_POOL_SIZE,
    private val maxPoolSize: Int = MAX_POOL_SIZE,
    private val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,
    private val schedulerName: String = "CoroutineScheduler",
) : ExecutorCoroutineDispatcher() {
    private var coroutineScheduler = createScheduler()
    override fun dispatch(context: CoroutineContext, block: Runnable): Unit = coroutineScheduler.dispatch(block)	
}

SchedulerCoroutineDispatcher中实践调用dispatch()办法的实践是coroutineScheduler，所以dispatcher.dispatch()实践调用的是coroutineScheduler.dispatch()

internal class CoroutineScheduler(
    @JvmField val corePoolSize: Int,
    @JvmField val maxPoolSize: Int,
    @JvmField val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,
    @JvmField val schedulerName: String = DEFAULT_SCHEDULER_NAME
) : Executor, Closeable {
    //Executor接口中的办法被覆盖
    override fun execute(command: Runnable) = dispatch(command)
    fun dispatch(block: Runnable, taskContext: TaskContext = NonBlockingContext, tailDispatch: Boolean = false) {
        trackTask() 
        //将传入的 Runnable 类型的 block（也便是 DispatchedContinuation），包装成 Task。
        val task = createTask(block, taskContext)
        // 拿到当时的使命行列, 测验将使命提交到本地行列并根据成果进行操作
        //Worker其实是一个内部类，其实便是Java的Thread类
        val currentWorker = currentWorker()
        //将当时的 Task 添加到 Worker 线程的本地行列，等候履行。
        val notAdded = currentWorker.submitToLocalQueue(task, tailDispatch)
        if (notAdded != null) {
            if (!addToGlobalQueue(notAdded)) {
                // 全局行列在封闭/封闭的终究一步封闭——不再承受任何使命
                throw RejectedExecutionException("$schedulerName was terminated")
            }
        }
        val skipUnpark = tailDispatch && currentWorker != null
        // 
        if (task.mode == TASK_NON_BLOCKING) {
            if (skipUnpark) return
            signalCpuWork()
        } else {
            //添加堵塞使命 
            signalBlockingWork(skipUnpark = skipUnpark)
        }
    }
}

8.Worker是什么？

 internal inner class Worker private constructor() : Thread() {
    init {
        isDaemon = true		//守护线程默许为true
    }
      private fun runWorker() {
        var rescanned = false
        while (!isTerminated && state != WorkerState.TERMINATED) {
            //在while循环中一向测验从行列中找到使命
            val task = findTask(mayHaveLocalTasks)
            // 找到使命则进行下一步
            if (task != null) {
                rescanned = false
                minDelayUntilStealableTaskNs = 0L
                //履行使命
                executeTask(task)
                continue
            } else {
                mayHaveLocalTasks = false
            }
            if (minDelayUntilStealableTaskNs != 0L) {
                if (!rescanned) {
                    rescanned = true
                } else {
                    rescanned = false
                    tryReleaseCpu(WorkerState.PARKING)
                    interrupted()
                    LockSupport.parkNanos(minDelayUntilStealableTaskNs)
                    minDelayUntilStealableTaskNs = 0L
                }
                continue
            }
            //没有使命则中止履行，线程或许会封闭
            tryPark()
        }
        tryReleaseCpu(WorkerState.TERMINATED)
    }
 }

9.Worker中的使命被找到后是怎样履行的？

internal inner class Worker private constructor() : Thread() {
    private fun executeTask(task: Task) {
        val taskMode = task.mode
        //当它找到一个使命时，这个作业者就会调用它
        idleReset(taskMode)
        beforeTask(taskMode)
        runSafely(task)
        afterTask(taskMode)
    }
    fun runSafely(task: Task) {
        try {
            task.run()
        } catch (e: Throwable) {
            val thread = Thread.currentThread()
            thread.uncaughtExceptionHandler.uncaughtException(thread, e)
        } finally {
            unTrackTask()
        }
    }
}
internal abstract class Task(
    @JvmField var submissionTime: Long,
    @JvmField var taskContext: TaskContext
) : Runnable {
    constructor() : this(0, NonBlockingContext)
    inline val mode: Int get() = taskContext.taskMode // TASK_XXX
}

终究进入到runSafely()函数中，然后调用run办法，前面剖析过，将DispatchedContinuation包装成一个完结了Runnable接口的Task，所以这儿的task.run()本质上便是调用的Runnable.run()，到这儿使命就协程使命就真实的履行了。

那么也就能够知道这儿的run() 函数其实调用的便是DispatchedContinuation父类DispatchedTask中的run()函数:

internal abstract class DispatchedTask<in T>(
    @JvmField public var resumeMode: Int
) : SchedulerTask() {
    public final override fun run() {
        assert { resumeMode != MODE_UNINITIALIZED } 
        val taskContext = this.taskContext
        var fatalException: Throwable? = null
        try {
            val delegate = delegate as DispatchedContinuation<T>
            val continuation = delegate.continuation
            withContinuationContext(continuation, delegate.countOrElement) {
                val context = continuation.context
                val state = takeState() // 
                val exception = getExceptionalResult(state)
                 // 检查连续开端是否在反常状况下康复。
                 // 假如是这样，它将主导撤销，不然原始反常将被静默地丢掉。
                val job = if (exception == null && resumeMode.isCancellableMode) context[Job] else null
                if (job != null && !job.isActive) {
                    //①
                    val cause = job.getCancellationException()
                    cancelCompletedResult(state, cause)
                    continuation.resumeWithStackTrace(cause)
                } else {
                    if (exception != null) {
                        //②
                        continuation.resumeWithException(exception)
                    } else {
                        //③
                        continuation.resume(getSuccessfulResult(state))
                    }
                }
            }
        } catch (e: Throwable) {
            // 
            fatalException = e
        } finally {
            val result = runCatching { taskContext.afterTask() }
            handleFatalException(fatalException, result.exceptionOrNull())
        }
    }	
}

• 注释①： 在代码履行之前这儿会判别当时协程是否被撤销。假如被撤销了就会调用 continuation.resumeWithStackTrace(cause)将详细的原因传出去；
• 注释②： 判别协程是否发生了反常假如现已发生反常就调用continuation.resumeWithException(exception)将反常传递出去；
• 注释③： 假如前面运转没有问题，就进入终究一步continuation.resume(getSuccessfulResult(state)，此刻协程正式被发动而且履行launch当中传入的block或许Lambda函数。

这儿其实便是协程与线程发生相关的地方。

以上便是协程的创立、发动的流程，但是还有几个问题没有弄理解：

• 协程创立的时分CoroutineScope是什么
• 协程的结构化中父子联系是怎样树立的
• 结构化树立后又是怎样撤销的

接下来对这几个问题进行回答：

10.协程创立的时分CoroutineScope是什么

前面对于协程的三种创立办法中的launch、async的创立办法中都有CoroutineScope(Job())，现在先来剖析下CoroutineScope做了什么，先来看下launch和async的源码。

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}
public fun <T> CoroutineScope.async(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> T
): Deferred<T> {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyDeferredCoroutine(newContext, block) else
        DeferredCoroutine<T>(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

async、launch的扩展接收者都是CoroutineScope，这就意味着他们等价于CoroutineScope的成员办法，假如要调用就必须先获取到CoroutineScope的目标。

public interface CoroutineScope {
    /**
     * 此效果域的上下文
     * Context被效果域封装，用于完结作为效果域扩展的协程构建器
     * 不建议在一般代码中拜访此特点，除非拜访[Job]实例以取得高级用法
     */
    public val coroutineContext: CoroutineContext
}

CoroutineScope是一个接口，这个接口所做的也仅仅对CoroutineContext做了一层封装而已。CoroutineScope最大的效果便是能够便利的批量的控制协程，例如结构化并发。

11.CoroutineScope与结构化并发

fun coroutineScopeTest() {
    val scope = CoroutineScope(Job())
    scope.launch {
        launch {
            delay(1000000L)
            logX("ChildLaunch 1")
        }
        logX("Hello 1")
        delay(1000000L)
        logX("Launch 1")
    }
    scope.launch {
        launch {
            delay(1000000L)
            logX("ChildLaunch 2")
        }
        logX("Hello 2")
        delay(1000000L)
        logX("Launch 2")
    }
    Thread.sleep(1000L)
    scope.cancel()
}
//输出成果：
//================================
//Hello 2 
//Thread:DefaultDispatcher-worker-2
//================================
//================================
//Hello 1 
//Thread:DefaultDispatcher-worker-1
//================================

上面的代码完结了结构化，仅仅创立了CoroutineScope(Job())和运用launch发动了几个协程就完结了结构化，结构如图所示，那么它的父子结构是怎样树立的？

CoroutineScope这儿要阐明一下为什么分明是是一个接口，但是在创立的时分却能够以结构函数的办法运用。在Kotlin中的命名规矩是以【驼峰法】为主的，在特别状况下是能够打破这个规矩的，CoroutineScope便是一个特别的状况，它是一个顶层函数但它发挥的效果却是结构函数，同样的还有Job()，它也是顶层函数，在Kotlin中当顶层函数被用作结构函数的时分首字母都是大写的。

12.协程的结构化中父子联系是怎样树立的

再来看一下CoroutineScope作为结构函数运用时的源码：

/**
 * 创立一个[CoroutineScope]，包装给定的协程[context]。
 * 
 * 假如给定的[context]不包括[Job]元素，则创立一个默许的' Job() '。
 * 
 * 这样，任何子协程在这个范围或[撤销][协程]失利。就像在[coroutineScope]块中一样，
 * 效果域自身会撤销效果域的一切子效果域。
 */
public fun CoroutineScope(context: CoroutineContext): CoroutineScope =
	ContextScope(if (context[Job] != null) context else context + Job())

结构函数的CoroutineScope传入一个参数，这个参数假如包括Job元素则直接运用，假如不包括Job则会创立一个新的Job，这就阐明每一个coroutineScope目标中的 Context中必定会存在一个Job目标。而在创立一个CoroutineScope目标时这个Job()是一定要传入的，由于CoroutineScope便是经过这个Job()目标办理协程的。

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

上面的代码是launch的源码，剖析一下LazyStandaloneCoroutine和StandaloneCoroutine。

private open class StandaloneCoroutine(
    parentContext: CoroutineContext,
    active: Boolean
) : AbstractCoroutine<Unit>(parentContext, initParentJob = true, active = active) {
    override fun handleJobException(exception: Throwable): Boolean {
        handleCoroutineException(context, exception)
        return true
    }
}
private class LazyStandaloneCoroutine(
    parentContext: CoroutineContext,
    block: suspend CoroutineScope.() -> Unit
) : StandaloneCoroutine(parentContext, active = false) {
    private val continuation = block.createCoroutineUnintercepted(this, this)
    override fun onStart() {
        continuation.startCoroutineCancellable(this)
    }
}

StandaloneCoroutine是AbstractCoroutine子类，AbstractCoroutine是协程的抽象类， 里边的参数initParentJob = true表明协程创立之后需求初始化协程的父子联系。LazyStandaloneCoroutine是StandaloneCoroutine的子类，active=false使命它是以懒加载的办法创立协程。

public abstract class AbstractCoroutine<in T>(
	parentContext: CoroutineContext,
	initParentJob: Boolean,
	active: Boolean
) : JobSupport(active), Job, Continuation<T>, CoroutineScope {
    init {
        /**
         * 在上下文中的父协程和当时协程之间树立父子联系
         * 假如父协程现已被撤销他或许导致当时协程也被撤销
         * 假如协程从onCancelled或许onCancelling内部操作其状况，
         * 那么此刻树立父子联系是危险的
         */
        if (initParentJob) initParentJob(parentContext[Job])
    }
}

AbstractCoroutine是一个抽象类他承继了JobSupport，而JobSupport是Job的详细完结。

在init函数中根据initParentJob判别是否树立父子联系，initParentJob的默许值是true因而if中的initParentJob()函数是一定会履行的，这儿的parentContext[Job]取出的的Job便是在launche创立时传入的Job。

initParentJob()是JobSupport中的办法，由于AbstractCoroutine承继自JobSupport，所以进入JobSupport剖析这个办法。

public open class JobSupport constructor(active: Boolean) : Job, ChildJob, ParentJob, SelectClause0 {
    final override val key: CoroutineContext.Key<*> get() = Job
    /**
     * 初始化父类的Job
     * 在一切初始化之后最多调用一次
     */
    protected fun initParentJob(parent: Job?) {
        assert { parentHandle == null }
        //①
        if (parent == null) {
            parentHandle = NonDisposableHandle
            return
        }
        //②
        parent.start() // 保证父协程现已发动
        @Suppress("DEPRECATION")
        //③
        val handle = parent.attachChild(this)
        parentHandle = handle
        // 检查注册的状况
        if (isCompleted) {
            handle.dispose()
            parentHandle = NonDisposableHandle 
        }
    }
}

上面的源码initParentJob中添加了三处注释，现在分别对这三处注释进行剖析：

• if (parent == null)： 这儿是对是否存在父Job的判别，假如不存在则不再进行后边的作业，也就谈不上树立父子联系了。由于在Demo中传递了Job()因而这儿的父Job是存在的，所以代码能够继续履行。
• parent.start()： 这儿保证parent对应的Job发动了；
• parent.attachChild(this)： 这儿便是将子Job添加到父Job中，使其成为parent的子Job。这儿其实便是树立了父子联系。

用一句话来归纳这个联系便是：每一个协程都有一个Job，每一个Job又有一个父Job和多个子Job，能够看做是一个树状结构。这个联系能够用下面这张图表明:

13.协程的结构化树立后又是怎样撤销的

结构化能够被创立的一起CoroutineScope还供给了可撤销的函数，Demo中经过scope.cancel()撤销了协程，它的流程又是怎样的呢？先从scope.cancel中的cancel看起

/**
 * 撤销这个scope，包括当时Job和子Job
 * 假如没有Job，可抛出反常IllegalStateException
 */
public fun CoroutineScope.cancel(cause: CancellationException? = null) {
    val job = coroutineContext[Job] ?: error("Scope cannot be cancelled because it does not have a job: $this")
    job.cancel(cause)
}

scope.cancel又是经过job.cancel撤销的，这个cancel详细完结是在JobSupport中

public open class JobSupport constructor(active: Boolean) : Job, ChildJob, ParentJob, SelectClause0 {
    ...
    public override fun cancel(cause: CancellationException?) {
        cancelInternal(cause ?: defaultCancellationException())
    }
    public open fun cancelInternal(cause: Throwable) {
        cancelImpl(cause)
    }
    /**
     * 当cancelChild被调用的时分cause是Throwable或许ParentJob
     * 假如反常现已被处理则回来true，不然回来false
     */
    internal fun cancelImpl(cause: Any?): Boolean {
        var finalState: Any? = COMPLETING_ALREADY
        if (onCancelComplete) {
            // 保证它正在完结，假如回来状况是 cancelMakeCompleting 阐明它现已完结
            finalState = cancelMakeCompleting(cause)
            if (finalState === COMPLETING_WAITING_CHILDREN) return true
        }
        if (finalState === COMPLETING_ALREADY) {
            //转换到撤销状况，当完结时调用afterCompletion
            finalState = makeCancelling(cause)
        }
        return when {
            finalState === COMPLETING_ALREADY -> true
            finalState === COMPLETING_WAITING_CHILDREN -> true
            finalState === TOO_LATE_TO_CANCEL -> false
            else -> {
                afterCompletion(finalState)
                true
            }
        }
    }
    /**
     * 假如没有需求协程体完结的使命回来true并当即进入完结状况等候子类完结
     * 这儿代表的是当时Job是否有协程体需求履行
     */
    internal open val onCancelComplete: Boolean get() = false
}

job.cancel()终究调用的是JobSupport中的cancelImpl()。这儿它分为两种状况，判别根据是onCancelComplete，代表的便是当时Job是否有协程体需求履行，假如没有则回来true。这儿的Job是自己创立的且没有需求履行的协程代码因而回来成果是true，所以就履行cancelMakeCompleting()表达式。

private fun cancelMakeCompleting(cause: Any?): Any? {
    loopOnState { state ->
        ...
        val finalState = tryMakeCompleting(state, proposedUpdate)
        if (finalState !== COMPLETING_RETRY) return finalState
    }
}
private fun tryMakeCompleting(state: Any?, proposedUpdate: Any?): Any? {
    ...
    return tryMakeCompletingSlowPath(state, proposedUpdate)
}
private fun tryMakeCompletingSlowPath(state: Incomplete, proposedUpdate: Any?): Any? {
    //获取状况列表或提升为列表以正确操作子列表
    val list = getOrPromoteCancellingList(state) ?: return COMPLETING_RETRY
    ...
    notifyRootCause?.let { notifyCancelling(list, it) }
    ...
    return finalizeFinishingState(finishing, proposedUpdate)
}

进入cancelMakeCompleting()后经过多次流转终究会调用tryMakeCompletingSlowPath()中的notifyCancelling()，在这个函数中才是履行子Job和父Job撤销的终究流程

private fun notifyCancelling(list: NodeList, cause: Throwable) {
    //首要撤销子Job
    onCancelling(cause)
    //告诉子Job
    notifyHandlers<JobCancellingNode>(list, cause)
    // 之后撤销父Job
    cancelParent(cause) // 试探性撤销——假如没有parent也没联系
}
private inline fun <reified T: JobNode> notifyHandlers(list: NodeList, cause: Throwable?) {
    var exception: Throwable? = null
    list.forEach<T> { node ->
        try {
            node.invoke(cause)
        } catch (ex: Throwable) {
            exception?.apply { addSuppressedThrowable(ex) } ?: run {
                exception =  CompletionHandlerException("Exception in completion handler $node for $this", ex)
            }
        }
    }
    exception?.let { handleOnCompletionException(it) }
}

notifyHandlers()中的流程便是遍历当时Job的子Job，并将撤销的cause传递曩昔，这儿的invoke()终究会调用 ChildHandleNode 的 invoke()办法

public open class JobSupport constructor(active: Boolean) : Job, ChildJob, ParentJob, SelectClause0 {
    ...
    internal class ChildHandleNode(
        @JvmField val childJob: ChildJob
    ) : JobCancellingNode(), ChildHandle {
        override val parent: Job get() = job
        override fun invoke(cause: Throwable?) = childJob.parentCancelled(job)
        override fun childCancelled(cause: Throwable): Boolean = job.childCancelled(cause)
    }
    public final override fun parentCancelled(parentJob: ParentJob) {
        cancelImpl(parentJob)
    }
}

childJob.parentCancelled(job)的调用终究调用的是JobSupport中的parentCanceled()函数，然后又回到了cancelImpl()中，也便是 Job 撤销的入口函数。这实践上就相当于在做递归调用。

子Job撤销完结后接着便是撤销父Job了，进入到cancelParent()函数中

/**
 * 撤销Job时调用的办法，以便或许将撤销传达到父类。
 * 假如父协程担任处理反常，则回来' true '，不然回来' false '。
 */ 
private fun cancelParent(cause: Throwable): Boolean {
    // Is scoped coroutine -- don't propagate, will be rethrown
    if (isScopedCoroutine) return true
    /* 
    * CancellationException被以为是“正常的”，当子协程发生它时父协程通常不会被撤销。
    * 这允许父协程撤销它的子协程(通常状况下)，而自身不会被撤销，
    * 除非子协程在其完结期间溃散并发生其他反常。
    */
    val isCancellation = cause is CancellationException
    val parent = parentHandle
    if (parent === null || parent === NonDisposableHandle) {
        return isCancellation
    }
    // 职责链形式
    return parent.childCancelled(cause) || isCancellation
}
/**
 * 在这个办法中，父类决议是否撤销自己(例如在重大毛病上)以及是否处理子类的反常。
 * 假如反常被处理，则回来' true '，不然回来' false '(调用者担任处理反常)
 */
public open fun childCancelled(cause: Throwable): Boolean {
    if (cause is CancellationException) return true
    return cancelImpl(cause) && handlesException
}

cancelParent的回来成果运用了职责链形式， 假如回来【true】表明父协程处理了反常，回来【false】则表明父协程没有处理反常。

当反常是CancellationException时假如是子协程发生的父协程不会撤销，或许说父协程会忽略子协程的撤销反常，假如是其他反常父协程就会呼应子协程的撤销了。

14.newCoroutineContext(context)

launch源码中第一行代码做了什么目前还不得而知，这儿剖析一下做了什么事

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
	//			便是这一行
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

/**
 * 为新的协程创立上下文。当没有指定其他调度程序或[ContinuationInterceptor]时，
 * 它会设置[Dispatchers.Default]，并添加对调试工具的可选支持(当翻开时)。
 */
public actual fun CoroutineScope.newCoroutineContext(context: CoroutineContext): CoroutineContext {
    //①
    val combined = coroutineContext.foldCopiesForChildCoroutine() + context
    //②
    val debug = if (DEBUG) combined + CoroutineId(COROUTINE_ID.incrementAndGet()) else combined
    //③
    return if (combined !== Dispatchers.Default && combined[ContinuationInterceptor] == null)
    debug + Dispatchers.Default else debug
}

• 注释①：这行代码首要调用了coroutineContext，这是由于newCoroutineContext()是CoroutineScope的扩展函数，CoroutineScope对CoroutineContext进行了封装，所以newCoroutineContext()函数中可直接拜访CoroutineScope的coroutineContext；foldCopiesForChildCoroutine()函数回来子协程要承继的[CoroutineContext]；然后跟传入的context参数进行兼并。这行代码便是让子协程能够承继父协程的上下文元素。
• 注释②：它的效果是在调试形式下，为咱们的协程目标添加唯一的 ID，这个ID便是在调试协程程序时呈现的日志如：Thread:DefaultDispatcher-worker-1 @coroutine#1中的@coroutine#1，其中的1便是这个ID。
• 注释③：假如兼并后的combined没有指定调度程序就默许运用Dispatcher.Default。

经过上面的剖析能够得出newCoroutineContext函数承认了默许运用的线程池是Dispatcher.Default，那么这儿为什么会默许运用Default线程池而不是Main呢？ 由于Kotlin并不是只针对Android开发的，它支持多个平台Main线程池仅在UI相关的平台中才会用到，而协程是不能脱离线程运转的，所以这儿默许运用Default线程池。

15.总结：

1. 协程是怎样被创立的

协程在承认自己的发动战略后进入到createCoroutineUnintercepted函数中创立了协程的Continuation实例，Continuation的完结类是ContinuationImpl，它承继自BaseContinuationImpl，在BaseContinuationImpl中调用了它的create() 办法，而这个create() 办法需求重写才干够完结不然会抛出反常，那么这个 create() 的重写便是反编译后的Java代码中create() 函数。

2. 协程是怎样被发动的

协程经过createCoroutineUnintercepted函数创立后紧接着就会调用它的 intercepted() 办法，将其封装成 DispatchedContinuation 目标，DispatchedContinuation 是Runnable 的子类，DispatchedContinuation会持有CoroutineDispatcher以及前面创立的Continuation目标，DispatchedContinuation调用内部的resumeCancellableWith()办法，然后进入到resumeCancellableWith() 中的dispatched.dispatch()，这儿会将协程的Continuation包装成Task并添加到Worker的本地使命行列等候履行。而这儿的Worker本质上是Java中的Thread，在这一步协程完结了线程的切换，使命添加到Worker的本地使命行列后就会经过run()办法发动使命，这儿调用的是task.run()，这儿的run终究是调用的DispatchedContinuation的父类DispatchedTask中的run()办法，在这个run办法中假如前面没有反常终究会调用continuation.resume()，然后就开端履行履行协程体中的代码了也便是反编译代码中的invokeSuspend()，这儿开端了协程状况机流程，这样协程就被发动了。

3. CoroutineScope与结构化的联系

CoroutineScope是一个接口，这个接口所做的也仅仅对CoroutineContext做了一层封装而已。CoroutineScope最大的效果便是能够便利的批量的控制协程，CoroutineScope在创立它的实例的时分是需求传入Job()目标的，由于CoroutineScope便是经过这个Job()目标办理协程的。协程的结构化联系也就因而而发生。 协程的结构化联系是一种父子联系，父子联系能够看做是一个N叉树的结构，用一句话来归纳这个联系便是：每一个协程都有一个Job，每一个Job又有一个父Job和多个子Job，能够看做是一个树状结构。 父子联系的树立是经过AbstractCoroutine中的initParentJob()进行的，而AbstractCoroutine是JobSuppert的子类，树立父子联系的进程便是首要承认是否有父类假如没有则不树立父子联系，假如有父类则需求保证父Job现已被发动，然后经过attachChild()函数将子Job添加到父Job中，这样就完结了父子联系的树立。

4. 父子联系树立后怎样撤销结构化的运转

由于是一个树结构因而协程的撤销以及反常的传达都是依照这个结构进行传递。当撤销Job时都会告诉自己的父Job和子Job，撤销子Job终究是以递归的办法传递给每一个Job。协程在向上撤销父Job时经过职责链形式一步一步的传递到最顶层的协程，一起假如子Job发生CancellationException反常时父Job会将其忽略，假如是其他反常父Job则会呼应这个反常。对于CancellationException引起的撤销只会向下传递撤销子协程；对于其他反常引起的撤销既向上传递也向下传递，终究会使一切的协程被撤销。