Spring Integration分布式锁TTL与Redisson租期的设计差异咨询

这是对Spring Integration Issue #8687的跟进，该Issue提到Spring Integration分布式锁的TTL概念仅适用于跨进程场景，不适用于同进程内的线程竞争场景。

我后续尝试了Redisson，其RLock接口包含lease time（租期）概念，相关方法定义如下：

/**
 * Tries to acquire the lock with defined <code>leaseTime</code>.
 * Waits up to defined <code>waitTime</code> if necessary until the lock became available.
 *
 * Lock will be released automatically after defined <code>leaseTime</code> interval.
 *
 * @param waitTime the maximum time to acquire the lock
 * @param leaseTime lease time
 * @param unit time unit
 * @return <code>true</code> if lock is successfully acquired,
 *          otherwise <code>false</code> if lock is already set.
 * @throws InterruptedException - if the thread is interrupted
 */
boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;

我认为TTL与lease time概念相似（如有误请指正），但两者表现存在差异：Redisson的租期在跨进程和同进程线程场景下行为一致，而Spring Integration的TTL仅在跨进程场景生效。

差异复现方式 #

• 依赖环境启动命令：

docker run -p 6379:6379 -d redis:7.0.12 --requirepass "mypass"

docker run -e POSTGRES_USER=localtest -e POSTGRES_PASSWORD=localtest -e POSTGRES_DB=orders -p 5432:5432 -d postgres:15.3

# 运行JUnit测试前需启动上述容器

• 测试逻辑：通过JUnit测试模拟同进程内多线程竞争锁的场景，观察TTL/租期过期后其他线程是否能获取锁。
• 模式切换：通过修改配置文件中的锁注册器类型切换测试模式：

lock.registry.name=redisson
# 修改为 redis / jdbc / redisson 即可切换不同锁实现进行测试

测试结果 #

在Spring Integration的Redis/JDBC锁模式下，线程2即使在TTL过期后仍无法获取锁；而在Redisson模式下，线程2可在租期过期后正常获取锁，后者的逻辑在概念上更合理。

请问导致这种TTL/租期设计差异背后的考量是什么？

内容的提问来源于stack exchange，提问作者Cui Pengfei 崔鹏飞