开篇之作
（1） 描述
两条或更多的分支合并到单一的一条后续路径中，每一条使能进入分支都激活后续路径的一次执行线程。虽然多条分支在图形上是合并的，但是这个多路合并并不对这些分支激活的后续线程进行任何的同步。
（2） 抽象模型描述
多路合并的Flash动画
上图中，B和C是多路选择后的分支，这样的分支可以超过两个，假设还有E、F……，这样的分支在多路选择处不进行同步，每一个分支都会激活一次D的执行，即D（B）、D（C）、D（E）……，并且这些D的线程互不干扰。
（3） 业务场景举例
报销流程，假设分为三部分：住宿费、交通费、飞机票特殊报销。可能出现的情况有：住宿费+交通费；住宿费+交通费+飞机票特殊报销；交通费；交通费+飞机票特殊报销……
流程开始，首先填写报销申请（勾选报销的内容，三种费用中选择），之后流程根据勾选的内容激活后续的填写不同报销单的分支，最后每一张报销单都需要经过审批。
如果流程引擎没有实现多路合并我们可以变相的实现上面的功能。如下图：
但上述的实现有以下的不足：
a、 重复工作量，审批分明是同一个活动，非要分多个来画；
b、 无法进行统计，若要对审批这一活动的时间、数量等信息进行统计分析，那么分成了多个活动后就难于进行统计。
c、 资源的分配，假设审批是由一个岗位来负责，且任务压力应该在这个岗位上负载均衡，那么分成了多个活动后这个资源的分配也无从着手。
（4） 含义引申
多路合并的后续路径，是一些相同行为的执行线程，这就类似于另外一种模式——多实例模式。这些线程终有一个需要同步的时候，在业务场景中，这个同步就非常的复杂，如后续步骤为制证，这种业务可以分为以下情况，我们一一举例说明：
a、 强制一对一：一个审批后的单据生成一个财务凭证，那么这些多实例的线程暂时不同步，留到后续步骤。这种管理方式是比较常见的。
b、 强制多对一：同一个报销申请产生的报销单据，需要生成在一个财务凭证上。因此在制证前就需要同步。这种管理方式是比较常见的。
c、 任意多对多：在本场景中，这个不太可能发生，但在一般的物流业务中却非常常见。假设飞机票的审批比较严格，拖得时间比较长，另外两个报销单早批了，那么先将这两个生成同一个财务凭证。这种任意性的规则，一般都是通过人来判断的。
