curator 的 interprocessmutex 实现 zookeeper 分布式锁，本质是利用临时顺序节点与 watch 机制实现强一致、防死锁、可重入的互斥控制；需 zookeeper 多节点集群、curator 5.3+、正确配置重试与会话超时，锁路径须为持久节点，acquire() 创建临时顺序节点并监听前驱，释放依赖会话自动清理与身份校验。
用 Curator 的 InterProcessMutex 实现 ZooKeeper 分布式锁，本质是利用 ZooKeeper 的临时顺序节点 + Watch 机制，达成强一致（CP 型）、防死锁、可重入的互斥控制。它不是“自己造轮子”，而是直接复用经过生产验证的高级封装。
核心前提：ZooKeeper 集群与 Curator 客户端准备
确保 ZooKeeper 服务已部署为多节点集群（如 3 或 5 节点），具备分区容错能力；客户端使用 Curator 5.3+（适配 ZooKeeper 3.8），并正确配置重试策略和会话超时：
- 连接字符串格式为
host1:2181,host2:2181,host3:2181，支持自动故障转移 - 推荐使用
ExponentialBackoffRetry设置重试，例如new ExponentialBackoffRetry(1000, 3) - 会话超时（session timeout）建议设为 30~60 秒，避免网络抖动误触发节点删除
加锁逻辑：一行 acquire() 背后的真实动作
调用 interProcessMutex.acquire() 并非简单发个请求，它完整执行以下流程：
- 在指定路径（如
/locks/order_process）下创建一个临时顺序节点，形如/locks/order_process/_c_abc123-lock-0000000007 - 获取该父路径下所有子节点，并按序号升序排列
- 判断自己创建的节点是否排在第一位：若是，立即获得锁；若否，对前一个序号更小的节点设置 Watch
- 一旦前驱节点被删除（释放锁），Watch 触发，重新检查排序列表，循环直至排第一
关键保障机制解析
InterProcessMutex 不仅“能用”，更在细节上守住分布式锁的核心要求：
- 强互斥性：依赖 ZooKeeper 的顺序节点原子创建与严格字典序，天然杜绝并发争抢导致的状态歧义
- 防死锁：节点为临时节点，客户端异常断连后，ZooKeeper 自动清理，锁自动释放
- 身份唯一性：每个锁实例绑定当前线程 + 会话 ID，解锁操作校验持有者身份，他人无法强制删除
-
可重入：同一 JVM 线程内多次
acquire()只会增加内部计数，不重复创建节点；对应release()也需调用相同次数才真正释放
生产级使用注意事项
避免踩坑，需关注这些实操细节：
- 锁路径必须是持久节点（如预先用
create -p /locks/order_process创建），否则首次加锁会失败 - 不要在 finally 块里无条件
release()—— 若 acquire 超时抛异常，锁并未拿到，此时 release 会报错；应先判断isAcquiredInThisProcess() - 业务执行时间应明显小于会话超时；如需长任务，启用 Curator 内置的
LockInternals自动续期（需开启CuratorFramework的 background thread） - 监控建议接入 Prometheus：Curator 5.3 提供了
LockStats接口，可暴露等待时长、获取成功率等指标
