分布式锁超时应设为锁初始有效期而非业务时限，推荐p95耗时+缓冲并配合redisson看门狗或主动续期；显式指定leasetime会禁用看门狗；需避免超时过短导致重复执行或过长引发锁残留。

在分布式系统中，用注解配置分布式锁的超时时长，核心是把“锁生命周期”和“业务执行时间”解耦，避免因预估不准导致锁提前释放或长期占用。关键不在于写死一个数字，而在于让锁能自适应业务实际耗时——尤其是配合 Redisson 的看门狗机制或自定义续期逻辑。

明确超时参数的实际含义

使用注解时常见的超时字段（如 leaseTime 或 expire）不是“业务必须在这个时间内完成”，而是：

• 锁的初始有效期：Redis 中 key 的 TTL，即从加锁成功那一刻起，最多保留多久
• 它必须大于绝大多数正常执行路径的耗时，但不宜过大（比如设成 24 小时），否则节点宕机后锁残留时间过长
• 若业务耗时波动大（如依赖外部 HTTP 调用），建议设为 P95 耗时 + 缓冲（例如 8 秒 + 2 秒 = 10 秒），再交由续期机制兜底

基于 Redisson 注解配置 leaseTime

Redisson 提供了开箱即用的注解支持（需引入 redisson-spring-boot-starter），直接控制超时：

• 使用 @RLock 或自定义注解（如 @RedisLock(expire = 10)），其中 expire 单位为秒，对应底层 lock.lock(10, TimeUnit.SECONDS)
• 更推荐用带等待时间的变体：lock.tryLock(3, 10, TimeUnit.SECONDS) —— 最多等 3 秒获取锁，拿到后持有 10 秒
• 注意：不传 leaseTime 时，Redisson 默认启用看门狗（watchdog），每 10 秒自动续期一次，续期时间为 30 秒；一旦显式指定 leaseTime，看门狗将被禁用，锁到期即释放

自定义注解实现动态超时与续期

当固定超时不够灵活（比如不同方法差异大、或需按环境区分），可扩展注解支持运行时计算：

• 在注解中增加 SpEL 表达式支持，例如 @RedisLock(spelTimeout = "#{@timeoutService.getTimeout(#root.methodName)}")
• 切面解析表达式，调用业务类获取真实超时值（如查配置中心、读 DB、结合请求参数计算）
• 对长时间任务，启动独立线程监控锁剩余时间；当 TTL lock.renewLease() 主动续期（需确保线程安全）

避坑要点：超时设置不当的典型后果

错误配置会直接引发数据错乱或雪崩，务必验证：

• 超时太短：锁在业务中间被释放，其他节点闯入，出现重复扣款、并发生成重复单据
• 超时太长 + 无续期：节点崩溃后锁长期残留，整个功能不可用，直到超时自动清理
• 未校验锁归属就删除：A 拿到锁，执行慢；B 等待超时后误删 A 的锁，导致双写
• 跨线程续期失效：异步任务（如 @Async）在新线程执行，原锁对象不可见，需传递锁标识或改用 ThreadLocal 存储