Redisson分布式锁源码-可重入锁的八大机制-下(3)

Redisson分布式锁源码-可重入锁的八大机制-下(3)

尝试获取锁超时

   可以看到前面的各种分析都是对：lock.lock()  的加锁方式进行分析的，在这种方式下如果获取锁失败，我们都是知道它会进入一个while的死循
环中、间歇性的一直获取锁，相当于就阻塞住了。
   如果说你想要指定个时间，在这个时间内获取锁都失败的话就直接退出、保证不阻塞，此时可以通过如下方式加锁：
   
    lock.tryLock(30, 10, TimeUnit.MILLISECONDS);

   这里第一个参数就是指定了30s之内要是获取不到锁就自动放弃了，不再陷入while循环中不断无休止的尝试了，我们看下底层是如何实现的：

其实看到这里大概也就知道了，tryAcquire和之前执行的逻辑是一样的，执行加锁的入口：
如果ttl不为空就表示获取锁失败，此时像之前lock.lock()的方式，此时应该就是进入一个while死循环中一直阻塞住直到成功获取锁。

然而这里，已经指定了获取锁超时时间，此时可以看到时间指定超时时间waitTime赋值给了time，可以看到各种耗时操作都会导致time时间被扣减，redis底层订阅相关操作需要耗时、在while中重新尝试加锁时间也要被扣减，直到某一刻time已经小于等于0了，此时就会执行方法acquireFailed标记当前线程对key获取锁失败，然后直接return返回false，表示获取锁失败了。

所以说尝试获取锁超时的底层实现，只不过不会再给你一个while的死循环一直在那耗着，而是说在指定时间内，你一直去尝试获取，如果在指定时间内你还没加锁成功，就标记加锁失败并返回。
此时整体流程进度如下图所示：

锁超时自动释放锁

    同样当我们在获取锁的时候，如果采用：lock.tryLock(30, 10, TimeUnit.MILLISECONDS) 方式获取锁时，第二个参数就表示本次就算获取所
成功了，
    那么这把锁被线程最多只能被持有10s，10s之后这把锁将被释放，这块我们也看下源码是怎样实现的：

此时发现，当指定锁超时自动释放锁的时间后，参数leaseTime就为10，此时就会执行第一个逻辑分支，从上图代码我们可以看到，此时就算获取锁成功之后，也不会对获取锁的结果设置watchdog监听器了，也就不会维持加锁了。

这也就意味着当指定的时间过后，当前线程就会因为锁的过期时间到了而自动释放锁，锁超时自动释放说白了就是给你这个key的存活时间、设置为你自己指定的那个时间，而我在后台就不会给你添加一个watchdog机制来维持加锁了。

最终，完整的redis可重入锁执行的整体流程图如下图所示：