JeecgBoot分布式锁机制优化：解决Redisson看门狗机制冲突问题

背景介绍

在JeecgBoot 3.7.2版本中，开发团队发现了一个与分布式锁相关的重要问题。当系统使用Redisson作为分布式锁实现时，原有的解锁逻辑可能会破坏Redisson内置的看门狗机制，导致抛出IllegalMonitorStateException异常。

问题分析

Redisson作为Redis的Java客户端，提供了强大的分布式锁功能。其内部实现了一个称为"看门狗"的自动续期机制，当锁的持有时间超过一定阈值时，会自动延长锁的有效期，防止业务未执行完成时锁被意外释放。

JeecgBoot原有的解锁逻辑直接调用了redissonClient.getLock(lockName).unlock()，这种方式存在两个潜在问题：

1. 没有检查当前线程是否确实持有该锁
2. 可能干扰Redisson的看门狗续期机制

当多个线程并发操作时，可能会出现一个线程尝试释放另一个线程持有的锁，导致IllegalMonitorStateException异常，错误信息类似于："attempt to unlock lock, not locked by current thread"。

解决方案

优化后的解锁逻辑增加了两个关键检查：

1. lock.isLocked() - 检查锁是否被持有
2. lock.isHeldByCurrentThread() - 检查当前线程是否持有该锁

只有在两个条件都满足时，才会执行解锁操作。这种改进带来了以下优势：

• 避免了非法解锁操作
• 保持与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);
    }
}

最佳实践

在使用JeecgBoot的分布式锁功能时，建议开发者：

1. 确保锁的获取和释放成对出现
2. 在finally块中释放锁，避免异常导致锁无法释放
3. 合理设置锁的超时时间，避免长时间持有锁
4. 对于复杂的业务逻辑，考虑使用tryLock等更灵活的加锁方式

总结

这次优化解决了JeecgBoot与Redisson分布式锁机制的兼容性问题，提高了系统在高并发场景下的稳定性。通过增加必要的检查条件，既保证了锁的正确释放，又不会干扰Redisson内部的看门狗机制，为分布式系统的可靠运行提供了更好的保障。