Java中锁机制从单机到分布式本质是“替换”而非“升级”，因synchronized/ReentrantLock仅限单JVM生效，跨进程即失效；分布式锁需借助Redis（高性能、原子命令）、ZooKeeper（强一致、临时节点）或数据库（简单但低效）等外部中间件实现互斥、防死锁与高可用。
Java 中的锁机制从单机走向分布式，本质不是“升级”而是“替换”——因为 synchronized、ReentrantLock 等本地锁只在 JVM 内生效，跨进程、跨机器就完全失效。要在分布式场景下保障共享资源的互斥访问，必须借助外部协调服务来统一管理锁状态。
下面从原理和落地两个层面说清楚怎么“换掉本地锁，用上分布式锁”。
为什么本地锁在分布式下不 work
-
synchronized和ReentrantLock依赖 JVM 的线程模型和内存可见性，所有线程必须在同一进程内； - 分布式系统中，多个服务实例部署在不同服务器上，各自有独立 JVM 和内存空间，彼此看不到对方的锁状态；
- 即使加了锁，A 服务加的锁对 B 服务毫无约束力，结果就是并发冲突、数据错乱（比如超卖、重复扣款）。
分布式锁的核心替代逻辑
要实现等效的“同一时刻仅一个节点操作资源”，需满足三个关键动作：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 获取锁：向共享存储发起原子请求，成功即代表抢到锁；
- 持有锁：业务执行期间，锁状态持续有效（通常靠自动过期或心跳续期）；
- 释放锁：业务完成或异常时，安全删除/标记锁，避免死锁。
这三步不能靠 Java 语言层完成，必须依赖外部中间件提供原子性与一致性保障。
立即学习“Java免费学习笔记（深入）”；
主流实现方式及选型要点
基于 Redis（最常用，适合高并发、低延迟场景）
- ✅ 优势：性能高（内存操作）、支持原子命令（如
SET key value NX EX seconds）、天然支持自动过期； - ⚠️ 注意点：
- 单节点 Redis 有单点风险，生产环境必须用哨兵或集群模式；
- 锁释放必须用 Lua 脚本校验 value，防止误删他人锁；
- 默认不可重入，如需重入，得自己维护锁计数（例如用 Hash 存
client_id:count）； - 网络分区时可能出现脑裂，建议配合 Redlock（多节点多数派）或直接用成熟封装如 Redisson。
基于 ZooKeeper（强一致性优先，适合任务调度类场景）
- ✅ 优势：顺序临时节点 + Watcher 机制，天然支持公平锁、可监听锁释放、会话失效自动清理；
- ⚠️ 注意点：
- 性能低于 Redis（ZK 写操作走 ZAB 协议，延迟更高）；
- 部署运维成本高，需单独维护 ZK 集群；
- 客户端连接中断后，若 session 未超时，锁仍存在，需合理设置
sessionTimeout。
基于数据库（简单系统或过渡方案）
- ✅ 优势：无需引入新组件，利用现有 MySQL/PostgreSQL；
- ⚠️ 注意点：
- 悲观锁（
SELECT ... FOR UPDATE）易阻塞、易死锁，不适合高频写； - 乐观锁（
version字段 + CAS 更新）不真正“锁”，靠重试解决冲突，适合读多写少； - 唯一索引插入法（建锁表，插唯一
lock_name）简单但无超时自动清理，需定时任务兜底。
- 悲观锁（
实际迁移怎么做？
- 找出原使用
synchronized或ReentrantLock的关键方法（如库存扣减、订单创建）； - 抽离出资源标识（如
"stock_lock_1001"），作为分布式锁的 key； - 替换加锁/解锁逻辑：用 RedisTemplate 或 Redisson 获取锁，包裹原业务代码；
- 加异常兜底：try-finally 或 try-with-resources 确保锁一定释放；
- 加超时控制：获取锁设 wait timeout，业务执行设 lease time，防无限等待或长持有。
不复杂但容易忽略。
