Redission源码详解

最新推荐文章于 2025-05-05 17:05:55 发布
最新推荐文章于 2025-05-05 17:05:55 发布
阅读量1.1k 收藏 6
点赞数 6
文章标签： java 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/ludkjava/article/details/141231254
版权

环境搭建

redis搭建

在本地搭建个redis，启动redis服务端和客户端。客户端是为了观察redis中锁的信息。

依赖

新建个SpringBoot项目，依赖Redission jar包

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson-spring-boot-starter</artifactId>
	<version>3.21.1</version>
</dependency>

工具类

@Service
public class RedisUtil {
    @Autowired
    private RedissonClient redissonClient;

    public  boolean tryLock(Long key){
        RLock rLock= redissonClient.getLock(String.valueOf(key));
        try {
            boolean lockResult=rLock.tryLock(10,30, TimeUnit.SECONDS);
            return lockResult;
        } catch (InterruptedException e) {
            e.printStackTrace();
            return false;
        }
    }
}

测试Controller

package com.ludk.weixin.controller;

import com.ludk.weixin.common.tool.RedisUtil;
import com.ludk.weixin.entity.Product;
import com.ludk.weixin.service.IProductService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.*;

import java.util.Collections;

@Controller
@Slf4j
@RequestMapping("/product")
public class ProductController {
    @Autowired
    RedisUtil redisUtil;




    @RequestMapping("/myProduct")
    @ResponseBody
    Object myProduct(@RequestParam("userId") Long userId){
        long before=System.currentTimeMillis();
        log.error("获取锁之前："+before);
        redisUtil.tryLock(userId);
        long after=System.currentTimeMillis();
        System.out.println("获取锁之后："+after);
        System.out.println((after-before)/1000);
        return productService.getMyProduct(userId);

}

源码思路分析

首先需要知道Redission实现的分布式锁有哪些特点？

  • 支持锁的超时，避免死锁。通过对Redis key设置超时时间实现。
  • 支持可重入锁，同一个线程可以多次获取锁。Redis中通过存储hash类型，其中一个字段记录次数实现。
  • 当线程A获取到锁执行业务逻辑且未执行完，如果锁超时，可以通过看门狗续锁的时间，避免其他线程获取锁。通过看门狗实现。

源码分析

初始化锁对象

主要是初始化默认锁的释放时间和uuid，下面会用到。

加锁方法

org.redisson.api.RLock#tryLock方法参数如下：

  • long waitTime：当获取锁失败时，等待waitTime时间后返回获取锁失败。
  • long leaseTime：锁释放时间，当获取到锁以后，这个锁多久失效。也就是redis中存储的锁的key的有效时间。
  • TimeUnit unit：上面两个时间的单位。
@Override
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
	//将锁的等待时间转为毫秒数
    long time = unit.toMillis(waitTime);
    //当前时间，从现在起算锁的等待时间
    long current = System.currentTimeMillis();
    //当前线程id，因为是可重入锁，需要用threadId区别是否是当前线程。
    long threadId = Thread.currentThread().getId();
    //获取锁，如果ttl 为null则说明获取锁成功。否则ttl代表这个锁还有多久超时，超时则当前线程有获取到锁的可能
    Long ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
    // lock acquired
    if (ttl == null) {
        return true;
    }
    // System.currentTimeMillis()是当前时间，current是进入tryLock这个方法的时间，time=time-(System.currentTimeMillis() - current)表示还有多少时间获取锁超时，time<=0就说明超时
    time -= System.currentTimeMillis() - current;
    if (time <= 0) {//获取锁超时，返回false。
        acquireFailed(waitTime, unit, threadId);
        return false;
    }
    //记录当前时间
    current = System.currentTimeMillis();
    //订阅监听redis消息，并且创建RedissonLockEntry，其中RedissonLockEntry中比较关键的是一个 Semaphore属性对象,用来控制本地的锁请求的信号量同步，返回的是netty框架的Future实现。
    CompletableFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
    try {
    	//添加锁的监听，如果锁释放，会进入监听类，将Semaphore释放
    	// 阻塞等待subscribe的future的结果对象，如果subscribe方法调用超过了time，说明已经超过了客户端设置的最大wait time，则直接返回false，取消订阅，不再继续申请锁了。
        subscribeFuture.get(time, TimeUnit.MILLISECONDS);
    } catch (TimeoutException e) {
        if (!subscribeFuture.completeExceptionally(new RedisTimeoutException(
                "Unable to acquire subscription lock after " + time + "ms. " +
                        "Try to increase 'subscriptionsPerConnection' and/or 'subscriptionConnectionPoolSize' parameters."))) {
            subscribeFuture.whenComplete((res, ex) -> {
                if (ex == null) {
                    unsubscribe(res, threadId);
                }
            });
        }
        acquireFailed(waitTime, unit, threadId);
        return false;
    } catch (ExecutionException e) {
        acquireFailed(waitTime, unit, threadId);
        return false;
    }

