JeecgBoot分布式锁机制与Redisson看门狗机制冲突解析

问题背景

在JeecgBoot 3.7.2版本中，用户在使用分布式锁功能时遇到了IllegalMonitorStateException异常。该异常表明当前线程尝试释放一个并非由它持有的锁，这种情况通常发生在分布式锁的实现机制出现问题时。

技术原理分析

Redisson分布式锁机制

Redisson作为Redis的Java客户端，提供了完善的分布式锁实现。其核心特性包括：

1. 看门狗机制：Redisson通过后台线程定期续期锁的有效期，防止业务执行时间超过锁过期时间导致的锁自动释放问题。
2. 线程绑定：每个锁都与获取它的线程ID绑定，确保只有持有锁的线程才能释放锁。
3. 锁状态检查：提供了isLocked()和isHeldByCurrentThread()等方法用于检查锁状态。

JeecgBoot原有实现的问题

原JeecgBoot的解锁实现直接调用unlock()方法，没有进行前置检查：

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

这种实现方式存在两个主要问题：

1. 线程安全性问题：可能尝试释放非当前线程持有的锁
2. 破坏看门狗机制：直接释放锁会中断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团队通过PR#36彻底解决了这个问题，主要改进包括：

1. 保持Redisson原生机制：尊重Redisson的看门狗设计，不强制中断锁的生命周期
2. 优化锁获取方式：采用更符合Redisson设计理念的锁管理策略
3. 异常处理完善：增强了对各种边界情况的处理能力

最佳实践建议

基于JeecgBoot和Redisson的分布式锁使用，我们建议：

1. 锁获取与释放配对：确保每个锁的获取都有对应的释放操作
2. 合理设置超时时间：根据业务场景设置适当的锁超时时间
3. 避免嵌套锁：尽量减少锁的嵌套使用，防止死锁
4. 资源清理：在finally块中确保锁的释放操作

总结

分布式锁的正确实现需要考虑多方面因素，包括线程安全、锁续期、异常处理等。JeecgBoot通过不断优化其分布式锁实现，既保证了业务功能的可靠性，又保持了与Redisson原生机制的兼容性。开发者在使用时应当理解底层机制，避免因不当使用导致的性能问题或功能异常。