1. 协程的结构化并发

上篇文章，我通过两个例子简单的介绍了Job cancel方法在不同的父子关系情况下，看起来很相似的代码，执行结果却很不相同的情况。文中我引出了Job结构化并发的概念，即父Job和子Job形成树的数据结构，本文我将详细介绍Kotlin协程框架是如何实现结构化并发的。

什么叫结构化并发？用通俗易懂的话解释就是，协程之间的协作是有组织，有纪律的。如果协程之间的关系是确定了的，那么协程之间的cancel和exception处理是有章法可寻的。

下图，假设Job2处发生了异常，那么它的子Job、父Job以及父Job的其它子Job是否会被cancel掉呢？答案是看情况（不是说有章法可寻吗？怎么成看情况了？因为算法是固定的，但是Job的行为可能各不相同）。在树的数据结构中，任何一个节点的cancel事件有两条传播路径，向上传播给父节点，向下传播给子节点。那么接受到cancel事件的父节点或子节点是否cancel掉自己完全取决于它的内部实现。

举例说明，假设Job2处发生异常了协程被迫cancel掉，事件传播到Job0。那么Job0会有两种处理方式。其一、把自己也cancel掉，然后把自己的所有子Job都cancel掉，其二、忽略掉该事件，当作啥事也没发生。

熟悉协程的同学应该能意识到，这两种处理方式分别对应Job和SupervisorJob。

1.1 Job处理异常

job2处1/0发生异常打印结果如下，我们注意到通过Job方式启动，随着job2发生异常，job1和job3都被cancel掉。

2021-12-19 16:35:52.439  job1 start
2021-12-19 16:35:52.440  job2 start
2021-12-19 16:35:52.440  job3 start

1.2 SupervisorJob处理异常

打印结果如下，job1和job3不受job2的异常影响，程序照常执行。

2021-12-19 16:44:30.832  job1 start
2021-12-19 16:44:30.833  job2 start
2021-12-19 16:44:30.833  job3 start
2021-12-19 16:44:32.835  job1 end
2021-12-19 16:44:32.835  job3 end

那么问题来了：为什么SupervisorJob和Job会有这样的差异呢？

2. Job基础知识

通过CoroutineScope.launch方法启动协程，返回值为Job类型。本文着重讲解以下几个方法：

1. start
2. cancel
3. invokeOnCompletion

2.1 start方法

start方法作用是启动一个协程，类似Thread.start方法。通过默认的方式启动协程，start方法会默认被调用的。

2.2 cancel方法

cancel方法作用是取消协程，避免资源的浪费，Android开发者比较熟悉的场景有，当一个Activity销毁之后，应该取消掉还没有执行完的工作。协程中的cancel，必须要有挂起点。

2.2.1 使用delay方法

观察日志由于delay方法是suspend修饰的，它是协程的挂起点，发现job1被成功cancel掉。

2021-12-19 17:16:16.377  running in job2

2.2.2 使用Thread.sleep方法观察发现，job1协程体没有调用suspend修饰的方法，无法被cancel掉，job1

2021-12-19 17:26:05.554  running in job2
2021-12-19 17:26:06.544  running in job1

2.2.3 通过yield或者ensureActive方法更正

在Thread.sleep方法后面增加yield或者ensureActive方法，可以让job1被cancel掉。yield本身是一个suspend函数，在yield方法处恢复协程体运行时，会检查当前协程是否被cancel掉。ensureActive则是通过抛出CancellationException取消掉当前的协程。

2.2.4 CancellationException是一种特殊的Exception，它和Exception的区别在于，如果在协程中抛出CancellationException，除了子协程外并不会影响其它协程

对比1.1代码1/0抛出除0异常，CancellationException并不会影响job1和job3。

2021-12-19 19:08:46.558  job1 start
2021-12-19 19:08:46.559  job2 start
2021-12-19 19:08:46.561  job3 start
2021-12-19 19:08:46.626  job4 start
2021-12-19 19:08:48.560  job1 end
2021-12-19 19:08:48.561  job3 end

2.3 invokeOnCompletion方法

该方法的作用是给Job注册一个回调，当Job执行完成后执行回调函数。

2021-12-19 19:19:39.278  job start 2021-12-19 19:19:41.280  job end 2021-12-19 19:19:41.281  job invokeOnCompletion

当协程被cancel时，回调立马执行。

2021-12-19 19:34:21.809  job start
2021-12-19 19:34:22.811  job invokeOnCompletion

我们来看下invokeOnCompletion源码

CompletionHandler类似Java中的callback，当Job完成后，调用该回调，类似Android的OnClickListener。CompletionHandler持有ChildJob，并注册到父Job上，那么子Job就可以监听父Job的取消和完成事件，从而实现事件从上往下传播。如果子Job能够直接或间接的持有父Job的引用，那么当子Job被cancel时，就能直接把事件，从下往上传播。所以cancel事件是双向传播的

而协程框架也正是通过invokeOnCompletion方法建立起父子Job的树形关系

3. Job建立树形关系

我们关注上面类图标红的几个类。

划重点

1. ChildHandle的childCancelled表示子Job被取消时，往上传播
2. CompletionHandler的invoke方法表示父Job被取消时执行子Job的回调，往下传播，最终会调用到ChildJob的parentCancelled方法
3. ChildHandleNode同时实现了ChildHandle和CompletionHandler，表示该节点可以双向传播

核心方法有：

1. JobSupport.initParentJobInternal(parent: Job?)
2. Job.attachChild(child: ChildJob): ChildHandle
3. JobSupport.invokeOnCompletion( onCancelling: Boolean, invokeImmediately: Boolean, handler: CompletionHandler )

划重点->通过CompletionHandler生成JobNode设置到父Job的state属性中，state属性有NodeList链表，用来保存回调列表

1处，如果当前只有一个CompletionHandler，则直接保存到state中

2处，如果当前有两个CompletionHandler则将state属性提升成链表

3处，如果当前大于2个CompletionHandler，则直接将该CompletionHandler添加到链表的尾部。

PS这块代码看起来比较复杂，写起来也比较费劲，初次接触肯定云里雾里，时间有限先写到这里吧。以后时间允许再详细写写

总而言之

1. Job通过state的NodeList对象与子Job建立关系，当Job被取消时通过这个链条向子Job发送取消请求

2. Job通过initParentJobInternal方法中获取到的parentHandle与父Job建立关系，当子Job被取消时通过该引用向父Job发送取消请求

3. 协程Job中的双向传播机制是协程框架算法决定的。当取消请求到达具体的Job时，Job如何处理则由Job实现类自己决定

4. 本文讲解了Job是如何建立关系的。下篇文章我将结合Job，SupervisorJob，coroutineScope，supervisorScope讲解他们在关系链路上如何处理双向cancel事件的