1. 问题现场：那个让人头疼的“attempt to unlock lock”异常

不知道你有没有遇到过这种情况：项目里用Redission分布式锁，平时跑得好好的，一到流量高峰或者某些特定操作序列下，控制台就开始疯狂报错，抛出一个IllegalMonitorStateException，错误信息大概长这样：attempt to unlock lock, not locked by current thread by node id: xxxxx。第一次看到这个错误，我整个人是懵的，心里想：“我明明是在当前线程里加的锁，怎么解锁的时候就说不是我的锁了？”

这个错误，说白了就是“解铃人非系铃人”。Redission在解锁时，会做一个严格的校验：它不仅要检查这把锁是否存在，还要检查请求解锁的线程ID和客户端节点ID，是不是当初那个成功获取到锁的“主人”。如果对不上，它就认为你在尝试释放一个不属于你的锁，这是一种安全防护机制，防止锁被误删导致业务逻辑混乱。但在实际高并发场景里，这个机制反而成了“事故高发区”。

我踩过几次坑之后发现，这个问题很少是简单的代码写错了，它背后往往是一系列“巧合”叠加的结果。最常见的就是线程复用和锁续期（看门狗）机制失效这两个坑爹兄弟联手搞事。比如，你用了线程池，一个线程刚执行完一个带锁的任务，很快又被调度去执行另一个任务，如果前一个任务的锁因为某种原因还没完全释放干净（比如网络延迟导致Redis里的锁标识删除慢了半拍），后一个任务又试图去操作同一把锁，就很容易撞上这个错误。更隐蔽的是，当你使用lock.lock(10, TimeUnit.SECONDS)这种带超时参数的方法时，你以为万事大吉，实际上却默默关闭了Redission的看门狗自动续期功能。一旦你的业务执行时间超过了10秒，锁就自动过期释放了，但你的线程还在傻傻地执行后续逻辑，等走到finally块里调用unlock()时，锁早就没了，或者已经被其他节点抢走了，这时候再去解锁，可不就报错了嘛。

所以，面对这个异常，我们首先得转变思路：别把它当成一个简单的“bug”去修，而要把它看作一个系统在高并发、分布式环境下状态一致性的警示信号。它逼迫我们去深入理解Redission锁的生命周期管理、线程模型与锁的绑定关系，以及如何正确地与它的看门狗机制协作。接下来，我们就一层层剥开这个问题的外壳，看看里面到底藏着什么玄机。

2. 深度原理：线程、Node ID与看门狗的三者博弈

要彻底搞懂这个异常，我们得钻进Redission的肚子里看看它到底是怎么运作的。这涉及到三个核心概念：线程标识、客户端节点ID（Node ID）和看门狗（Watchdog）机制。它们三个的关系，决定了锁的归属和生死。

2.1 锁的“身份证”：线程ID + Node ID

在单机JVM的synchronized或ReentrantLock里，锁的持有者就是线程本身，JVM自己就能管理。但在分布式环境下，光靠线程ID就不够用了，因为不同机器上的线程ID可能会重复。所以Redission设计了一个复合型的“锁持有者标识”。

当你调用lock.lock()时，Redission底层会做这么几件事：

1. 生成一个唯一的客户端节点ID（Node ID）。这个ID通常是UUID:线程ID的格式，或者基于机器特征生成，确保在整个分布式集群中唯一。
2. 获取当前线程ID。
3. 将 Node ID + 线程ID 的组合，作为value，存储到Redis中这个锁对应的key里。

你可以把它想象成一把智能锁，它不仅记录是谁家的钥匙（Node ID代表哪个服务实例），还记录是这家人里的谁的手（线程ID）拿钥匙开的锁。解锁的时候，它必须核对这两重信息，完全匹配才会开门。这就是not locked by current thread by node id错误的直接来源——你手里的“钥匙”对不上锁里记录的“备案信息”。

2.2 守护神与“自杀开关”：看门狗机制详解

Redission最被人称道的就是它的看门狗自动续期机制。但很多人对它一知半解，反而容易踩坑。

