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

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

 1.相同客户端线程是如何实现可重入加锁的？
 2.其他线程加锁失败时，底层是如何实现阻塞的？
 3.客户端宕机了，锁是如何释放的？
 4.客户端如何主动释放持有的锁？
 5.客户端尝试获取锁超时的机制在底层是如何实现的？
 6.客户端锁超时自动释放机制在底层又是如何实现的？

Redis可重入锁的核心流程–可重入锁的加锁机制

 （1）相同线程重复加锁-重入加锁 ,下执行加锁的脚本：

记得第一次加锁时，key是不存在的，所以那时我们才能成功将当前线程的信息、设置到key的hash数据结构中，表示当前线程已经加锁成功。
但是现在是相同线程再次过来对同一key加锁，那么key已经存在这个条件当然就不成立了，接下来就到下一个if分支。

下一个if分支逻辑为：
hexists anyLock UUID:ThreadId
也就是判断当前key是否被当前线程持有，因为是相同的线程再次对同一个key加锁，此时当然能够在key中的hash数据结构中找到记录，所以条件成立，执行如下指令：
hincrby KEYS[1] ARGV[2] 1 即 hincrby anyLock UUID:ThreadId 1
表示对anyLock这个key中的hash数据结构里面的UUID:ThreadId的value增加1

从：
anyLock {
UUID:ThreadId 1
}

变为：
anyLock {
UUID:ThreadId 2
}

然后再对key重置过期时间为30s

key的hash数据结构中，UUID:ThreadId对应的1到底是什么意思呢？其实就是线程对key加锁的次数；当一个线程第一次过来加锁，线程当然就只是加了一次锁而已，所以对应key中的UUID:ThreadId对应的value值当然就是1；那现在我们看到线程第二次过来对同一个key加锁，那当然就是对应2了，表示当前线程对这个key加了两次锁了，这就是重入加锁。

然后重入锁加成功之后，当然也是后台开启一个watchdog后台线程，每隔10s检查一下key，如果key存在就重置key的过期时间为30s。
这下我们又知道了，原来Redisson可重入加锁的语义，竟然是通过key中某个线程标识UUID:ThreadId对应的加锁次数来表示的。

此时整体流程进度如下图所示：

其他线程重复加锁阻塞

其他线程过来加锁时，当然也是要执行这个加锁的脚本，如下图：

只不过其他线程过来对同一key重复加锁时：
首先第一个if条件，根据上文我们已经知道，当前key已经被第一个线程持有了，不成立；
第二个if条件，因为持有key的锁不是当前线程，所以也不成立，所以此时就只能来到最后的一步：

pttl anyLock

表示返回当前key的剩余存活时间，因为不是返回nil，这下加锁当然就失败了。

此时我们就需要看一下加锁失败后，将会执行什么逻辑，如下图：

不管是第一次加锁成功、同一线程重复过来重入加锁成功，lua脚本都会返回nil即返回空，下一步直接开启watchdog后台定时任务，每隔10s定时检查key并续期。
同时在上图的第一部分的方法lockInterruptibly中，如果发现ttl为空就直接返回了。

但是现在，其他客户端线程过来对同一key加锁，加锁失败了，此时监听器中判断条件：
if (!future.isSuccess())
直接成立，当然就直接return返回了，但是这也导致不会开启watchdog定时任务了。

这时它在方法lockInterruptibly中会进入一个while的死循环中，大概每次休息ttl的时间之后，ttl就是当前key还存活的时间，每次获取失败我就先等ttl时间，然后再去尝试一下加锁，期盼着有朝一日能获取到锁、好跳出这个while的死循环中。

当一个线程对一个key加锁成功后，那么其他的线程也想要过来加锁时、就是这样一直被耗在while循环中的，这样不就实现阻塞了吗。