redisson分布式锁源码和原理浅析

最新推荐文章于 2024-07-31 09:48:24 发布

天涯泪小武

最新推荐文章于 2024-07-31 09:48:24 发布

阅读量1.7w

点赞数 9

分类专栏： redis 架构文章标签： redisson分布式锁原理 redisson分布式锁

武伟峰原创文章，转载请注明地址http://blog.csdn.net/tianyaleixiaowu。

本文链接：https://blog.csdn.net/tianyaleixiaowu/article/details/96112684

版权

架构同时被 2 个专栏收录

39 篇文章 21 订阅

订阅专栏

redis

14 篇文章 6 订阅

订阅专栏

之前写过一篇使用redisson完成简单的分布式锁的文章，https://blog.csdn.net/tianyaleixiaowu/article/details/90036180

在redisson之前，很多人可能已经自己实现过基于redis的分布式锁，本身原理也比较简单，redis自身就是一个单线程处理器，具备互斥的特性，通过setNx，exist等命令就可以完成简单的分布式锁，处理好超时释放锁的逻辑即可。

redisson在此基础上，加上了更多的逻辑控制和功能，譬如公平锁等。这一篇我们就来看看redisson是如何完成分布式锁的。

先是使用锁的地方，在上一篇里已经用了。先获取RLock对象，调用lock、tryLock方法来完成加锁的功能。之后执行完毕需要被加锁的逻辑后，释放锁。

lock方法是直接加锁，如果锁已被占用，则直接线程阻塞，进行等待，直到锁被占用方释放。

tryLock方法则是设定了waitTime（等待时间），在这个等待时间没到前，也是线程阻塞并反复去获取锁，直到取到锁或等待时间超时，则返回false。

这里就以tryLock的源码为例来看看。pom里依赖的redisson版本是

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
        long time = unit.toMillis(waitTime);
        long current = System.currentTimeMillis();
        long threadId = Thread.currentThread().getId();
        //尝试获取锁，如果没取到锁，则获取锁的剩余超时时间
        Long ttl = tryAcquire(leaseTime, unit, threadId);
        // lock acquired
        if (ttl == null) {
            return true;
        }
        //如果waitTime已经超时了，就返回false
        time -= System.currentTimeMillis() - current;
        if (time <= 0) {
            acquireFailed(threadId);
            return false;
        }
        
        current = System.currentTimeMillis();
        RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
        if (!await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
            if (!subscribeFuture.cancel(false)) {
                subscribeFuture.onComplete((res, e) -> {
                    if (e == null) {
                        unsubscribe(subscribeFuture, threadId);
                    }
                });
            }
            acquireFailed(threadId);
            return false;
        }

        try {
            time -= System.currentTimeMillis() - current;
            if (time <= 0) {
                acquireFailed(threadId);
                return false;
            }
            //进入死循环，反复去调用tryAcquire尝试获取锁，ttl为null时就是别的线程已经unlock了
            while (true) {
                long currentTime = System.currentTimeMillis();
                ttl = tryAcquire(leaseTime, unit, threadId);
                // lock acquired
                if (ttl == null) {
                    return true;
                }

                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(threadId);
                    return false;
                }

                // waiting for message
                currentTime = System.currentTimeMillis();
                if (ttl >= 0 && ttl < time) {
                    getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } else {
                    getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
                }

                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(threadId);
                    return false;
                }
            }
        } finally {
            unsubscribe(subscribeFuture, threadId);
        }
//        return get(tryLockAsync(waitTime, leaseTime, unit));
    }

可以看到，其中主要的逻辑就是尝试加锁，成功了就返回true，失败了就进入死循环反复去尝试加锁。中途还有一些超时的判断。逻辑还是比较简单的。

再看看tryAcquire方法

这个方法的调用栈也是比较多，之后会进入下面这个方法

该方法就是与redis通信的地方，通过exists key的方法来判断是否已经上锁，如果没锁，则会返回null，锁了则返回超时时间。

回到那个死循环的地方：

这里有一个针对waitTime和redis锁住的key的超时时间大小的比较，取到二者中比较小的那个值，然后用java的Semaphore信号量的tryAcquire方法来阻塞线程。

那么Semaphore信号量又是由谁控制呢，何时才能release呢。这里又需要回到上面来看。

注意这个subscribe方法，它会进入到PublishSubscribe.java中

在这里可以看到，将当前的threadId添加到一个AsyncSemaphore中，并且设置一个redis的监听器，这个监听器是通过redis的发布、订阅功能实现的。如果不了解redis发布订阅的可以去百度查查。一旦监听器收到redis发来的消息，就从中获取与当前thread相关的，如果是锁被释放的消息，就立马通过操作Semaphore来让刚才阻塞的地方释放。