ReadWriteLock 仅适用于单机多线程场景，不支持分布式锁；其基于AQS实现，状态存于本地内存，无法跨JVM同步，故分布式下易致脏读、超卖等问题，应改用Redis分布式锁、ZooKeeper、数据库行锁或乐观锁等方案。
ReadWriteLock 本身是 JVM 进程内的本地锁机制，不适用于分布式系统。
ReadWriteLock 的作用范围仅限单机
它基于 AQS（AbstractQueuedSynchronizer）实现，所有状态（如读锁计数、写锁持有线程、等待队列）都保存在内存中，完全依赖线程间共享的堆内存和 volatile 变量。这意味着：
- 锁的状态无法跨 JVM 进程同步，不同节点上的 ReadWriteLock 实例彼此完全独立
- 节点 A 持有写锁，不影响节点 B 同时获取读锁或写锁，数据一致性无法保障
- 没有内置的网络通信、租约管理或故障探测能力
分布式场景下直接使用 ReadWriteLock 的风险
若在微服务或多实例部署中误用 ReadWriteLock 保护共享资源（如数据库记录、缓存键），将导致：
- 脏读/丢失更新：多个节点并发读取旧值后写入，覆盖彼此修改
- 缓存不一致：各节点本地缓存被各自 ReadWriteLock 保护，但底层存储已变更
- 逻辑错误：例如“库存扣减”看似加了读写锁，实则各节点独立判断并扣减，超卖不可避免
分布式环境下应替代的方案
需选用具备跨进程协调能力的分布式并发控制机制：
立即学习“Java免费学习笔记（深入）”；
- 分布式锁：如 Redis 的 RedLock（注意其争议与正确性边界）、ZooKeeper 临时顺序节点、Etcd 的 Lease + CompareAndSwap
- 数据库行级锁：SELECT ... FOR UPDATE（配合事务隔离级别），由 DBMS 保证强一致性
- 乐观锁：版本号（version）或时间戳字段，在提交时校验是否被其他请求修改
- 分布式一致性协议：如基于 Raft 的状态机复制（适合高一致性要求的核心服务）
ReadWriteLock 在分布式系统中的合理定位
它仍有价值，但仅用于单节点内部优化：
- 保护本地缓存（如 Caffeine）的读写，避免本节点多线程竞争
- 加速配置对象、元数据等只读或低频更新的本地副本访问
- 与分布式锁配合使用：先获取分布式写锁 → 更新 DB + 本地缓存 → 用 ReadWriteLock 保护后续高频读