看门狗什么时候上班？ 答案是：只有当你使用无参的lock.lock()方法时，看门狗才会被激活。 这是一个关键点！如果你用了lock.lock(leaseTime, TimeUnit)，传入了租约时间参数，就相当于你明确告诉Redission：“我知道我的业务要执行多久，时间到了你直接删锁就行，不用管我。” 这时候，看门狗就不会启动。

看门狗是怎么工作的？ 假设看门狗被激活了（默认超时时间lockWatchdogTimeout是30秒）。它的工作流程是这样的：

1. 成功加锁后，锁在Redis中的过期时间被设置为30秒。
2. 同时，在加锁成功的客户端，会启动一个后台定时任务（看门狗），这个任务每隔10秒（30秒 * 1/3）执行一次。
3. 每次执行，它都会检查当前线程是否还持有这把锁（通过本地的一个ConcurrentMap存储的持有状态）。如果还持有，它就向Redis发送一个PEXPIRE命令，将锁的过期时间重新刷新为30秒。
4. 只要业务线程没执行完，这个续期操作就会一直进行，实现“锁的永生”。直到业务线程主动解锁，或者客户端节点宕机（看门狗任务随之停止），锁才会在最后一次续期后的30秒自动过期。

为什么设置了leaseTime就看门狗就失效了？ 因为Redission认为，你既然传了leaseTime，就是想要精确控制锁的持有时间，避免因为某种原因（比如你的程序bug）导致锁永远无法释放。此时，它把锁设置成一个“定时炸弹”，时间一到自动销毁，不提供续期服务。这本身是个好设计，但问题在于，很多开发者低估了业务的执行时间，或者没考虑到GC停顿、网络IO波动等意外情况，导致业务没执行完，锁却先“自杀”了。

2.3 冲突的根源：状态不一致的“幽灵锁”

理解了上面两点，我们就能梳理出异常发生的几条典型路径：

1. 路径一：锁提前过期，线程解锁“空气锁”。

   • 场景：使用了lock(10, SECONDS)，业务执行了15秒。
   • 过程：第10秒，锁因租约到期，被Redis自动删除。第15秒，业务线程执行到finally块，调用unlock()。
   • 结果：Redission客户端向Redis发送解锁命令（Lua脚本）。脚本发现锁key已经不存在，或者存在但value（持有者标识）对不上（因为锁可能已被其他节点获取）。于是抛出异常。

2. 路径二：线程复用与锁状态残留。

   • 场景：Web应用或线程池环境下，线程A刚处理完一个请求并释放了锁（但Redis删除操作稍有延迟），紧接着又被调度来处理新请求，新请求尝试获取同一把锁。
   • 过程：线程A在新请求中调用lock()。Redission客户端可能先检查本地状态，如果本地状态清理不及时，可能产生误判。更复杂的情况是，在极端高并发下，锁的获取和释放命令在网络上乱序了。
   • 结果：线程以为自己拿到了锁，实际上锁的归属已经混乱，后续解锁时必然失败。

3. 路径三：网络分区与脑裂下的双重持有。

   • 场景：发生网络分区，客户端和Redis集群失联一段时间后又恢复。
   • 过程：在失联期间，客户端认为锁还持有（看门狗续期失败），但Redis端可能因过期已释放锁，并被分区另一侧的客户端获取。网络恢复后，两个客户端都认为自己是锁的持有者。
   • 结果：一方执行解锁操作时，会遇到node id不匹配的异常。这是分布式系统CAP理论下的经典难题，Redission的锁也无法完全避免，但好的使用模式可以降低其影响。

这些根源都指向一点：客户端本地感知的锁状态与Redis中心存储的实际锁状态，出现了不一致。 我们的优化目标，就是通过各种手段，尽可能减少这种不一致的发生概率，并在不一致发生时，能够安全、优雅地处理，而不是粗暴地抛出异常导致流程中断。

3. 实战优化方案：从tryLock到防御式编程

