Activiti 6.0 系列写到第六篇这一篇专门聊并行网关。工作流里最常见的场景就是“一个任务拆成多个子任务同时分给不同的人处理全部完成后再继续往下走”。比如采购申请要同时让财务、法务、技术三个部门会签三个部门都在自己权限内并行处理全部同意之后流程才进入下一节点。用代码硬写这种逻辑很痛苦但用流程引擎本身就简单很多——这就是并行网关Parallel Gateway的核心价值。我最初接触并行网关时总把它想复杂了以为它和代码里的多线程、并发控制有什么深层关系。实际用下来发现并行网关只是流程定义层面的一个“分流汇合标记”它不负责真正开线程所有并行分支仍然由引擎以同步方式推进。搞清楚这个认知后面很多问题就都会迎刃而解。1. 并行网关的核心原理与运行机制1.1 并行网关到底帮我们做了什么并行网关在 BPMN 规范里也叫“并行分叉网关”它做的事情用两句话就能概括分叉时把所有出口都激活汇合时等所有入口都到齐。分叉Fork场景是这样流程走到并行网关时引擎会查看这个网关后面连了几条顺序流。排他网关是“选了这条就不走那条”并行网关恰恰相反——它不做任何条件判断每一条出口顺序流都会被激活生成对应的执行实例Execution。也就是说5 条出口就会生成 5 个并行执行分支每个分支都从自己的后继节点继续运行。汇合Join场景是这样并行网关作为汇合节点时引擎会统计有几条入口顺序流。每来一个分支引擎就记录一次等到所有入口顺序流对应的分支都到达了它才把流程继续向后推动。如果只来了其中一部分流程就卡在网关这里表现为流程实例停留在“等待”状态。这里有一个关键的运行细节汇合时并行网关会“吞掉”先到的分支。比如 3 条入口顺序流第一条先到达后引擎不会让流程实例做出任何推进动作只是内部记录“已到达 1/3”直到第 3 条也到了它才合并所有分支数据生成一个后续执行实例并继续流转。这个特性直接导致了后面要讲的“死锁”问题。1.2 从 BPMN 文件看并行网关的真实面目用 Activiti 6.0 建模时并行网关在 BPMN XML 里的表现形式如下parallelGateway idforkGateway name并行分叉 / parallelGateway idjoinGateway name并行汇合 /分叉网关和汇合网关本质上用的是同一个标签它们在流程定义里是“成对”出现的。一个并行网关既可以做分叉也可以做汇合完全取决于它在流程里的位置和连线的方向。官方建模工具里通常用菱形加加号图标来表示菱形加 X 是排他网关菱形加 O 是包容网关加号就是并行网关——这个图形差异记住就不会选错。流程流转时并行网关并不知道自己下游要等哪些节点它只看“出口顺序流”。所以如果你建少了连线或者连线的 targetRef 写错了并行分支数就会和预期不一致。实际项目的流程定义我建议直接在 XML 源码里审查图形界面拉完线之后经常存在视觉上的“看似相连、实际没连上”的情况。2. 并行网关和排他、包容网关的选型差异2.1 三种网关的核心区别对比很多初学者在建模时拿不准该用哪种网关。我把最常见的三种网关放在一起对比看完基本就清楚了网关类型分叉策略汇合策略典型场景排他网关只走第一个满足条件的分支只要有任意一个分支到达就继续流转审批通过/驳回、金额分档处理并行网关所有出口分支全部激活必须等全部分支都到达会签、并行任务、多部门同时审批包容网关激活所有满足条件的分支满足条件的分支全部到达才会继续部分会签、有条件的并行处理排他网关处理的是“多选一”的问题并行网关处理的是“全选”的问题包容网关则是“选部分”的问题。业务上如果有“同时要多人审批”的需求那就是并行网关如果是“只要有一方通过就行”那是排他或者包容网关。2.2 实际业务里如何快速判断我之前接手过一个财务报销流程产品经理最初画的图是“部门负责人审批、财务复核、出纳付款”三个节点串行。后来业务要求改成“负责人审批通过后财务和出纳同时处理”这里就出现了并行需求。最初团队成员想用排他网关加两个条件表达式来模拟结果流程怎么跑都不对原因就在于排他网关只会走其中一个分支。判断标准就一条这些分支任务是不是“都必须完成且彼此没有先后要求”。只要答案是“是”就闭眼用并行网关。另外有个细节值得提醒并行网关的多个分支之间并不要求“同时发生”它只要求“最终都要到达汇合网关”。所以分支里有一个节点审批特别慢其他快的分支到了汇合点也只能先等着这是正常现象不是引擎卡住了。3. 从流程建模到跑通一次完整并行流转3.1 第一步设计一份可运行的流程定义我先给出一份最基础的并行网关流程定义。它包含一个开始事件、一个用户任务、一个并行分叉网关、两个并行用户任务、一个并行汇合网关和一个结束事件。这份定义我建议直接拿去测试跑通了再改造。?xml version1.0 encodingUTF-8? definitions xmlnshttp://www.omg.org/spec/BPMN/20100524/MODEL xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:activitihttp://activiti.org/bpmn targetNamespacehttp://www.activiti.org/test process idparallelProcess name并行网关测试流程 isExecutabletrue startEvent idstartEvent name开始 / userTask idinitiateTask name发起申请 activiti:assignee${initiator} / parallelGateway idforkGateway name分叉 / userTask idtaskA name任务A activiti:assigneeuserA / userTask idtaskB name任务B activiti:assigneeuserB / parallelGateway idjoinGateway name汇合 / endEvent idendEvent name结束 / sequenceFlow idflow1 sourceRefstartEvent targetRefinitiateTask / sequenceFlow idflow2 sourceRefinitiateTask targetRefforkGateway / sequenceFlow idflow3 sourceRefforkGateway targetReftaskA / sequenceFlow idflow4 sourceRefforkGateway targetReftaskB / sequenceFlow idflow5 sourceReftaskA targetRefjoinGateway / sequenceFlow idflow6 sourceReftaskB targetRefjoinGateway / sequenceFlow idflow7 sourceRefjoinGateway targetRefendEvent / /process /definitions注意一个基础但容易犯错的点BPMN 文件里的activiti:assignee我绑的是固定值userA、userB这只是测试用。真实项目中建议绑变量比如${assigneeA}、${assigneeB}否则任务分配写死会让后续流程复用非常痛苦。3.2 第二步部署流程并启动实例部署和启动代码用 Activiti 6.0 的 API 可以这样写// 部署流程 repositoryService.createDeployment() .addClasspathResource(parallel-process.bpmn20.xml) .name(并行网关测试流程) .deploy(); // 启动流程实例 MapString, Object variables new HashMap(); variables.put(initiator, zhangsan); ProcessInstance processInstance runtimeService.startProcessInstanceByKey(parallelProcess, variables);启动后查询任务列表你会发现一个有意思的现象流程不会自动走到分叉网关后面的任务A和任务B而是先停在“发起申请”节点。这是 Activiti 的正常机制——用户任务需要人工触发 complete 之后流程才会继续推进到下一个节点。3.3 第三步完成任务并验证并行分支模拟发起人完成“发起申请”任务// 查询发起人的任务 ListTask tasks taskService.createTaskQuery() .processInstanceId(processInstance.getId()) .taskAssignee(zhangsan) .list(); // 完成该任务 for (Task task : tasks) { taskService.complete(task.getId()); }完成之后再查一次所有任务ListTask currentTasks taskService.createTaskQuery() .processInstanceId(processInstance.getId()) .list(); for (Task task : currentTasks) { System.out.println(当前任务节点: task.getName() 办理人: task.getAssignee()); }打印结果应该是两条任务记录任务A办理人 userA和任务B办理人 userB。这一步就是并行网关分叉生效的直接证明——一个前置任务完成后同时产生两个独立的任务实例。两个任务相互独立谁先完成都不影响对方。3.4 第四步逐个完成并行分支观察汇合行为现在分别完成这两个任务。先完成任务A再查流程状态taskService.complete(taskA.getId());此时任务B还存在而且流程实例没有走到下一步这说明汇合网关还在等待任务B。等任务B也完成后流程才会走到结束事件taskService.complete(taskB.getId()); // 查询历史确认流程是否结束 HistoricProcessInstance historic historyService.createHistoricProcessInstanceQuery() .processInstanceId(processInstance.getId()) .singleResult(); System.out.println(流程结束时间: historic.getEndTime());如果打印出的 endTime 不为空说明整个流程已经正常走完。这个过程中我特别建议你关注一下ACT_RU_EXECUTION表的数据变化。完成发起申请后这张表里会多出两个并行执行实例它们的PARENT_ID_指向同一个父执行汇合完成后并行子执行全部消失只剩一个主执行继续向下走。理解这张表的变化比死记网关概念有用得多。4. 实际案例并行网关实现多角色会签4.1 会签场景的需求梳理前面举的流程还是太简单了真正最能体现并行网关价值的是“会签”场景。我拿一个最典型的需求拆解业务背景某公司采购设备金额超过 50 万时需要技术总监、财务总监、法务总监三人同时审批。三者并行处理互不依赖但必须全部审批通过合同才能进入用印环节。建模思路很简单发起人提交申请后接一个并行网关分叉到技术审批、财务审批、法务审批三个用户任务再汇合到合同用印节点。有人会问这不是和前面两个分支的例子一样吗区别在于真实业务里每个会签节点不是“完成”就行而是要有“同意/驳回”的表单数据而且如果任意一个人驳回了整个流程要能提前终止。后半句话就涉及到一个并行网关的常见改造方案。4.2 带驳回逻辑的会签设计严格讲纯并行网关不支持“提前终止”这种逻辑。你可以在汇合网关之后加一个排他网关判断所有会签结果里是否有“驳回”。但问题是如果所有分支都等到汇合才判断其中一个审批人驳回了其他两个人还是要把流程走完——这在真实办公场景里效率太低。常用的方案是用事件子流程配合消息中间件来打断并行分支或者简化业务规则把“驳回”也视为一种“完成”最后在汇合后的排他网关上统一判断。折中后的设计是流程走向发起申请 - 并行分叉 - 技术审批/财务审批/法务审批 - 并行汇合 - 排他网关判断结果 - 通过则合同用印驳回则退回修改。实现上每个会签节点的表单里带一个布尔变量比如techApprove、financeApprove、legalApprove。汇合之后用 EL 表达式判断exclusiveGateway idjudgeGateway name会签结果判断 / sequenceFlow idapproveFlow sourceRefjudgeGateway targetRefcontractSeal conditionExpression xsi:typetFormalExpression ![CDATA[${techApprove true financeApprove true legalApprove true}]] /conditionExpression /sequenceFlow sequenceFlow idrejectFlow sourceRefjudgeGateway targetRefmodifyTask conditionExpression xsi:typetFormalExpression ![CDATA[${techApprove false || financeApprove false || legalApprove false}]] /conditionExpression /sequenceFlow完整完成任务时记得把审批结果存入流程变量MapString, Object vars new HashMap(); vars.put(techApprove, true); taskService.complete(taskId, vars);这种设计的好处是流程定义简单所有会签结果都在汇合后统一处理代价是驳回场景下并行分支要全部走完。如果你的业务流程允许建议把“驳回”设计成“不通过也会走到汇合”避免引入复杂的终止子流程。等流程跑稳定了再考虑用事件子流程做超时未处理之类的增强。4.3 会签任务实现时的参数传递经验会签场景最容易踩的坑是变量覆盖。多个并行分支操作同一个流程实例时如果用的是runtimeService.setVariable()各分支间会互相覆盖数据。我推荐的做法是先拿到当前任务对应的 executionId用taskService.complete()传局部变量。这样每个分支的审批结果都挂在各自的执行实例上汇合后引擎会将所有子执行的变量合并到主执行上。这里有个细节汇合时多个并行子执行如果都设置了同名变量后到达的会覆盖先到达的。所以我在设计变量名时就刻意区分了techApprove、financeApprove、legalApprove而不是统一叫approve——这就是实战经验设计变量时留个心眼能为后续省掉大量排错时间。5. 常见问题与排查技巧实录5.1 流程走到并行网关后卡住不动这是使用并行网关最常遇到的问题。现象是流程实例显示在网关节点但所有任务都查询不到流程也不继续走。排查思路按下面三步走基本能定位第一步查ACT_RU_EXECUTION表看有多少条执行实例它们的ACT_ID_是什么。第二步查ACT_RU_TASK表看是否存在等待中的任务。第三步对照 BPMN XML 检查连线关系。最常见的原因是分叉网关和汇合网关没有正确配对。比如你建了三条并行分支但汇合网关只画了两条入口连线其中一个分支直接绕过汇合网关连到了后面的节点这样不仅会产生错误的分支行为甚至可能直接报错。遇到这种情况直接在源码里数每一个网关的 outgoing/ incoming 数量一眼就能看出问题。还有一种隐蔽情况某个并行分支上的用户任务没有设置办理人导致任务创建后没有 assignee但你按 assignee 查询时自然查不到。用taskQuery().processInstanceId(...).list()不带任何过滤条件就能看到这类“无主任务”。5.2 并行网关分支只走了一条现象是分叉网关之后只有一个任务被创建另一个分支没有任何反应。这种情况基本不是网关问题而是分支连线写错了。最常见的低级错误是两条分支连到了同一个目标任务上或者分叉网关的其中一条出口不是指向用户任务而是直接指向了汇合网关。XML 里检查一下之后其实很容易看出问题。另外还有一种可能你用了并行网关代码里却混用了runtimeService.createProcessInstanceQuery()只查了主执行分支没查子执行。并行分支的任务本来就在子执行上代码过滤条件如果限制得太死就会误以为分支没创建。5.3 并行网关和多人审批的区别这点值得单独拿出来说因为很多人在群里问过类似问题任务需要多个人处理是不是就该用并行网关我明确回答不是。并行网关解决的是“多个不同任务同时处理”的问题如果一个任务本身要多人办理且办理人之间互相可见、任意一人完成后任务就结束那应该用用户任务的多人办理配置比如activiti:assignee配合候选人组而不是并行网关。如果你要给同一个任务配置“多人会签”每人都必须审批、全部通过才流转在 Activiti 6.0 里通常用多实例Multi-instance子元素配合并行网关实现或者直接给用户任务加activiti:collection和activiti:elementVariable做多实例循环。简而言之并行网关控制的是流程的“形状”多实例控制的是单个任务上的“人数”两个概念不要混为一谈。5.4 并行网关死锁的典型案例关于“死锁”我再展开讲一个真实案例。某次我在一个模拟项目里给流程只加了分叉网关忘记在最后加汇合网关而是让两个分支的末端分别连向了两个不同的结束事件。这种流程定义能部署、能启动分叉也正常但流程结束后查看历史会发现留下了两个不相干的执行记录而且业务上无法确定“流程是否真正跑完”。更严重的死锁场景是分叉网关后有两个分支分支A最终会流到汇合网关分支B却流到了结束事件。这时分支B先到汇合点等待而分支A已经到结束事件永远不会再到汇合点流程实例就永久卡死了。这种问题在 BPMN 建模工具里不容易发现我建议每画完一个并行网关都手动检查一下所有分支最终是否都汇合到同一个节点——这也是我在项目中把它列为流程评审必检项的原因。6. 并行网关实操中的几个避坑建议6.1 流程定义阶段建议在 XML 源码层面做 review图形化建模工具给人很强的误导性——线连没连上看不清网关类型图标容易混淆。尤其是并行网关和包容网关在工具里的图标相似度很高选错了一个流程就跑飞。我实操的习惯是每次在工具里画完流程图都要打开 XML 源码逐个检查parallelGateway节点的outgoing数量。分叉网关的 outgoing 数量等于分支数汇合网关的 incoming 数量也等于分支数这个核对方法简单且可靠。6.2 关于流程变量的作用域并行分支上的任务变量默认是子执行实例级别汇合后统一合并到主执行实例。这意味着你在任意一个分支里设置了变量汇合后流程后续节点都能读取。但有一个坑如果并行分支里调用了 Java 服务任务或脚本任务它们对变量的修改可能在汇合时发生冲突。稳妥的做法是让每个分支写不同的变量名绝对避免不同分支同时写同一个变量名。6.3 合理利用历史表来验证流程模型并行网关相关的问题在运行期看运行时表只能看到“当前状态”要看到全流程的走向必须结合历史表。我常用的一条 SQL 是SELECT * FROM ACT_HI_ACTINST WHERE PROC_INST_ID_ ? ORDER BY START_TIME_;这条 SQL 能把流程实例经过的所有节点按时间列出来。如果预期是“发起 - 分叉 - 任务A/任务B - 汇合 - 结束”而实际记录里缺少了某个节点或者顺序反了对照这张表就可以快速确认模型哪一步出了问题。6.4 避免在并行网关后面直接挂脚本任务并行网关分叉后直接挂 Java 服务任务或脚本任务引擎会同步执行这些分支并不会真正开多线程并行。如果一个分支里的服务任务执行时间很长它会阻塞其他分支的推进吗不会。引擎是逐个将每个分支的执行实例放入命令上下文处理的但从调用方的视角看所有分支会在同一个事务提交后全部完成。如果你的服务任务里有远程调用、网络IO、重量级计算建议在服务任务里自己做异步化否则整个流程的“并行”只是逻辑上的并行执行时仍然会占用引擎线程影响其他流程实例的处理速度。7. 写在最后的一点体会并行网关是我在实际开发中用得最多的一种网关它的逻辑简单、表现稳定但正因为简单很多人反而不重视建模细节。我见过太多“生产环境流程跑一半卡死”的案例最终排查下来不是引擎问题而是流程图本身画错了——要么汇合网关漏了连线要么分支上挂了“永不结束”的子流程。我个人建议每一个刚接触 Activiti 的人都先用最简单的流程定义把并行网关的分叉、汇合、变量传递、历史记录完整跑一遍亲眼看一下ACT_RU_EXECUTION表的变化遇到问题再去查文档会顺手很多。后续如果业务复杂度上来了再去了解多实例、事件子流程这些进阶玩法——它们的底层很多思路都建立在并行网关之上。