Java 中 ReentrantLock 在分布式锁设计中的实现局限

先得明确一点：ReentrantLock 本质上只活在单个 JVM 进程内部，它天生不具备跨进程、跨机器的协调能力。所以，用它来实现分布式锁，从一开始就走错了方向。

那么，它到底卡在哪里？

无法跨越 JVM 边界

ReentrantLock 基于 AQS（AbstractQueuedSynchronizer）实现，本质上是一个本地锁。它的所有状态——谁持有锁、重入了几次、等待队列在哪里——都保存在当前 JVM 的本地内存中。当服务部署成集群，比如一个 Spring Boot 应用跑了多个实例，每个实例的 ReentrantLock 对象是完全独立的。节点1的锁被占用了，节点2对此一无所知，互斥效果自然无从谈起。

缺少自动失效与容错机制

分布式场景下，锁必须具备超时自动释放的能力，否则一旦持有锁的进程崩溃，就会造成死锁。ReentrantLock 本身不提供租约（lease）或 TTL（time-to-live）语义。你没法告诉它：“这把锁借你用 5 秒，超时我自动收回。” 即便你手动配合定时任务去 unlock，也无法处理进程直接宕机、锁还没来得及释放的情况。反观 Redis 的 SETEX 或 ZooKeeper 的临时节点，它们能从服务端层面保证“会话结束，锁即释放”。

无网络通信与一致性保障

分布式锁要依赖外部协调服务，比如 Redis、ZooKeeper、etcd，来让多个节点达成共识。ReentrantLock 没有内置任何网络协议，也不参与任何分布式一致性协议，Paxos 也好、Raft 也罢，和它都没关系。它既不能广播锁的状态，也无法验证锁的持有者是否合法——比如，防止某个节点误删其他节点持有的锁。这就意味着，它在 CAP 理论中对一致性或分区容忍性的基本要求都无法满足。

不支持跨语言与异构系统集成

现代微服务架构里，Ja va、Go、Python 等语言混用是常态。ReentrantLock 是纯 Ja va 实现，它的 API 和内存模型，其他语言根本看不懂，也拿不到。真正可用的分布式锁方案，比如 Redisson 或 Curator，本质上都是封装了标准协议（Redis 协议、ZooKeeper 的 ZNode 操作），这才让多语言客户端能够协同工作。