    try {
    	//经过上面的计算，time是还多长时间获取锁超时，time已经被减掉一部分了。这里继续把消耗的时间减掉。
        time -= System.currentTimeMillis() - current;
        if (time <= 0) {//time<0，获取锁超时，返回false，获取锁失败。
            acquireFailed(waitTime, unit, threadId);
            return false;
        }
    
        while (true) {//死循环，有两个点可以调出循环。获取锁成功跳出、获取锁超时（失败）跳出
            long currentTime = System.currentTimeMillis();
            ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
            // lock acquired
            if (ttl == null) {
                return true;
            }

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

            // waiting for message
            currentTime = System.currentTimeMillis();
            //下面的阻塞会在释放锁的时候，通过订阅发布及时获取锁
            if (ttl >= 0 && ttl < time) {//如果锁的超时时间小于等待时间，通过SemaphorerelaseryAcquire阻塞锁的释放时间
                commandExecutor.getNow(subscribeFuture).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
            } else {//否则，通过Semaphore的tryAcquire阻塞传入的最大等待时间
                commandExecutor.getNow(subscribeFuture).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
            }

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

org.redisson.RedissonLock#tryAcquire方法

private Long tryAcquire(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    return get(tryAcquireAsync0(waitTime, leaseTime, unit, threadId));
}

org.redisson.RedissonLock#tryAcquireAsync0方法

    private RFuture<Long> tryAcquireAsync0(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
        return getServiceManager().execute(() -> tryAcquireAsync(waitTime, leaseTime, unit, threadId));
    }

org.redisson.RedissonLock#tryAcquireAsync

private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    RFuture<Long> ttlRemainingFuture;
    if (leaseTime > 0) {//如果leaseTime >0，则传入锁释放时间，
        ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    } else {//否则用默认的锁释放时间30000ms
        ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,
                TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
    }
    CompletionStage<Long> s = handleNoSync(threadId, ttlRemainingFuture);
    ttlRemainingFuture = new CompletableFutureWrapper<>(s);

    CompletionStage<Long> f = ttlRemainingFuture.thenApply(ttlRemaining -> {
        // lock acquired
        if (ttlRemaining == null) {
            if (leaseTime > 0) {
                internalLockLeaseTime = unit.toMillis(leaseTime);
            } else {
            	//看门狗续时间，在锁要超时，业务还未执行完这种情况续锁时间。需要注意，leaseTime>0的时候不会有看门狗。
                scheduleExpirationRenewal(threadId);
            }
        }
        return ttlRemaining;
    });
    return new CompletableFutureWrapper<>(f);
}

org.redisson.RedissonLock#tryLockInnerAsync
该方法和redis交互，是锁实现的核心。

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        return commandExecutor.syncedEval(getRawName(), LongCodec.INSTANCE, command,
                "if ((redis.call('exists', KEYS[1]) == 0) " +
                            "or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then " +
                        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                        "return nil; " +
                    "end; " +
                    "return redis.call('pttl', KEYS[1]);",
                Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
    }

分析这个lua脚本的参数：

  • KEYS[1]：是大key，判断是否有其他线程获取到锁。
  • ARGV[1]：锁的释放时间，这个锁如果不释放，多久会超时。
  • ARGV[2]：uuid+线程id，用于实现可重入锁。

分析lua脚本的逻辑：
if ((redis.call(‘exists’, KEYS[1]) == 0)or (redis.call(‘hexists’, KEYS[1] ,ARGV[2]) == 1))
then
redis.call(‘hincrby’, KEYS[1], ARGV[2], 1);
redis.call(‘pexpire’, KEYS[1], ARGV[1]);
return nil;
end;
return redis.call(‘pttl’, KEYS[1]);

  • redis.call(‘exists’, KEYS[1]) == 0：说明大key不存在，也就是没有其他线程获取锁，可以之间获取锁成功了。
  • redis.call(‘hexists’, KEYS[1] ,ARGV[2]) == 1)：redis这大key下，当前线程已经获取到了锁。
  • return redis.call(‘pttl’, KEYS[1])：如果不是上面两种情况，说明其他线程占用锁了，返回这个锁还有多长时间释放。

总结：如果没有其他线程获取锁，或者当前线程已经获取到锁，则锁加上超时时间、当前线程锁的次数加1、然后返回空；否则说明有其他线程已经获取到锁，返回这个锁还有多久超时。

其他

lock、tryLock方法区别，参考这个博客：https://blog.youkuaiyun.com/weixin_37684345/article/details/135815110

ludkjava
关注
Redission分布式锁-源码解析（手把手解析）
weixin_46028606的博客
07-06 1085
Redission分布式锁-源码解析（手把手解析）
Redisson PermitExpirableSemaphore源码详解
NANA_Jp的博客
08-01 834
这两天的工作中发现了一个问题。原本一直在使用的redisson提供的semaphore信号量经常会莫名其妙的消失，也就是所谓的信号量泄露，发现问题出在调用的外部服务上，所以我只能试图通过给semaphore的每个信号量设置过期时间，也就是说当获取一个信号量的时候，如果在一定时间内没有归还，那么信号量将自动归还在总值里。这个时候就要使用redisson提供的另外一个功能，PermitExpirableSemaphore，他提供了为每个信号量设置过期时间的功能。...
redissonSourceReading:redisson源码阅读
03-23
redissonSourceReading:redisson源码阅读
十五、Redisson源码解析
小薛博客-助力人人成为架构师
12-20 2182
十五、Redisson源码解析1、code2、缓存续命3、watchdog4、源码解析1、分析1 - 通过redisson新建出来的锁key，默认是30秒2、分析23、分析34、分析4 - watch dog自动延期机制5、分析56、流程解释7、加锁查看8、可重入锁查看9、解锁5、常见异常情况更多内容： 1、code public class WatchDogDemo { public static final String LOCKKEY = "AAA"; private static
Redisson源码详解（redis分布式锁）
最新发布
xweiran的博客
05-05 450
读写锁利用的是reids的hash和string，hash（外面的大key是锁名称）里面的第一个键是mode，值是读写模式read或write，以后的键是锁标识UUID+threadId，值是重入的次数。执行加锁和释放锁的lua脚本的逻辑不一样。写锁是不会就超时记录的，因为写锁在同一时间只有一个线程能够获取(写写互斥)，锁的超时时间就是线程持有锁的超时时间，所以不需要。公平锁靠的是hash存放持有锁的线程信息，list集合存放等待的线程，zset集合则是存放线程以及等待锁的时间。
redisson源码解析
weixin_53067547的博客
02-03 1257
由于synchronized跟ReetrantLock是JVM级别的锁，在分布式情况下失效，这时候我们通常会选择redisson基于redis封装好的分布式锁。下面我们一起来分析以下redisson的源码。
Redis系列（二）Redisson分布式锁源码解析
CountryLord的博客
10-16 3531
Redisson分布式锁源码解析
Redis学习笔记【实战篇--分布式锁-redission】
qq_42192253的博客
05-31 2122
重入问题重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。超时释放：我们在加锁时增加了过期时间，这样的我们。
Redis:redission 源代码剖析1 连接建立
sunning9001的专栏
12-27 2679
redission作为redis 官方推荐的java客户端。 redission使用netty4.x作为网络层。 redission使用异步io方式操作。这与jedis 同步io操作方式完全不同。 但是redission也提供了同步操作方式。
一篇文章看懂Redission原理
时间如瑾 代码如诗
06-13 5531
一篇文章看懂Redission原理
【分布式锁篇】Redisson源码分析
WangJava_的博客
07-26 693
Redisson，分布式锁，微服务，锁机制
Redisson源码篇
weixin_44383484的博客
07-31 3966
Redisson源码
Redisson源码解读-分布式锁
王谷雨的博客
11-07 993
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。Redisson有一样功能是可重入的分布式锁。本文来讨论一下这个功能的特点以及源码分析。
Redis第14讲——Redis实现分布式锁（Redission源码解析）
让~学习~成为一种习惯（橡 皮 人の技术博客）
04-25 5169
在多线程环境下，为了保证数据的线程安全，我们通常用加锁的方式，使同一时刻只有一个线程可以对这个共享资源进行操作，在单服务系统我们常用JVM锁——Synchronized、ReentrantLock等。然而在多台服务系统的情况下，JVM锁就无法在多个服务器之间生效了，这时候我们就需要用分布式锁来解决线程安全的问题。分布式锁的实现方式有很多，主流的就是基于数据库、zookeeper以及redis，当然使用redis的居多，由于篇幅原因，本节就详细介绍一下使用redis实现分布式锁的几种方式。
《深入剖析Redisson源码》揭秘Redisson分布式锁原理（可重入锁机制、PubSub可重试机制、WatchDog超时续约机制，multiLock主从一致性问题）
实用技术干货分享⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄对您有用的话请点个关注吧~
12-23 1352
Redisson分布式锁原理可重入：利用hash结构记录线程id和重入次数。可重试：利用信号量和PubSub功能实现等待、唤醒，获取锁失败的重试机制。超时续约：利用watchDog，每隔一段时间（），重置超时时间。主从一致性：利用multiLock，多个独立的Redis节点，必须在所有节点都获取重入锁，才算获取锁成功。原理：利用setnx的互斥性；利用ex避免死锁；释放锁时判断线程标示缺陷：不可重入、无法重试、锁超时失效原理：利用hash结构，记录线程标示和重入次数；
【Redis】4.万字文章带你深入Redisson与源码解读(建议收藏)
沉迷写代码的程序猿的博客
10-30 4309
在前面【Redis】3.详解分布式锁解决了误删锁和原子性的问题但是不难发现，还存在一个问题，会导致锁不住。当锁的过期时间到了时候，锁就会被释放掉。这时候如果线程1因为阻塞还未向数据库插入订单数据，锁就被释放了，线程2就会获取锁，进行业务逻辑，这就导致锁不住。因此，当过期时间到了之后，业务逻辑还没执行完的时候，我们应该给这把锁续费，就不会出现这种问题了，这个续费问题该怎么解决呢？这就需要用到Redisson了。
redisson之分布式锁源码解读
vaidiy的博客
04-14 1477
基于源码了解redisson的加锁过程
Redisson分布式锁源码解读
青鸟飞鱼
07-20 693
加锁 & 解锁流程串起来上面结合 Lua 脚本和源码，分别分析了加锁流程和解锁流程。下面升级下挑战难度，模拟下多个线程争抢锁会是怎样的流程。示意图如下，比较关键的三处已用红色字体标注。概括下整个流程1、线程 A 和线程 B 两个线程同时争抢锁。线程 A 很幸运，最先抢到了锁。线程 B 在获取锁失败后，并未放弃希望，而是主动订阅了解锁消息，然后再尝试获取锁，顺便看看没有抢到的这把锁还有多久就过期，线程 B 就按需阻塞等锁释放。
redission锁源码解析
07-27
Redission 是一个基于 Redis 的 Java 分布式锁框架。它提供了一种简单且可靠的方式来实现分布式锁，以确保在分布式环境中的并发操作的一致性和互斥性。 Redission 的锁实现主要依赖于 Redis 的原子操作和 Lua 脚本。下面是 Redission 锁的源码解析： 1. 首先，Redission 提供了 `RLock` 接口作为分布式锁的主要接口。它提供了一系列的方法来获取锁、释放锁以及判断当前线程是否持有锁。 2. 在实现上，Redission 使用了 `RedissonLock` 类来具体实现 `RLock` 接口。该类内部维护了一个 `RMap` 对象，用于存储锁的状态信息。 3. 在获取锁时，Redission 会调用 `tryLockInner` 方法。该方法首先会尝试使用 Redis 的 `setnx` 命令来设置一个 Key-Value 对，其中 Key 是锁的名称，Value 是当前线程的标识符。如果设置成功，则表示当前线程获取到了锁；否则，表示锁已经被其他线程获取。 4. 在释放锁时，Redission 会调用 `unlockInner` 方法。该方法会使用 Redis 的 `eval` 命令执行一段 Lua 脚本来判断当前线程是否持有锁，并进行相应的解锁操作。 5. 为了确保锁的可重入性，Redission 使用了一个计数器来记录当前线程获取锁的次数。在每次获取锁时，计数器加一；在每次释放锁时，计数器减一。只有当计数器归零时，锁才会真正被释放。 总体来说，Redission 的锁实现是基于 Redis 的分布式原子操作和 Lua 脚本的。它通过对 Redis 的 Key-Value 存储进行操作，实现了简单且可靠的分布式锁机制。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值