Redisson项目中RLock多重锁定的时间重置问题分析

在分布式锁的实现中，Redisson作为Java客户端提供了RLock接口来实现可重入锁的功能。近期在版本3.19.2之后，用户报告了一个关于多重锁定场景下锁过期时间重置的异常行为。

问题现象

当使用RLock进行多重锁定时，即同一个线程多次调用lock()方法后，执行unlock()操作时，锁的剩余存活时间(remainTimeToLive)会被重置为配置的默认值（通常为30000毫秒），而非预期的锁定时间。例如以下代码：

RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("test-lock:1");
lock.lock(10, TimeUnit.SECONDS);
lock.lock(10, TimeUnit.SECONDS);
lock.unlock();
System.out.println(lock.remainTimeToLive()); // 输出接近30000而非10000

技术背景

Redisson的RLock实现了可重入锁机制，允许同一个线程多次获取同一个锁。在内部，它通过Redis的哈希结构维护锁的持有计数和过期时间。每次lock()调用会增加持有计数，而unlock()则会减少计数，当计数归零时才会真正释放锁。

问题根源

该问题源于3.19.2版本中对锁过期时间处理的逻辑变更。在多重锁定场景下，当执行unlock()操作时，系统错误地将锁的过期时间重置为配置的默认值，而非保留最初设置的过期时间。

影响范围

该问题影响从3.19.2到3.26.0的所有版本，主要影响以下使用场景：

1. 同一个线程多次获取同一个锁
2. 每次获取锁时指定了相同的过期时间
3. 需要准确获取锁剩余存活时间的应用

解决方案

Redisson开发团队已确认并修复了该问题。修复后的行为将保持以下原则：

1. 首次lock()调用设置的过期时间将作为基准
2. 后续多重lock()调用不会改变这个基准时间
3. 执行unlock()操作后，remainTimeToLive()将返回基于首次设置时间的准确剩余时间

最佳实践

在使用Redisson的可重入锁时，建议：

1. 避免在同一个代码块中多次调用lock()
2. 如需重入，考虑使用tryLock()配合适当的重试逻辑
3. 明确锁的获取和释放配对关系
4. 在关键路径上验证锁的剩余时间

该问题的修复确保了Redisson在分布式锁实现中的时间行为一致性，为依赖精确锁超时的应用提供了可靠保障。