锁租期一分钟但任务未完成时，会发生什么？

核心回答

如果是一分钟的固定租期，且没有成功续约，锁到期后其他客户端就可能重新获得锁；原任务通常不会因此被自动中断。于是旧任务还没结束、新任务又进入临界区，可能出现重复处理和并发写入。

关键要确认“一分钟”指的是固定 leaseTime，还是某种自动续约机制的租约周期。两者的行为不同。Redisson 普通 RLock 指定正的固定租期时，不能再假定看门狗会替它续期。

一个典型时间线

A 在第 0 秒取得锁，租期 60 秒；任务因为慢调用或长暂停未结束。到第 60 秒，若锁仍未续约，A 的租约失效。B 随后获取同一把锁并开始工作。A 在第 65 秒恢复后，可能仍按旧上下文继续操作共享资源。

锁服务只知道租约到期，并不知道 A 的业务线程是否已经停下。即使 A 在写入前检查“锁还在不在”，检查和真正写入之间仍可能过期，不能仅靠一次本地判断封闭竞争窗口。

怎样控制风险

任务时间可预测且临界区短时，可以选择覆盖实际耗时与合理波动的租期；时间不确定时，可使用到期前续约，并监控续约失败和剩余租期。但网络分区、GC 或进程暂停可能持续超过租约，续约不是绝对安全保证。

对重要写入，应让资源端参与判断。例如数据库按业务状态和版本条件更新，订单号唯一约束防止重复创建，或使用可靠生成且由下游原子校验的 fencing token 拒绝旧执行者。任务恢复与重试还需按业务幂等处理。

如果任务天然很长，可以拆成有明确状态和检查点的阶段，减少长时间持锁；对外副作用要记录请求与结果，避免重新接管后重复执行。

解锁时注意什么

解锁必须原子校验所有者，再释放对应的锁。A 的旧租约失效后，直接删除同名 Key 可能删掉 B 的新锁。Redisson 的持有线程语义也要求由合法所有者解锁；锁已丢失时出现异常，应按失去执行资格处理，不能吞掉后继续当成持锁成功。

常见追问

把租期改为十分钟呢？ 只是调整过早到期与故障接管速度的取舍，仍存在任务超时和暂停风险；业务约束和恢复设计同样必要。

参考资料