JeecgBoot分布式锁机制优化：解决Redisson解锁异常问题

背景介绍

在JeecgBoot 3.7.2版本中，使用Redisson实现的分布式锁机制出现了一个典型问题：当尝试解锁时，系统抛出IllegalMonitorStateException异常，提示"attempt to unlock lock, not locked by current thread"。这个问题源于对Redisson锁机制的不当使用，特别是在解锁操作时没有正确检查锁状态和持有线程。

问题分析

Redisson作为Redis的Java客户端，提供了完善的分布式锁实现。其内部维护了看门狗机制(Watchdog)来自动续期锁的过期时间，确保长时间业务操作不会因锁过期而中断。然而，JeecgBoot原有的解锁实现直接调用了unlock()方法，没有考虑以下关键因素：

1. 锁是否仍然被持有
2. 当前线程是否是锁的持有者
3. 锁可能已经被自动释放的情况

这种粗放的解锁方式会导致两个主要问题：

• 当锁已被其他线程释放时，尝试解锁会抛出异常
• 可能干扰Redisson内部的看门狗续期机制

解决方案

优化后的解锁逻辑增加了必要的状态检查：

public void unlock(String lockName) {
    try {
        RLock lock = redissonClient.getLock(lockName);
        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    } catch (Exception e) {
        log.error("解锁异常，lockName=" + lockName, e);
    }
}

这个改进实现了：

1. 先检查锁是否仍然被持有(isLocked)
2. 确认当前线程是锁的持有者(isHeldByCurrentThread)
3. 只有满足上述条件才执行解锁操作

技术原理

Redisson的分布式锁实现有几个关键特性需要理解：

1. 看门狗机制：默认情况下，Redisson会为获得的锁启动一个后台线程，定期(默认10秒)检查并延长锁的过期时间(默认30秒)。这确保了长时间运行的业务不会因锁过期而中断。

2. 线程绑定：Redisson锁与获得它的线程绑定，其他线程无法直接解锁。这是抛出IllegalMonitorStateException的根本原因。

3. 锁状态检测：RLock接口提供了丰富的方法来查询锁状态，包括isLocked()和isHeldByCurrentThread()等。

最佳实践

基于这次优化经验，在使用Redisson分布式锁时建议：

1. 始终检查锁状态：在解锁前务必确认锁仍然有效且由当前线程持有
2. 合理设置超时：根据业务场景设置适当的锁超时时间，平衡安全性和性能
3. 异常处理：妥善处理锁操作可能抛出的各种异常
4. 资源释放：确保在finally块中释放锁，避免资源泄漏

总结

JeecgBoot通过这次优化，不仅解决了特定的解锁异常问题，更重要的是完善了分布式锁的使用规范。这种改进体现了对Redisson机制的深入理解和对系统稳定性的高度重视。对于基于JeecgBoot开发的系统，建议及时应用这一优化，以确保分布式锁的可靠性和稳定性。