5、AsyncTool框架竟然有缺陷？

前言

本文是专栏《AsyncTool框架原理源码解析》系列的最后一篇文章 《AsyncTool框架竟然有缺陷？》，源码学习的过程当中，发现了AsyncTool框架的一个缺陷，并且针对缺陷给AsyncTool框架贡献了源码。算是对本专栏《AsyncTool框架原理源码解析》画上了一个圆满的句号吧。

专栏《AsyncTool框架原理源码解析》共有 5篇 文章，由浅入深，从实战使用再到源码、原理分析，包括但不仅局限于AsyncTool框架思考和总结，最后分享下我为AsyncTool框架开源项目贡献代码。以下是《专栏目录》：

1. 《AsyncTool框架简介和分析实现》
2. 《AsyncTool框架实战使用》
3. 《AsyncTool框架原理源码解析》
4. 《AsyncTool框架的一些思考》
5. 《AsyncTool框架竟然有缺陷？》

---

问题现场

在源码debug过程中，发现如果一个任务有多个依赖的情况，源码的处理稍有问题。

当有多个依赖任务时，任务得逻辑可以进行优化：

1、示例场景：A,B,C,D下一节点是F，即F依赖A,B,C,D

2、调用流程：**A,B,C,D共同开始work；每个任务调用fire()方法执行完自己以后都调用beginNext()方法执行F；

3、问题出现的过程：执行F时，因F有多个依赖会进入到doDependsJobs()方法；
因为这个方法是由synchronized修饰的，同一时刻，fromWrapper：A,B,C,D只会有1个获取到锁，进入到这个方法里；

public synchronized void doDependsJobs(ExecutorService executorService, List<DependWrapper> dependWrappers, WorkerWrapper fromWrapper, long now, long remainTime)

（1）假设B先拿到锁，进入doDependsJobs()，之后通过“ 一些列的内存及CPU判断逻辑 ”，再调用fire()执行F，以及beginNext()执行F的后续任务；
（2）当除了B以外的其他任务再进入到doDependsJobs()时， F已经执行完了，此时没有必要再进行“任何逻辑操作了” ，F及F后的后续链路已经执行了；

4、问题及解决办法：如上描述，B触发F执行完后，A，C，D任务再进入doDependsJobs()时，没有必要再做内存及CPU的判断逻辑了，直接return即可。

5、图文说明：

6、如何优化的？
进入doDependsJobs()前判断一下当前任务的状态即可。如下：

针对以上问题，以提交issue，并且提交了pull request。如下：

1. issue链接
2. pull request链接

2022/06/13 更新
针对问题的修复，现在已经被作者合并到master分支了，尽管只有3行代码。
虽然问题很小，但发现并解决的过程是美好的，。🤓🤓🤓🤓🤓🤓

---

🎉 如果喜欢这篇文章，请不要吝啬你的赞👍👍👍哦，创作不易，感谢！