Phaser不是一致性算法，仅是单机多线程同步屏障；它缺乏网络通信、持久化、多数派投票等Paxos/Raft必需能力，只能用于教学模拟中的阶段协调，不可替代共识协议逻辑。
Phaser 本身不是一致性算法，不能直接模拟 Paxos/Raft 等协议；它只是同步屏障工具，用错场景会掩盖分布式一致性的本质问题。
为什么不能把 Phaser 当作 Paxos 或 Raft 的“简化实现”
Phaser 的 arriveAndAwaitAdvance() 只做本地线程计数与阶段推进，不涉及网络通信、提案编号比较、多数派投票、日志复制或 leader 选举。Paxos 中的 Prepare/Accept 阶段必须跨节点交换消息并持久化状态，而 Phaser 完全不提供这些能力。强行用多个 Phaser 实例模拟“Acceptor 投票”只会导致：各节点 phase 号不同步、无超时重试、无法处理网络分区、无法区分 proposal ID 冲突——这些恰恰是 Paxos 要解决的核心问题。
- Phaser 的
onAdvance()回调只在本地所有注册线程都到达后触发，不能代表“法定人数已达成共识” - Phaser 没有状态持久化机制，节点崩溃重启后 phase 和 parties 全丢，而 Paxos 必须从磁盘恢复已接受的提案
- Phaser 不检查 value 是否冲突，也不保证“只有一个 value 被 chosen”，这违反 Paxos 安全性前提
Phaser 真实可用的定位：协调单机多线程模拟器的执行节奏
如果你要写一个 教学用的、单进程内运行的 分布式算法演示程序（比如可视化 Paxos 流程），Phaser 可以用来控制“模拟器时间轴”的阶段切换，但仅限于协调模拟线程本身，而非替代协议逻辑。
- 每个模拟节点（如
SimulatedAcceptor）启动后立即调用phaser.register()，确保它被计入下一阶段 - 在 prepare 阶段末尾，所有 acceptor 线程调用
phaser.arriveAndAwaitAdvance()，等全部模拟节点完成 prepare 处理再进 accept 阶段 - 若某个模拟节点因异常退出，主线程需监控
phaser.getUnarrivedParties()，超时后调用phaser.forceTermination()防止卡死 - 切勿在
onAdvance(int phase, int registeredParties)中实现提案比较或多数派判定——那些逻辑必须放在每个模拟节点自己的 run() 方法里
动态加入的正确写法：register() 必须早于任何 arrive* 调用
常见错误是 new Thread 启动后直接 phaser.arriveAndAwaitAdvance()，结果因未注册而永久阻塞。动态节点（如模拟的临时 learner）必须遵守严格时序：
- 节点线程启动后第一行代码必须是
phaser.register() - 注册成功后，才能执行本阶段业务逻辑（如解析收到的 Prepare 请求）
- 业务完成后，调用
phaser.arriveAndAwaitAdvance()等待其他节点，或phaser.arriveAndDeregister()主动退出后续阶段 - 注意：
register()不是幂等操作——重复调用会让该线程在后续阶段被计为多人，破坏阶段语义
多阶段屏障下容易忽略的关键点
Phaser 的阶段号（getPhase()）是全局单调递增的 long 值，但它的推进完全依赖于参与者主动调用 arrive* 方法。没有“自动推进”机制，也没有“阶段超时自动跳过”功能。这意味着：
- 如果某模拟节点逻辑卡死或忘记调用 arrive*，整个 stage 就停住，其他节点无限等待
- 不能靠判断
phase == 2就认为“已经进入 accept 阶段”，必须结合各节点实际状态（如是否已写入本地 log）来决定行为 - 调试时建议打印
phaser.getRegisteredParties()和phaser.getUnarrivedParties()，比只看 phase 更能反映真实同步进度
真正需要模拟分布式一致性，应基于 Netty/Vert.x 构建真实消息通道，并用 ZooKeeper 或 etcd 提供元数据协调；Phaser 最适合的，是帮你把单机多线程模拟器的“帧率”和“阶段节奏”管住，而不是代替共识逻辑本身。
