redis面试（八）watchdog看门狗代码逻辑

某个客户端上锁了之后，一直比如过了5分钟，10分钟，都没释放掉这个锁，那么你觉得会怎么样呢？锁对应的key刚开始的生存周期其实就是30秒而已，难道是默认情况下30秒后这个锁就自动释放？？？

lock watchdog，你对anyLock这个key加锁了以后，然后后台有一个定时调度的一个watchdog任务，这个任务的话呢其实就是每隔一定时间，10秒左右，延长一下anyLock这个key的生存周期，重新延长到30秒

只要你的这个lock没有释放掉，那么这个后台的watchdog他就会不断的去重复延长这个key的生存周期，对应的就是你的客户端长期的5分钟，10分钟，30分钟，一直持有了某一个key对应的分布式锁

首先从源码的层面，带着大家来看一下，如果你成功的对某个key加锁了之后，后台的定时调度任务（lock watchdog）是如何每隔10秒钟去延长一下那个key的生存时间的？
RFuture ttlRemainingFuture = tryLockInnerAsync()
我们上一节可以知道，tryLockInnerAsync这个方法中返回的是lua脚本执行之后，得到的这个key剩余的存在时间，不传的话默认是3000毫秒，也就是3秒钟。
那看下面的addListener()逻辑，这一看就是要加一个监听。
首先(!future.isSuccess()) 先判断上面加锁是否成功，如果不成功的话就直接返回不用管了，成功的话就取出来当前的剩余有效期，有效期也不为空的话，就去执行监听逻辑
还有一个判断，是返回值是否为null，如果为null的话才是加锁成功，不为null的话是失败
scheduleExpirationRenewal()方法 按照字面意思看的话，就是时间 过期 更新 。很明显，这里一定和看门狗逻辑有关系。 我们去看看里面的逻辑

第一行很简单expirationRenewalMap.containsKey(getEntryName())
就是判断