redisson.tryLock()的参数的理解

因为redis的 setnx 还是有诸多问题，这里使用redisson，当然，正常来说，redis的setnx已经够用了

1. 可重入锁问题
2. 超时释放问题
3. 如果是集群 主从不一致问题

依赖

        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.13.6</version>
        </dependency>

配置

package com.hmdp.config;

import com.baomidou.mybatisplus.annotation.DbType;
import com.baomidou.mybatisplus.extension.plugins.MybatisPlusInterceptor;
import com.baomidou.mybatisplus.extension.plugins.inner.PaginationInnerInterceptor;
import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient(){

        Config config = new Config();

        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
//        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456");

        return Redisson.create(config);
    }

}

使用

package com.hmdp;

import com.hmdp.entity.SeckillVoucher;
import com.hmdp.service.ISeckillVoucherService;
import com.hmdp.service.impl.SeckillVoucherServiceImpl;
import org.junit.Test;
import org.junit.jupiter.api.BeforeEach;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import javax.annotation.Resource;

@SpringBootTest
public class HmDianPingApplicationTests {


    @Resource
    private RedissonClient redissonClient;


    @Test
    public void testRedisson() {

        long shopId = 147852478L;

        /*这样获取的是一把 可重入锁*/
        RLock lock = redissonClient.getLock("lock:order:" + shopId);

        /*等待时间，超时施放时间，时间单位
        * 不传递参数默认值是：不等待（-1），30秒*/
        boolean b = lock.tryLock();

        if (!b) {
            System.out.println("获取锁失败");
        }

        try{
            System.out.println("执行业务逻辑");
        }finally {
            lock.unlock();
        }

    }


}

这里有三个参数

1. waitTime ----等待时间
2. leaseTime ----超时施放时间
3. TimeUnit ----时间单位

等待时间

如果ABC…多个线程去抢夺一把锁，A成功了，如果设置的是 -1，那么BCD。。。。就不等待，直接返回失败，也就是不再去抢夺锁了，一次失败，直接放弃。
如果不是-1，假如说是 10（单位是秒）那么BCD…失败后会择机再次去抢夺，这里的择机抢夺，就代表着不是 与A抢夺失败后的立马再次抢夺，因为【明知道A抢过锁之后会执行自己的业务，需要一定的时间，那么BCD。。。立马再去抢夺锁的意义在哪里呢？ 除了徒增cpu的负担，没有太大意义】 。所以这里的择机抢夺，其实是利用了 发布，订阅机制。

从上面的图片可以看到，A抢过锁之后，执行业务，结束之后释放锁，释放锁的时候还 publish （发布）了一个信号，而有人发布，就有人订阅，发布人是A，订阅人是BCD…，所以说这里的择机再次抢夺是在BCD…接收到A发布的消息之后再去抢夺。
当然了，从第一次与A抢夺失败，到等待A完成业务发布消息这段等待时间+ 第一次和A抢夺锁的时间 总数不能超过10s，毕竟10s 就是硬性规定，10s之内，不论发生多么复杂的逻辑，只要拿到锁就行，不行就直接放弃。

超时施放时间

就是说 A拿到了锁之后， 如果发生了一些异常错误，内部业务没能正常的执行，没能正常执行释放锁的操作，这个时候 这个超时施放时间才会起作用，也就是说，在A抢到锁之后，即便A的业务出现了堵塞，但是只要没发生一些异常情况，这里的超时施放时间是不起作用的，因为只要不发生异常，内部就会有一个 看门狗，每隔 超时施放时间/3就会刷新一次锁的过期时间（是一个定时任务），确保A能够执行完成业务，当然，A执行完业务后，会删除刷新有效期的定时任务。所以说，超时释放时间在正常执行业务的时候，是不发挥作用的，只在出现异常的时候才会起作用。