知道了原理，我们就可以对症下药了。直接照搬网上“加个判断再解锁”的代码片段可能暂时解决问题，但要想系统更稳健，我们需要一套组合拳。下面是我在多个生产环境中总结验证过的优化方案。

3.1 首选方案：使用tryLock()并严格校验持有权

这是最推荐，也是最能从根本上规避异常的做法。核心思想是：将“加锁”从一个可能阻塞的被动操作，变为一个主动获取、明确知晓结果的主动操作，并在解锁前进行防御性检查。

具体代码模板如下：

import org.redisson.api.RLock;
import java.util.concurrent.TimeUnit;

public class LockService {
    private RedissonClient redissonClient;
    private static final String LOCK_KEY = "MY_BUSINESS_LOCK";

    public void doBusiness() {
        RLock lock = redissonClient.getLock(LOCK_KEY);
        boolean isLockAcquired = false; // 明确标记锁是否获取成功
        try {
            // 主动尝试获取锁，最多等待2秒，锁持有超时设为30秒
            isLockAcquired = lock.tryLock(2, 30, TimeUnit.SECONDS);
            if (isLockAcquired) {
                // 成功获取锁，执行核心业务逻辑
                executeCoreBusiness();
            } else {
                // 获取锁失败，进行降级处理：快速失败、排队、记录日志等
                handleLockFailure();
                return; // 关键！没拿到锁，直接返回，不会执行finally中的解锁逻辑
            }
        } catch (InterruptedException e) {
            // 处理线程中断，这是良好的编程习惯
            Thread.currentThread().interrupt();
            handleInterruption();
            return;
        } finally {
            // 只有在成功获取锁的情况下，才尝试解锁
            if (isLockAcquired) {
                // 防御式解锁：双重校验
                if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                    try {
                        lock.unlock();
                        log.info("锁释放成功");
                    } catch (IllegalMonitorStateException e) {
                        // 即使校验后仍发生异常，记录日志但不要抛出，避免掩盖业务异常
                        log.warn("解锁时发生预期外状态异常，锁可能已自动过期或由其他线程释放", e);
                    }
                } else {
                    log.debug("锁已被释放或不属于当前线程，无需解锁");
                }
            }
        }
    }

    private void executeCoreBusiness() {
        // 你的业务代码
        // 注意：业务执行时间应远小于锁的超时时间（如30秒），建议设置一个监控告警
    }

    private void handleLockFailure() {
        // 获取锁失败的逻辑：返回友好提示、放入队列稍后重试、触发降级策略等
        log.warn("未能获取分布式锁，资源繁忙");
    }
}

这个方案好在哪里？

1. 状态明确：tryLock的返回值isLockAcquired清晰地告诉我们本次操作是否拿到了锁。没拿到，流程直接转向失败处理，逻辑清晰。
2. 避免误解锁：这是最关键的一点。只有isLockAcquired为true的线程，才有资格进入解锁流程。这从根本上防止了“没抢到锁却尝试解锁”的乌龙事件。
3. 双重安全校验：在解锁前，使用lock.isLocked()和lock.isHeldByCurrentThread()进行双重检查。这虽然不能100%避免极端并发下的状态不一致（因为在检查和执行解锁之间仍有一微小间隔），但能拦截掉99%的错误场景，比如锁已自动过期的情况。
4. 异常隔离：即使在双重校验后仍然抛出异常（概率极低），我们在catch块里也只是记录警告日志，而不是抛出异常。这保证了业务主流程的异常不会因为一个辅助性的锁清理操作而中断，符合“防御式编程”的思想。

3.2 锁超时时间设置的黄金法则

如果你因为某些原因必须使用lock.lock(leaseTime, TimeUnit)，或者在使用tryLock(waitTime, leaseTime, TimeUnit)时，对leaseTime的设置必须非常谨慎。

错误示范：

// 业务可能执行几十秒，却只给锁5秒生命，必出问题。
lock.tryLock(2, 5, TimeUnit.SECONDS);

黄金法则：

锁的超时时间 (leaseTime) > 业务最大可能执行时间 + 网络与GC缓冲时间

你需要做的是：

