并发场景可能存在的需求之——任意编排
1 多个执行单元的串行请求
2 多个执行单元的并行请求
3 阻塞等待，串行的后面跟多个并行
4 阻塞等待，多个并行的执行完毕后才执行某个
5 串并行相互依赖
6 复杂场景
并发场景可能存在的需求之——每个执行结果的回调
传统的Future、CompleteableFuture一定程度上可以完成任务编排，并可以把结果传递到下一个任务。如CompletableFuture有then方法，但是却无法做到对每一个执行单元的回调。譬如A执行完毕成功了，后面是B，我希望A在执行完后就有个回调结果，方便我监控当前的执行状况，或者打个日志什么的。失败了，我也可以记录个异常信息什么的。
此时，传统的就无能为力了。
我的框架提供了这样的回调功能。并且，如果执行失败、超时，可以在定义这个执行单元时就设定默认值。
并发场景可能存在的需求之——执行顺序的强依赖和弱依赖
如上图的3，A和B并发执行，最后是C。
有些场景下，我们希望A和B都执行完毕后，才能执行C，CompletableFuture里有个allOf(futures...).then()方法可以做到。
有些场景下，我们希望A或者B任何一个执行完毕，就执行C，CompletableFuture里有个anyOf(futures...).then()方法可以做到。
我的框架同样提供了类似的功能，通过设定wrapper里的addDepend依赖时，可以指定依赖的任务是否must执行完毕。如果依赖的是must要执行的，那么就一定会等待所有的must依赖项全执行完毕，才执行自己。
如果依赖的都不是must，那么就可以任意一个依赖项执行完毕，就可以执行自己了。
并发场景可能存在的需求之——依赖上游的执行结果作为入参
譬如A-B-C三个执行单元，A的入参是String，出参是int，B呢它需要用A的结果作为自己的入参。也就是说A、B并不是独立的，而是有结果依赖关系的。
在A执行完毕之前，B是取不到结果的，只是知道A的结果类型。
那么，我的框架也支持这样的场景。可以在编排时，就取A的结果包装类，作为B的入参。虽然此时尚未执行，必然是空，但可以保证A执行完毕后，B的入参会被赋值。
并发场景可能存在的需求之——全组任务的超时
一组任务，虽然内部的各个执行单元的时间不可控，但是我可以控制全组的执行时间不超过某个值。通过设置timeOut，来控制全组的执行阈值。
并发场景可能存在的需求之——高性能、低线程数
该框架全程无锁，没有一个加锁的地方。
创建线程量少。
如这样的，A会运行在B、C执行更慢的那个单元的线程上，而不会额外创建线程。
总结
该并发框架提供
> 1 提供任何形式的串行、并行执行单元的组合。如a、b、c的串行，a、b的串行同时与c并行，a、b、c的并行
> 2 为每个执行单元提供执行成功、失败、超时、异常的回调
> 3 支持为单个执行单元设置异常、失败后的默认值
> 4 支持为整个group（多个任意组合的执行单元）设置超时时间。单个执行单元失败，不影响其他单元的回调和最终结果获取。如果自己依赖的任务失败，则自己也立刻失败。
> 5 整个group执行完毕或超时后，同步阻塞返回所有执行单元结果集，按添加的顺序返回list。也支持整个group的异步回调不阻塞主线程
> 6 支持每个group独享线程池，或所有group共享线程池（默认）
该并发框架已开源，https://gitee.com/tianyalei/asyncTool
标签：多线程,组合,依赖,并发,场景,线程,执行,任意,单元 From： https://blog.51cto.com/u_13706148/6038481