weixiaohuai的博客

RCountDownLatch的功能跟CountDownLatch，用于实现某个线程需要等待其他线程都完成之后，我再去执行，这种场景就可以使用CountDownLatch。同样，在redis中写入了一个 {key}:{计数器总数}的String类型的数据。减少锁存器的计数器。当计数达到零时通知所有等待线程。

基于Redis的Redisson的分布式信号量RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。

红锁其实也并不能解决根本问题，只是降低问题发生的概率。完全相互独立的redis，每一台至少也要保证高可用，还是会有主从节点。既然有主从节点，在持续的高并发下，master还是可能会down机，从节点可能还没来得及同步锁的数据。很有可能多个主节点也发生这样的情况，那么问题还是回到一开始的问题，红锁只是降低了发生的概率。其实，在实际场景中，红锁是很少使用的。这是因为使用了红锁后会影响高并发环境下的性能，使得程序的体验更差。所以，在实际场景中，我们一般都是要保证Redis集群的可靠性。

KEYS[3]: 等待队列中线程锁时间的set集合名称，redisson_lock_timeout:{分布式锁key}，是按照锁的时间戳存放到集合中的。KEYS[4]: 释放锁时发布消息的channel通道，redisson_lock__channel:{分布式锁key}，。KEYS[1]: 我们指定的分布式锁的key，如本例中redissonClient.getFairLock("fairLock")的 "fairLock"ARGV[2]: 锁的超时时间，本例中为锁默认超时时间：30000毫秒（30秒）

通过lindex指令获取redisson_lock_queue:{fairLock}在List等待队列的第一个元素，因为此时t2、t3线程都在等待队列中，所以会执行zscore redisson_lock_timeout:{fairLock} d23e0d6b-437c-472c-9c9d-2147907ab8f9:47，从zset有序集合中获取d23e0d6b-437c-472c-9c9d-2147907ab8f9:47对应的分数，也就是对应的过时时间，timeout = 1663143100976。

相比较Redisson可重入锁的加锁逻辑，释放锁的逻辑就相对简单一些。释放锁分为主动释放和自动释放两种方式。

本例中，我们没有指定超时时间，internalLockLeaseTime默认就是在RedissonLock构造方法中获取的看门狗超时时间30秒，那么30 / 3 = 10秒，也就是看门狗将会延迟10秒启动第一次续期；可以看到，自动续期底层还是一段LUA脚本，通过hexists指令判断锁是不是自己的锁，如果是的话，则通过pexpire指令将锁的过期时间给重置为30秒，返回1，表示自动续期成功；从源码中可以看到，Redisson的看门狗借助了netty的时间轮，简单理解就是定时任务，对分布式锁进行自动续期的。

当获取锁失败之后，首先会通过subscribe()订阅【"redisson_lock__channel" + 锁key】的消息，也就是订阅锁释放的消息，当前持有锁的线程在释放锁之后，会通过publish指令发布一条消息，这样之前获取锁失败的那些线程就知道锁已经被释放了，可以获取了。Redisson可重入锁实现互斥的关键，就是上述的第三种情况，获取锁失败后，返回锁剩余的过期时间。如上代码，可以看到，lock()方法加锁成功后，会返回nil，此处会判断为 null，直接返回。

加锁的逻辑基本上都在LUA脚本里面了，可以看到，当执行LUA脚本返回nil的时候，表示锁获取成功，否则返回的是锁剩余的过期时间，即其他线程需要等待的时间。KEYS[1]: Collections.singletonList(getRawName()) ==> 我们指定的分布式锁的key。redis key = lock，这个lock就是我们前面通过redissonClient.getLock("lock")指定的；从上面的代码可以看出，Redisson内部实际上就是通过一段LUA脚本来进行加锁的。