1. 分布式锁在不同场景下的使用方式
在日常开发里，分布式锁是个绕不开的话题。说到"Redisson分布式锁"，我猜你可能遇到过两种情况：要么是微服务架构下多个实例需要抢同一个资源，要么是定时任务在集群环境里重复执行导致数据异常。不管是哪种，Redisson这个基于Redis的Java客户端框架，都会是你在Java技术栈里最顺手的选择之一。
先说说它到底解决了什么问题。传统单机环境下，JVM内置的synchronized和Lock就能搞定线程安全。但一旦服务拆成多实例部署，或者多个服务协作处理同一份数据，锁就必须放在所有节点都能访问到的地方。Redis作为一个高性能的存储中间件，天然适合承担这个"公共锁仓库"的角色。Redisson则是把Redis底层命令封装成了我们熟悉的Java锁API，用起来几乎和单机锁一样顺手，同时帮你处理了超时续期、原子性保证、重入等细节问题。
这篇文章主要面向三类读者。第一类是刚接触微服务、需要给接口加并发控制的开发者；第二类是在已有项目里遇到过重复执行、超卖等并发问题，想找一个成熟方案的工程师；第三类是单纯想弄清楚Redisson内部机制，避免踩坑的人。我会从原理讲到代码，再讲实际部署时遇到的坑，内容尽量贴近真实业务场景。
很多人一开始图省事，自己拿SETNX写个锁，结果线上出了各种问题：锁过期了代码还没跑完、删除锁时误删了别人的锁、主从切换时锁直接消失。Redisson把这些坑都封装掉了，这也是我用它替换自研锁的核心原因。下面我从头到尾拆一遍，包括它为什么这么设计、代码怎么写、以及我在项目中实际踩过的坑。
2. 为什么不用自己手写的SETNX锁
2.1 手写Redis锁的几个经典坑
自己实现分布式锁，思路其实很简单：多个客户端竞争写同一个key，谁写成功了谁就获得锁。用Redis命令表达就是SET key value NX EX seconds，NX保证只有key不存在时才能写入，EX设置自动过期时间防止死锁。但真正落到生产环境，这个看似简单的方案有四个绕不开的坑。
第一个坑是锁过期时间不好设。设短了，业务没跑完锁就没了，别的请求趁机进来，并发控制失效。设长了，万一持有锁的节点宕机，要等很久锁才自动释放，大量请求堆积在等待队列里。按照经验值，业务执行时间的中位数乘以3到5倍，看起来合理，但实际业务总会遇到极端情况，某次慢查询、GC停顿、网络抖动，时间直接就超了。
第二个坑是误删锁。进程A拿到锁，执行太久，锁自动过期。进程B拿到新锁开始执行。这时候A终于跑完了，执行DEL删锁，直接把B的锁删了，导致C也能进来，三个进程同时操作临界区。解决办法是删除前先比较value是否是自己写入的那个唯一标识，但"比较+删除"两个步骤之间会引入新的并发窗口，除非用Lua脚本保证原子性。
第三个坑是主从切换导致锁丢失。Redis主节点写入了锁，还没同步到从节点时主节点挂掉，从节点晋升为主节点，但锁数据已经丢了，其他客户端又可以拿到同一把锁。这个坑在自研方案里基本没法解，除非上更重的组件。
第四个坑是等待锁的体验不好。拿不到锁的请求只能循环轮询SETNX，或者干脆直接失败返回。这里又碰上两难：轮询间隔短了，Redis压力大；间隔长了，响应变慢。而且没有"公平竞争"的概念，后面来的线程可能比前面的先抢到锁。
我早期接手的项目里，线上出现过一个很典型的误删锁故障。服务A处理用户积分入账，某次数据库慢查询导致执行时间超过锁过期时间，锁被自动释放。服务B拿到锁后开始重复入账，A跑完之后又把锁删了。最终结果是同一笔积分数次入账，对账时才发现问题。报障的同事一开始怀疑Redis出了问题，查了半天才发现是锁代码写错了。从那之后，我在团队里定了规矩：分布式锁相关的代码，不自己造轮子。
2.2 Redisson在锁过期问题上的设计
Redisson解决"锁提前过期"的办法叫看门狗机制。默认情况下，拿锁时如果不指定leaseTime，框架会启动一个后台定时任务，每隔一段时间（默认是锁超时时间的1/3）检查锁是否还在。如果锁还在且有线程持有，就自动续期，把过期时间往后推。这就相当于给锁设置了一个动态有效期——只要持有锁的线程还活着，锁就永远不会提前过期。
但如果业务线程已经执行完并释放了锁，定时任务也会随之取消，不会白白占用资源。这个设计意味着"锁的存活时间"和"业务执行时间"解耦了，你不需要费心预估业务要跑多久。
Redisson默认的锁超时时间是30秒，看门狗每10秒续一次。如果业务逻辑超过30秒还没有执行完，也不用担心，只要线程不挂，锁会一直续下去。如果线程所在的进程突然宕机，看门狗也停了，锁最多30秒后自动过期，不会造成死锁。
当然，看门狗也不是没有成本。每把锁都会有一个后台定时任务在跑，锁的数量多了，Redis的PEXPIRE命令调用量会上升，不过实测下来这个开销可以接受，正常业务规模下不需要刻意优化。
3. Redisson锁的核心机制拆解
3.1 从一次加锁看整个链路
Redisson加锁的核心不是一条简单的SET命令，而是一段Lua脚本。用Lua的原因很直接：Redis单线程执行脚本，整个脚本天然是原子的，中间不会被其他命令插进来。这一点是用SETNX还能不能保证原子性时最关键的差别。
加锁时，Redisson会执行一段脚本，做三件事：第一，判断锁的key是否已存在；第二，如果不存在，用Hash结构写入锁信息，field是"客户端唯一ID:线程ID"的组合，value是重入次数，初始为1，同时设置过期时间；第三，如果已存在，校验field是不是当前线程的标识，如果是，把重入次数加1并重置过期时间。
用Hash结构而不是简单的String，是因为要支持锁的可重入。同一个线程可以多次加锁同一把锁，比如方法A调方法B，两处都加了同一把锁，正常情况下B应该能直接拿到锁继续执行，而不是把自己卡死。Redisson通过判断客户端标识来识别同一线程，重入时只增加计数，不会重新设置锁的持有者。
解锁时对应的Lua脚本逻辑则相反：先校验当前线程是否持有锁，是的话把计数器减1；如果计数器变成0，删除整个key并发布"锁已释放"的消息；如果计数器还没归零，只更新过期时间，锁仍然保留，表示外层方法还没退出。
我经常用一个比喻来给团队新人讲这个机制：Hash结构就像一个储物柜，钥匙上刻着你的名字。你进去一次，柜子门上的计数器加一，走一步减一，计数归零时柜门彻底锁上。别人来开柜子时发现自己的名字对不上，就不会去动你的计数器。
3.2 看门狗续期到底在做什么
看门狗的实现其实不复杂，但设计上有几个细节值得关注。
第一，续期脚本例行的职责是重新设置锁的过期时间。如果锁还没到期，说明业务还在执行，就调用PEXPIRE把过期时间重置为默认值。如果锁已经不存在了，说明业务已经结束或者锁异常释放，就停止续期。
第二，看门狗是绑定当前线程的。每个线程加锁时会注册一个独立的定时任务，线程解锁时把这个任务取消。不会出现线程A的看门狗给线程B的锁续期的情况，因为续期前会校验持有者身份。
第三，如果你手动指定了leaseTime，看门狗就不会启动。这是很多人忽略的点。因为一旦指定了租约时间，框架认为"业务执行时长你心里有数"，它就不帮你兜底了。所以实际使用中，如果某段代码执行时间可能超过预设的5秒，要么给足余量，要么干脆不传leaseTime让看门狗处理。
这个设计的取舍是：看门狗的安全感换来的是Redis key的生命周期可能被延长。如果业务线程卡死但JVM还活着，看门狗会一直续期，锁永远不释放。所以不要以为有了看门狗就万事大吉，长时间持锁仍然要排查是不是代码里有阻塞操作。
3.3 等待锁的线程是怎么被唤醒的
拿不到锁的线程不会傻傻轮询。Redisson里有一个绕开轮询的设计：等待中的线程会订阅一个Redis频道，这个频道跟锁的key一一对应。持有锁的线程释放锁时，会往这个频道发布一条消息，正在等待的线程收到消息后会重新尝试获取锁。
这样设计的好处很直观。轮询方式下，N个线程同时等一把锁，每个线程每秒轮询一次，Redis每秒要处理N次查询命令。而订阅方式下，大部分时间线程都在阻塞等待信号，只有锁释放时才真正唤醒竞争，Redis的压力小很多。
我还记得一个细节：加锁失败后，Redisson会先通过"订阅+信号量"的方式阻塞，然后有一个小循环来确保等锁线程能及时被唤醒。从实测效果看，等锁线程的唤醒延迟通常在毫秒级别，基本不会对业务造成可感知的等待。
3.4 公平锁和常规锁的差异
默认的lock()拿锁时是抢锁模式，谁手快谁得。但有些业务场景需要公平性，比如秒杀活动里先到先得、订单处理里按请求顺序执行。Redisson提供了FairLock，核心是基于Redis的有序集合和队列历史记录来实现先进先出。
公平锁的代价是性能下降。每把锁多维护了一个等待队列，加锁和解锁需要额外的Redis命令来管理队列。如果业务对执行顺序不敏感，没必要用公平锁。我一般只在资金类操作或者对账类的串行任务里才用。
4. Spring Boot集成Redisson的实操记录
4.1 环境准备与依赖引入
我在项目里用的版本是Spring Boot 2.7和Redisson 3.23，两者兼容性稳定，如果是Spring Boot 3.x，需要注意Redisson版本要在3.17以上。Maven坐标：
<dependency> <groupId>org.redisson</groupId> <artifactId>redisson-spring-boot-starter</artifactId> <version>3.23.5</version> </dependency>引入依赖后，在application.yml里配置Redis连接信息：
spring: redis: redisson: config: | singleServerConfig: address: "redis://127.0.0.1:6379" password: null database: 0 threads: 16 nettyThreads: 32 transportMode: "NIO"需要提醒的是，如果项目里同时使用了Spring Data Redis和Redisson，两者可以共存，Spring Data Redis负责缓存操作，Redisson负责锁，互不干扰。但如果自己手动构建RedissonClient，要记得在@Configuration里声明Bean，避免和starter自动配置重复创建连接池。
4.2 三种最常用的加锁模板
第一种是lock()，最粗暴的写法。拿不到锁就死等。适合那些宁可卡住也不能跳过、但锁等待时间极短的场景，日常建议少用。
@Autowired private RedissonClient redissonClient; public void processOrder(Long orderId) { RLock lock = redissonClient.getLock("order:lock:" + orderId); lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); } }第二种是tryLock()带等待时间和租约时间。等不到就放弃，适合接口调用方有超时约束的场景。
public boolean tryProcess(Long userId) { RLock lock = redissonClient.getLock("user:lock:" + userId); boolean acquired = false; try { // 尝试5秒，拿不到就放弃 acquired = lock.tryLock(5, 10, TimeUnit.SECONDS); if (!acquired) { return false; } // 业务逻辑 return true; } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } finally { if (acquired && lock.isHeldByCurrentThread()) { lock.unlock(); } } }第三种是给业务指定明确的租约时间。此时看门狗不生效，锁一定会在这个时间后过期，适合那些你确认执行时间不会超过阈值的场景。
lock.lock(3, TimeUnit.SECONDS);三种写法里最容易被坑到的是
tryLock(5, 10, TimeUnit.SECONDS)，这里的5是等锁等待时间，10是租约时间。很多人把第一个参数理解成"执行超时时间"，下意识设成很大，结果锁一直占有不释放，别人永远抢不到。再次提醒一句，这个参数管的是"等待获取锁"的时长，不是业务执行时长。
4.3 注解式加锁的自定义封装
每次手动写try/finally容易漏，我在项目里用一个线程安全的封装解决这个重复劳动。思路是定义一个自定义注解，配合Spring AOP的环绕通知来做加锁和解锁。
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface DistributedLock { String key(); long waitTime() default 3; long leaseTime() default 30; TimeUnit timeUnit() default TimeUnit.SECONDS; }切面里根据注解的key拼接锁名，加锁后调用方法的joinPoint.proceed()，finally里释放锁。有一点要特别注意：AOP切面只能拦截通过Spring容器调用目标方法的情况。同一个类里方法自调用时，注解不会生效，因为代理没走进去。
这个自定义注解用起来会清爽很多，业务代码里只需要在方法上加上@DistributedLock(key = "order:lock:#orderId")。虽然Redisson官方没有提供这样的注解，但社区方案成熟，照着封装一个完全可行。
4.4 单元测试里怎么验证锁的行为
集成Redis做单测的成本略高，我测试分布式锁一般分两级。第一级用本地Redis容器（比如嵌入式或者测试容器起一个Redis服务），验证基本加解锁流程；第二级写一个高并发对比的集成测试，模拟同时提交多个请求，验证最终只有一个执行成功。
一个我常用的并发测试思路：起10个线程同时执行同一个加锁方法，记录进入临界区的线程数，断言只有一个线程进入。为了确认锁确实被竞争过，可以加一个计数器，记录所有线程尝试加锁的次数，这个值应该远大于1。
@Test public void testDistributedLockOnlyOneEnter() throws Exception { int threadCount = 10; CountDownLatch readyLatch = new CountDownLatch(threadCount); CountDownLatch startLatch = new CountDownLatch(1); AtomicInteger enterCount = new AtomicInteger(); for (int i = 0; i < threadCount; i++) { new Thread(() -> { readyLatch.countDown(); try { startLatch.await(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } RLock lock = redisson.getLock("test:lock"); if (lock.tryLock()) { enterCount.incrementAndGet(); lock.unlock(); } }).start(); } readyLatch.await(); startLatch.countDown(); Thread.sleep(500); assertEquals(1, enterCount.get()); }5. 分布式锁的进阶用法与业务落地场景
5.1 读写锁：读并发写互斥
Redisson的RReadWriteLock适合读多写少的场景。读锁和读锁之间不互斥，读锁和写锁、写锁和写锁之间互斥。这个语义和JVM里的ReadWriteLock一致，但作用范围是整个分布式集群。
一个典型的应用场景是配置中心：多个实例同时读取某个配置项，某个时刻管理员更新配置，更新期间读请求应该被阻塞，避免读到中间状态，而日常读取可以并发执行，不需要加锁排队。用Redisson的读锁时要注意，如果业务对"读到旧值"不敏感，其实不需要读锁，直接把配置放在缓存里定期刷新反而性能更好。
读锁和写锁的代码形式和RLock几乎一样，只是获取锁对象时要用redissonClient.getReadWriteLock("config:lock")，然后分别调用readLock()和writeLock()。要特别注意的是，在同一个线程里，先拿写锁再拿读锁是允许的，反过来则会发生死锁，这和JVM的读写锁规则一致。
5.2 红锁到底要不要用
Redisson提供了RedissonRedLock，思路是同时对多个Redis主节点加锁，超过半数成功才算加锁成功。这解决的是"单点Redis主从切换丢锁"的问题，但也带来了性能和维护成本的大幅上升，而且业界对这个方案本身有争议。
我个人的实际体会：对于绝大多数业务场景，单台Redis配上主从和哨兵已经足够。锁丢失的问题确实是极小概率事件，而红锁部署多套Redis的复杂度是确定性的，为了极小概率的故障场景付出持续的运维成本，性价比不高。
如果业务确实要求极强的锁可靠性，比如金融级的资金操作，建议优先考虑引入基于共识算法的顺序一致性组件，或者用数据库本身的乐观锁来兜底，而不是指望红锁解决一切。
我看到过一种说法：红锁的争议点不在于它不能工作，而在于它假设了"每个Redis节点之间时钟完全一致"，这在现实里很难保证。涉及时钟偏移、GC停顿等问题时，红锁不能提供真正的强一致性保证。所以在选型时不要因为"听起来更安全"就无脑上红锁，先评估业务对锁丢失的实际容忍度。
5.3 多级锁与分段锁的设计思路
有些热点资源上锁粒度太大，会导致大量线程排队，QPS上不去。举个库存扣减的例子：如果所有用户抢购同一个商品都去抢同一把"商品锁"，即使Redis处理能力够，业务侧也会因为锁排队而拉长响应时间。此时可以引入分段锁，把库存拆成多个独立的段，用户请求先根据用户ID哈希到某个段，再对那个段加锁。
分段锁的缺点是：一次性扣减多个段的库存时，需要处理多个锁的获取顺序，顺序不对容易形成环路死锁。比如一个请求要同时扣减段1和段2，另一个请求要扣减段2和段1，如果两边分别持有段1和段2的锁再等对方，就死锁了。缓解方案是让所有请求按照段ID从小到大依次加锁，破坏环路。
Redisson本身没有直接提供分段锁的接口，但可以配合getLock(lockKeyPrefix + segmentId)来实现。设计分段数时，要根据业务热点和Redis实例的QPS能力来评估，没有固定的推荐值。
5.4 幂等校验和分布式锁的配合
分布式锁解决的是同一时刻只有一个执行者的问题，但并发请求里经常出现"重复提交"的场景：同一个订单的取消请求，用户点了两次，两次请求同时到达，虽然锁保证只有一次能执行，但第二次请求不能直接返回失败，最好是告诉用户"正在处理中"。
实际操作中，我在锁的基础上加了一个幂等标记：第一次请求进来时，在Redis里写入一个"处理中"状态，设置较短过期时间；第二次请求看到这个状态，直接返回"请稍后重试"，而不是走加锁逻辑。两套机制配合，体验会好很多。
6. 生产环境实战中的问题排查与避坑记录
6.1 锁没起到作用：为什么会重复执行
锁没起作用，优先排查的不是Redis，而是"所有客户端是不是连的同一个Redis"。如果某个服务的配置指向了不同的Redis实例，或者Redis做了多租户隔离，那么两边各刷各的锁，根本互相看不到。这类问题在开发环境模拟不出来，只有上线后才会暴露。
其次是锁的key设计。如果key里有变量，比如订单号、用户ID，要确认多个请求用的是同一个值。之前有个项目把用户ID和会话ID一起拼进锁key，同一个用户的两次请求因为会话不同，锁key自然不同，并发控制完全失效。
还要检查代码是不是真的走了锁逻辑。AOP切面对方法自调用不生效，这是我前面提到的典型例子。如果方法内部调用另一个加锁方法，锁的作用范围可能和预期不符。
6.2 锁提前释放或删除失败
锁提前释放最常见的原因是手动了leaseTime且设置过短。看门狗不会干预你手动指定的过期时间，所以业务一旦超过这个时间，锁就物理消失。排查时看监控里锁的过期时间是否和预设值一致，如果每次都卡在预设时间附近，问题基本定位。
删除锁失败则要检查isHeldByCurrentThread()判断。如果你在锁的持有线程之外调用了unlock()，Redisson会抛出IllegalMonitorStateException。别忽略这个异常，它其实是在保护你：说明你试图释放别人持有的锁。用try/finally包裹解锁时，finally里要判断当前线程是否真的持有锁，避免在锁已经自动过期的情况下调用unlock()。
6.3 锁等待超时却不生效
并发量大的时候，锁的等待机制可能会出现"等了很久也没拿到锁"的情况。排查方向有三个：一是确认等待时间是否够长，tryLock的等待时间设置成1秒，在高竞争下大概率拿不到；二是有没有大量的锁没有释放，导致后来的线程全部在排队；三是Redis实例的CPU使用率是否接近饱和，此时无论锁本身设计得多好，Redis的响应延迟都会拖累整体表现。
我遇到过一次比较隐蔽的情况：某个加锁请求在拿到锁之后，业务代码里调了第三方接口，超时设置为60秒，相当于锁被占用了整整60秒。这段时间内所有同key的请求全都超时。后来给第三方调用单独设置了较短的超时时间，同时把锁粒度细化，问题才解决。
6.4 常见问题速查
| 问题现象 | 可能原因 | 排查思路 |
|---|---|---|
| 锁看似加了却没有互斥效果 | 不同实例连了不同Redis；锁key里拼接了过多变量 | 检查Redis连接配置；对比锁key值 |
| 业务未执行完锁就释放 | 手动指定了过短的leaseTime | 去掉leaseTime让看门狗接管，或调大时间 |
| 解锁抛IllegalMonitorStateException | 在非持有线程里调用unlock | 解锁前用isHeldByCurrentThread判断 |
| 高并发下大量请求等锁超时 | 锁粒度太大、等待时间太短、Redis压力高 | 细化锁粒度、增加等待时间、扩容Redis |
| AOP注解加锁不生效 | 方法自调用或代理没生效 | 通过Spring注入调用，或改用编程式加锁 |
6.5 高并发场景下的性能实测数据
我在测试环境模拟过一组数据，供大家参考。单台Redis 8核16G内存，锁的key前缀固定为10个热点段，客户端50个线程并发抢锁，每把锁的业务逻辑是纯内存计算加模拟耗时50毫秒。实测结果是：吞吐量大概在每秒4500次加解锁左右，P99延迟在120毫秒内。如果方案改成所有线程抢同一把锁不分段，P99会飙升到接近300毫秒。这说明锁的粒度和分段设计在业务量上来时非常重要。
如果Redis单实例已经成为瓶颈，可以优先考虑把锁key拆分到不同的Redis分片，或者给热点锁设计短租约时间，减少锁key在Redis里的存留时间。但无论如何，都要记住一个原则：锁只是保证正确性的兜底手段，不能替代业务层面的乐观设计。
7. 我对Redisson分布式锁的真实体会
做分布式系统这几年，我用过自研的Redis锁、用过数据库乐观锁，也用过Redisson，最后留在生产环境里的基本都是Redisson。
让我最放心的一点是它的设计成熟度。加锁、解锁、等待唤醒、续期这些细节，Redisson的源码里考虑得很完整，远比团队里自己花两天写出来的方案可靠。Lua脚本保证原子性，Hash结构支撑可重入，发布订阅机制解决轮询压力，看门狗兜底锁过期问题——每一处设计都对应着真实生产环境里踩过的坑。
但我也要泼点冷水：Redisson不是万能药。它解决的是"多节点互斥"这个单一问题，但它不解决你的锁粒度粗、业务超时、Redis集群运维这些更上层的设计问题。框架能帮你把锁做得正确，但锁本身的存在价值取决于你是否在合适的地方用它。
我手上现在还有一个原则：能用数据本身保证一致性的场景，不用锁；必须用锁的场景，锁的持有时间要尽可能短；锁的key要有清晰的生命周期语义，用完之后立刻释放，不依赖过期兜底。Redisson让这个原则落地变得很简单，但判断力还是得在自己手里。
