Redis分布式锁之锁续期的源码透析！针针见血！

时间为何无法评估？

你是否一定会有这样的疑问：一个同步代码块，逻辑很简单，完全可以预估一个时间。如果预估不准，通过测试取一个平均时间然后稍微做些预留即可，就可以满足我们对锁设置过期时间的评估。

可是对时间的评估并不仅限于简单的业务逻辑，比如像这样一个简单逻辑：判断某条数据是否在数据库中已经存在，如果存在将某个字段更新。逻辑很简单，但是你是否考虑过网络延时导致数据库的链接建立时间较长、连接池中的链接数量不足需要阻塞等待、数据更新的时候需要等待一把较长时间才能释放的写锁等等一系列不可抗拒的因素引发的代码执行时长过大。

当然除了这些，可能代码逻辑本身也可能存在死锁或者远程接口调用超时等。列举的这些操作都有可能会产生代码的执行时间超出我们的预期。

总之，我们不能够对于同步代码块的执行时间过于理想化地评估，毕竟掺杂着网络、存储、锁 等因素，一切的一切并不是那么的靠谱。

顺便提一嘴，是不是可以将锁时间设置长一点，比如一个小时。如果一切进展顺利，不会有问题。可是您是否还记得如果锁释放之前，进程异常终止的这种情况？也就意味着，当进程恢复后必须等到锁过期释放，同步代码才能继续，业务才能继续。所以，合理设置一个过期时间非常重要！

什么是锁续期？

如果您是一个Java开发者，那么你很幸运。基于Java代码实现的Redission框架，它实现concurrent的Lock接口，友好地封装锁的实现，并且对锁过