1. 评估业务耗时：通过日志、APM工具（如SkyWalking, Pinpoint）统计你业务方法在99%或99.9%情况下的执行时间。假设是P99=20秒。
2. 增加安全缓冲：考虑到Full GC停顿、网络瞬时抖动、依赖服务慢查询等因素，增加一个缓冲时间。比如5-10秒。
3. 设置超时时间：那么你的leaseTime至少应该设置为30秒以上。
4. 设置等待时间：waitTime（尝试获取锁的最大等待时间）应该设置得较短，比如1-3秒。在分布式环境下，长时间阻塞等待锁会急剧降低系统吞吐量，并增加死锁风险。快速失败然后通过重试或降级策略处理是更好的方式。

一个实用的配置表格参考：

业务场景	预估业务最大耗时	建议缓冲时间	最终leaseTime设置	建议waitTime设置	备注
简单查询/缓存更新	1-2秒	3秒	5-10秒	1秒	短平快操作，锁持有时间应尽量短。
复杂计算/单次批处理	10-20秒	10秒	30秒	2-3秒	需要为GC和IO留足缓冲。
外部系统调用/文件处理	30-60秒	20秒	90秒+	3-5秒	依赖外部系统，不确定性高，超时需设置更长，并强烈建议使用tryLock模式。
未知或波动大	难以评估	-	使用无参lock()	使用tryLock(短等待)	最推荐！让看门狗自动续期，避免手动评估失误。

3.3 结合看门狗：如何正确使用lock()

对于执行时间不确定，或者你不想费心去评估超时时间的业务，请务必使用无参的lock.lock()方法，让看门狗为你保驾护航。

这里有个重要技巧：合理配置lockWatchdogTimeout。 默认30秒的看门狗超时对于很多业务可能太短了。你可以在初始化RedissonClient时进行全局配置：

Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
// 将看门狗超时时间调整为60秒
config.setLockWatchdogTimeout(60000L); // 单位：毫秒
RedissonClient redisson = Redisson.create(config);

将超时时间调长，比如60秒，意味着看门狗每次续期都会把锁的生命刷新到60秒，这给了业务更充裕的执行时间，同时续期间隔变为20秒（60 * 1/3），对Redis的压力增加也不大。这是一个在安全性和性能之间很好的平衡点。

记住一个口诀：想省心，用无参lock()；要精准，慎用带参lock()，且时间务必留足余量。

4. 进阶：在高并发与复杂场景下的加固策略

对于秒杀、全局配置更新等超高并发场景，或者微服务架构下的复杂调用链，仅仅优化锁的使用方式可能还不够。我们需要更系统的加固策略。

4.1 设计降级与熔断机制

分布式锁是保证强一致性的手段，但它本身也可能成为系统的单点或瓶颈。你的业务逻辑不能完全依赖锁一定获取成功。

• 降级：当获取锁失败时，不能只是抛异常。可以返回一个用户友好的提示（“系统繁忙，请稍后再试”）、将请求放入队列异步处理、或者返回一个缓存中的稍旧但可用的数据。
• 熔断：如果连续多次获取某个特定资源的锁都失败，可能意味着锁服务或底层Redis出现问题了。此时可以触发熔断，在一段时间内直接走降级逻辑，避免无意义的重试拖垮系统。

// 一个简单的熔断器思路（伪代码）
public class LockServiceWithCircuitBreaker {
    private CircuitBreaker circuitBreaker = new CircuitBreaker(5, 60000); // 5次失败，熔断1分钟

    public void doBusiness() {
        if (circuitBreaker.isOpen()) {
            // 熔断器打开，直接降级
            fallback();
            return;
        }

        try {
            if (tryAcquireLock()) {
                executeCoreBusiness();
            } else {
                circuitBreaker.recordFailure(); // 记录失败
                fallback();
            }
        } catch (Exception e) {
            circuitBreaker.recordFailure();
            throw e;
        } finally {
            // ... 解锁逻辑
        }
    }
}

4.2 为锁添加监控与告警

