lockrenewalfailedexception是自定义运行时异常，用于标识锁续期失败；需捕获redis连接中断、超时等底层异常，包装为含锁key、租期、线程id等上下文的自定义异常并抛出，同时触发解锁、告警与降级。
Java中分布式锁续期失败时，LockRenewalFailedException 并不是 JDK 或主流框架（如 Redisson、Curator）默认提供的异常类型。它通常是你自己定义的业务异常，用于明确标识“锁自动续期失败”这一关键错误场景。要正确抛出该异常，核心在于：捕获底层续期失败信号（如超时、连接中断、锁已丢失），并主动封装为自定义异常。
定义 LockRenewalFailedException
建议继承 RuntimeException，避免强制上层处理，符合分布式锁失败属于不可恢复的运行时问题的语义：
<font size="2"><pre class="brush:php;toolbar:false;">public class LockRenewalFailedException extends RuntimeException {<br> public LockRenewalFailedException(String message) {<br> super(message);<br> }<br><br> public LockRenewalFailedException(String message, Throwable cause) {<br> super(message, cause);<br> }<br>}
在 Redisson 中检测并抛出
Redisson 的 RLock 默认开启看门狗机制，但续期失败时可能静默终止后台任务。需监听续期异常或检查锁状态：
- 使用
lock.lockInterruptibly()加锁后，通过lock.expireAsync()手动续期，并监听 Future 异常 - 更可靠方式：启用 Redisson 的监控回调，重写
Config.setLockWatchdogTimeout()并结合日志/指标判断续期是否停滞 - 实际续期失败时（如 Redis 不可达），
expireAsync()返回的RFuture会完成异常，此时捕获并抛出自定义异常
在 Curator 中识别续期失败
Curator 的 InterProcessMutex 本身不自动续期，需手动调用 client.getConnection().getZooKeeper().exists() 或依赖 LeaderLatch 等机制。常见做法：
- 启动独立心跳线程，定期调用
mutex.acquire()验证锁有效性 - 若
ZooKeeper抛出KeeperException（如 ConnectionLoss、SessionExpired），说明会话失效、锁已释放，此时应立即抛出LockRenewalFailedException - 避免仅靠超时判断——必须确认 zk 节点路径不存在或版本变更
通用防护策略：续期失败后必须释放并告警
抛出异常只是第一步，关键是要防止“假持有”：
- 在
catch (LockRenewalFailedException e)块中，优先尝试unlock()（即使可能失败，也要执行） - 记录完整上下文：锁 key、租期、当前线程、节点 IP、续期尝试次数
- 触发告警（如发钉钉/邮件），因为续期失败往往预示着网络分区、Redis 崩溃或 GC 导致线程长时间停顿
不复杂但容易忽略：异常类型要统一，所有分布式锁实现都应转换为同一异常，便于上层统一熔断或降级。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
