承接上一篇锁超时、主从丢锁、集群脑裂三大生产问题，本篇聚焦 Redisson 中三类高频进阶锁：公平锁、异步锁、读写锁。分别讲解设计原理、适用场景、底层逻辑、核心代码与线上使用规范，区分不同业务场景该如何选型，同时对比普通非公平锁的差异，补齐分布式锁完整知识体系。
一、开篇导读
前面篇章讲解的均为 Redisson 默认非公平可重入锁，线程抢锁全凭竞争，不区分等待顺序。在实际业务中，会遇到排队有序执行、异步无阻塞加锁、读写分离并发控权等场景，普通锁无法满足诉求。 本篇依次拆解三大进阶锁：公平锁解决排队顺序问题、异步锁适配非阻塞编程模型、读写锁区分读 / 写并发权限，同时附带 Lua 核心逻辑、调用示例、优缺点与落地禁忌。
二、Redisson 公平锁（FairLock）
2.1 适用场景
非公平锁下，新线程可能直接插队抢到锁，长期等待的线程会出现线程饥饿 。 公平锁严格按照请求加锁的先后顺序分配锁资源，保证先来先执行。 典型场景：消息队列消费、任务排队执行、顺序化业务流程、需要严格保证请求时序的接口。
2.2 底层数据结构与核心原理
公平锁在普通 Hash 锁基础上，额外借助 List 队列 + 发布订阅 实现排队机制：
- 基础锁结构：依旧使用 Hash 存储线程标识与重入次数，保留可重入特性；
- 排队队列：单独维护一个 List 结构，记录所有等待锁的线程标识，按照入队顺序排序；
- 竞争规则：锁释放后，从队列头部取出第一个等待线程分配锁，杜绝插队；
- 唤醒机制：结合发布订阅，锁释放后依次唤醒队列内线程，有序竞争。
2.3 核心运行流程
- 线程尝试加锁，若锁空闲，直接获取锁执行业务；
- 锁被占用时，将当前线程信息存入等待队列，订阅消息并阻塞；
- 锁持有者解锁后，向频道发送释放通知，同时从队列头部取出首个等待线程；
- 被唤醒线程获取锁，其余线程继续排队，全程遵循先来先服务。
2.4 基础使用示例（Java）
java
运行
2.5 优缺点与选型建议
- 优点：保证执行顺序，彻底解决线程饥饿，时序严格可控；
- 缺点：多了队列维护、顺序唤醒逻辑，性能略低于非公平锁，高并发下吞吐略有下降；
- 建议：顺序类业务必用公平锁，高并发抢资源、无顺序要求场景优先默认非公平锁。
三、Redisson 异步锁（AsyncLock）
3.1 适用场景
传统 lock() 是同步阻塞 模式，线程会一直卡在加锁环节，直到获取锁成功。 异步锁基于 Reactor 异步模型，适配响应式编程、Netty 服务、网关、微服务异步链路，全程不阻塞工作线程，提升线程复用率与系统吞吐。 典型场景：网关接口、异步回调服务、高吞吐中间件、全异步架构项目。
3.2 核心设计特点
- 不阻塞当前工作线程，加锁结果通过回调、CompletableFuture 异步返回；
- 底层依然复用原有 Lua 脚本、看门狗续期、发布订阅能力，功能与同步锁完全对齐；
- 支持可重入、超时等待、自动续期、失败重试等全部特性；
- 严格遵循异步编程范式，避免阻塞线程池造成服务卡死。