volatile 在分布式锁中不发挥作用，它仅保证单JVM内线程间变量的可见性，无法解决跨节点状态同步问题，分布式锁必须依赖Redis、ZooKeeper等外部中间件实现。
volatile 在分布式锁的内存可见性中 不发挥作用。
这不是它设计的场景，也不是它的能力范围。直接说清楚：
volatile 只管单 JVM 内的线程间可见性
它通过 Java 内存模型（JMM）强制读写主内存、插入内存屏障、禁止重排序，确保：
- 同一个 JVM 中，线程 A 修改
volatile变量后，线程 B 能立即看到最新值； - 但它对跨进程、跨网络、跨机器的“其他节点”完全无感知、无干预能力。
分布式锁的本质是跨节点协调
分布式锁要解决的是：多个独立 JVM（比如 3 台服务器上的 Spring Boot 实例）如何就“谁持有锁”达成一致。
这依赖：
- 网络通信（如 Redis 的 SETNX、ZooKeeper 的临时顺序节点、etcd 的 Lease）；
- 共享外部存储（Redis、数据库、一致性协调服务）；
- 分布式共识机制（如 Raft、Paxos），而非本地内存同步。
所以：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 即使你在某个服务里用
volatile boolean locked = false;， - 这个
locked只在本机 JVM 的线程间可见； - 其他机器上的服务完全不知道这个变量的存在，更不会去读它——它们有自己的
locked副本，彼此毫无联系。
常见误解与典型误用
- ❌ 把
volatile用在微服务共享配置开关上（如volatile boolean featureEnabled），以为改了就能全集群生效； - ❌ 在分布式任务调度器中用
volatile标记“任务是否完成”，结果只有本节点更新，其他节点永远卡住； - ❌ 认为加了
volatile就能替代 Redis 的GET/SET或 ZooKeeper 的 watch 机制。
这些都会导致：
- 数据不一致；
- 锁失效（多个节点同时认为自己持锁）；
- 业务逻辑错乱（比如重复发券、重复扣库存）。
真正起作用的替代方案
要实现分布式环境下的“状态可见性”，得靠外部中间件或协议：
- ✅ Redis + Lua 脚本：用原子命令（如
SET key value NX EX 30）保证锁的获取与超时； - ✅ ZooKeeper：利用节点存在性 + Watch 机制通知锁状态变更；
- ✅ etcd：基于 Lease 和 Revision 的强一致性键值存储；
- ✅ 数据库乐观锁：用版本号或时间戳字段控制并发更新；
- ✅ 框架封装：如 Redisson 的
RLock、Curator 的InterProcessMutex，内部已屏蔽底层复杂性。
总结一句话
volatile 是单机多线程的“内存同步轻骑兵”，不是分布式系统的“跨节点信使”。想让锁的状态被所有节点看见，得靠网络+共识+外部存储，而不是加一个 volatile 关键字。
