协程原理剖析----协程分发器原理深度解读

协程上下文Coroutine Context：

接着上一次https://www.cnblogs.com/webor2006/protected/p/12579271.html的协程继续探究。

在上一次的理论中提到了协程上下文Coroutine Context，其实所有的协程构建器(coroutine builder)如launch和async都会接收一个可选的CoroutineContext参数，该参数可用于显式指定新协程所运行的分发器以及其它上下文元素。咱们来看一下程序：

也就是我们可以指定其它的上下文分发器，接下来再来看一下async()：

协程分发器：

首先咱们先编写个例子：

而launch它不是第一个参数是可以接收一个协程上下文么？所以咱们手动指定一下：

呃，不是要接收的是一个协程上下文类型么？咋传的是一个分发器呢？其实它也是一个上下文：

它的类型是一个Unconfined，那它是不是协程上下文类型呢，看一下它的层次继承体系既可：

 

嗯，接下来继续编写代码：

最后再来修改，对于协程我们知道它是运行在指定线程里面的，那能否指定某个线程来作为协程的分发器呢？答案是可以的，这里可以将线程池设置成协程的分发器，如下：

看下错误提示：

这里需要的是一个协程上下文类型，而很明显线程池用的是Java的方式不可能是Kotlin需要的协程上下文类型的，所以此时扩展方法则又会发生效能了：

所以代码修改如下：

也就是看一下每一个协程线程的运行情况，运行：

下面对于上面的程序进行一个解析：

1、当通过launch来启动协程并且不指定协程分发器时，它会继续启动它的那个CoroutineScope的上下文与分发器。对于该示例来说，它会继承runBlocing的上下文，而runBlocking则是运行在main线程当中。

2、Dispatchers.Unconfined是一种很特殊的协程分发器，它在该示例中也是运行在main线程中，但实际上，其运行机制与不指定协程分发器时是完全不同的。【在日常的开发中使用较少】

注意了！！如之前我们所解读的对于这个Unconfied的协程分发器它是不会局限于某一个特定的线程的：

那目前由于这个launch就是运行在main()线程当中，而输了也如预期是在main线程，不就是局限于某个线程，跟官方说的有点出入？其实不是这样的，这里只能说是凑巧而已，如果修改一下代码则运行结果又不一样了，如下：

也就是符合官网的解释了，不会局限于某个特定的线程了，那再来修改一下：

关于这块的原理剖析放下次继续。