Phaser不参与Activiti流程状态变更，仅协调同实例内多个异步子任务的阶段性执行节奏，如并行网关后的ServiceTask按“校验→通知→归档”阶段对齐汇合，其作用限于JVM内任务节奏控制，不可替代Redis等分布式锁保障数据一致性。
Phaser 在 Activiti 多分支节点异步切换中不直接参与流程状态变更，也不替代 Activiti 自身的事务与锁机制；它的作用是**协调同一流程实例内多个自定义异步子任务的阶段性执行节奏**，比如并行网关（Parallel Gateway）后启动的若干 ServiceTask（标记 async="true"），确保它们在业务逻辑层面按阶段对齐、有序汇合，而非解决数据库并发冲突。
明确适用边界：Phaser 管的是“任务节奏”，不是“数据一致性”
Activiti 的多分支异步切换本质是：流程引擎将一个流程实例拆分为多个 Execution 或 Task，交由线程池（如 Spring 的 TaskExecutor）异步执行。此时真正的并发风险来自：
- 多个线程同时调用
runtimeService.setVariable("orderStatus", "processed")—— 变量覆盖 - 多个线程争抢完成同一个用户任务（
taskService.complete(taskId)）—— 乐观锁异常 - 多个异步作业（
ACT_RU_JOB）被重复触发执行 —— 业务逻辑重复
这些问题必须靠 以 processInstanceId 为粒度的分布式锁（如 Redis 锁） 来防护，Phaser 无法也无需介入。它只适用于：你已在委托类（JavaDelegate）或监听器中封装了安全的变量操作，但仍需控制多个子任务的执行阶段（例如“全部校验完成 → 统一发通知 → 批量归档”）。
典型场景：并行校验 + 阶段汇合
假设一个订单审批流程，在并行网关后启动 3 个异步校验任务（信用、库存、风控），每个校验结果需写入流程变量，最后由汇总节点统一判断是否通过。这时可这样用 Phaser：
立即学习“Java免费学习笔记（深入）”；
- 主线程（如
ExecutionListener.onEnd）创建一个Phaser phaser = new Phaser()，并将其作为上下文传入各子任务 - 每个校验委托类启动时调
phaser.register()，表示“我将参与本次三阶段协作” - 校验完成后，调
phaser.arriveAndDeregister()—— 该任务退出，不再参与后续阶段 - 当所有校验完成，phaser 进入 phase=1；此时可由一个专用汇总线程（或主线程 awaitAdvance(0) 后触发）读取全部变量，执行通知逻辑
- 通知发送完毕，再调一次
phaser.arriveAndDeregister()（若该线程也注册过），推进到 phase=2，触发归档动作
关键实践要点
避免把 Phaser 当成“全局锁”或“流程锁”来用：
- 每个流程实例独享一个 Phaser 实例，不能复用或跨实例共享，否则阶段语义混乱
-
Phaser 生命周期应与流程实例绑定：可在流程启动时创建，存入
execution.getProcessInstance().getId()对应的缓存（如ConcurrentHashMap<String, Phaser>），流程结束时调phaser.forceTermination()清理 -
绝不在线程池 submit() 中裸调 Phaser：必须封装为
TaskWrapper，统一处理 register/arrive/deregister，防止遗漏或重复调用 -
onAdvance() 仅做轻量钩子：比如记录“phase=1 完成，共3个校验任务”，不要在里面调用
runtimeService或远程接口
为什么不推荐用 Phaser 替代分布式锁？
因为 Phaser 是 JVM 内存级同步工具，不具备跨进程可见性。在集群部署下，Activiti 的多个节点可能同时处理同一流程实例的不同分支 —— 此时一个节点上的 Phaser 对另一个节点完全不可见，根本起不到协调作用。而 Redis 锁或数据库行锁能保证所有节点看到同一把锁，这才是保障数据一致性的正解。
