synchronized在分布式环境失效，因其仅作用于单jvm内；需用外部协调服务实现跨进程互斥，常用redis（配合redisson）、zookeeper或数据库方案，选型取决于性能、一致性与运维成本。

synchronized 在分布式环境失效，是因为它只作用于单个 JVM 内部的线程，而分布式系统中多个服务实例运行在不同进程、不同机器上，彼此看不到对方的锁状态。要解决这个问题，核心思路是：**用一个所有节点都信任的外部协调服务来实现跨进程互斥**。

用 Redis 实现分布式锁（最常用）

Redis 因其高性能和原子操作能力，成为生产中最主流的分布式锁底座。关键不是简单 set key，而是必须满足互斥、防死锁、可重入、自动续期等要求：

• 使用 SET key value NX PX timeout 命令，保证“设置+过期”原子性，避免 set + expire 分离导致的锁不一致
• value 必须是唯一随机字符串（如 UUID），释放锁时通过 Lua 脚本比对 value，防止误删他人锁
• 引入“看门狗”机制（如 Redisson 的 watchdog），在锁持有期间自动延长过期时间，避免业务执行超时导致锁提前释放
• 推荐直接使用 Redisson 客户端，它已封装好可重入、公平、联锁、红锁等高级能力，且默认启用看门狗

用 ZooKeeper 实现强一致性锁

ZooKeeper 基于 ZAB 协议提供强一致性，适合对数据安全要求极高的场景（如金融类任务调度）：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 利用临时顺序节点（Ephemeral Sequential Node）实现锁排队；客户端监听前一个节点的删除事件来感知锁释放
• 会话断开后临时节点自动删除，天然具备防死锁能力
• 缺点是性能低于 Redis，部署运维更重，网络波动易引发羊群效应

数据库方案（适合低并发、强事务场景）

在已有数据库且并发压力不大的系统中，可用唯一索引或 for update 实现轻量级分布式锁：

• 插入唯一键记录（如 lock_name = 'order_gen'），插入成功即获锁，失败则重试或等待
• 或用 select ... for update 查询一条固定记录，依赖数据库行锁保证互斥
• 务必配合超时机制和定时清理任务，否则容易因异常未释放导致死锁

选型关键看三个维度

不追求“最好”，而要看是否匹配你的实际需求：

• 性能优先、容忍短暂不一致 → Redis（配合 Redisson）
• 强一致性不可妥协、能接受一定延迟 → ZooKeeper 或 etcd
• 已有数据库、QPS 很低、不想引入新中间件 → 基于 DB 的乐观/悲观锁方案

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南