锁的状态是系统健康度的重要指标。你需要监控：

• 锁等待时间：tryLock的waitTime参数的实际消耗时间。如果平均等待时间持续增长，说明资源竞争激烈。
• 锁获取失败率：获取锁失败的次数比例。失败率飙升是系统过载或锁设计有问题的信号。
• 锁持有时间：业务执行期间锁被持有的时间。如果持有时间经常接近或超过超时时间，非常危险，需要优化业务或调整超时配置。

将这些指标接入你的监控系统（如Prometheus+Grafana），并设置告警规则。例如：“锁持有时间超过超时时间的80%”时发出警告。

4.3 避免锁的滥用与粒度控制

这是很多新手容易犯的错误：用一把大锁锁住整个服务或整个数据库表。

• 细化锁粒度：锁的粒度应该尽可能小。比如，不要锁“用户下单”，而是锁“用户A的下单”或“商品SKU_12345的库存”。使用业务标识作为锁key的一部分，例如 LOCK:ORDER:USER_{userId} 或 LOCK:INVENTORY:SKU_{skuId}。
• 减少锁持有时间：只把真正需要互斥执行的代码块放在锁内。锁外尽可能完成一些准备操作，如参数校验、数据查询等。
• 考虑替代方案：是不是一定要用分布式锁？对于库存扣减，使用Redis的DECR原子操作可能更高效；对于状态更新，使用数据库的乐观锁（版本号）可能更轻量。

4.4 处理“僵尸锁”与节点宕机

即使有看门狗，客户端节点突然宕机（kill -9，机器断电）也可能会导致锁无法释放，形成“僵尸锁”，直到超时过期。为了应对这种情况：

• 可以适当调低lockWatchdogTimeout，让僵尸锁更快自动释放，但这会增加正常业务下网络波动导致锁意外释放的风险，需要权衡。
• 在一些极端重要的场景，可以增加一个后台清理任务，定期扫描并释放那些持有时间异常长（比如超过正常业务时间数倍）且没有活跃心跳（需要业务侧自己记录）的锁。但这实现复杂，一般不推荐。

5. 排查工具箱：当异常再次发生时

即使做了所有优化，在复杂的生产环境中，奇怪的问题可能还是会偶尔出现。这时你需要一个清晰的排查思路。

1. 第一步：看日志，定位现场

   • 找到异常堆栈，确认是哪里调用的unlock。
   • 查看异常发生前后，关于加锁、业务执行、解锁的日志，还原执行序列。

2. 第二步：查Redis，看锁状态

   • 连接到Redis，用GET {lock_key}命令查看锁key对应的value。这个value就是Node ID + 线程ID。
   • 用TTL {lock_key}查看锁的剩余生存时间。如果TTL是-2（key不存在）或value对不上，问题就找到了。
   • 小技巧：可以在加锁成功时，把Node ID和线程ID记录到日志或MDC中，出问题时直接拿来和Redis里的value对比。

3. 第三步：分析时间线

   • 对比业务开始时间、锁获取时间、异常发生时间。
   • 计算业务执行耗时是否超过了锁的leaseTime。
   • 检查是否有长时间的GC停顿（查看GC日志）。

4. 第四步：复现与压测

   • 如果问题难以定位，尝试在测试环境复现。使用jmeter或gatling模拟高并发场景。
   • 重点关注线程池配置、锁超时时间设置、以及是否有异步任务在操作同一把锁。

我印象最深的一次排查，最后发现是因为一个同事在锁内部调用了另一个也用了同一把锁的RPC方法，形成了隐式的“锁重入”，但解锁顺序不对，导致了状态混乱。所以，保持锁内代码的简洁和透明至关重要。

说到底，分布式锁是一个强大的工具，但也是一个精细的活。它要求我们对并发、网络、超时有着深刻的理解。从lock.lock()到lock.tryLock()的转变，从不做校验到防御式解锁，每一步都是为了让系统在分布式的不确定性中，行为更加确定和可靠。希望这些从实际坑里总结出来的经验，能帮你把Redission用得更加得心应手。