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类型。本文着重讲解以下几个方法：
- start
- cancel
- 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建立树形关系
我们关注上面类图标红的几个类。
划重点
- ChildHandle的childCancelled表示子Job被取消时，往上传播
- CompletionHandler的invoke方法表示父Job被取消时执行子Job的回调，往下传播，最终会调用到ChildJob的parentCancelled方法
- ChildHandleNode同时实现了ChildHandle和CompletionHandler，表示该节点可以双向传播
核心方法有：
- JobSupport.initParentJobInternal(parent: Job?)
- Job.attachChild(child: ChildJob): ChildHandle
- 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事件的
