1、抢券场景

正常思路：

代码实现：

比如优惠券数量为1。正常情况下：用户A的请求过来（对应线程1），查库存，抢券、改库存，然后用户B也来请求（对应线程2），继续查库存，抢券，此时，库存为0，抢券失败，没问题。

但既然是抢券，就不会一个请求一个请求的来，并发下，线程必然交替执行。

线程1查完库存，num=1，挂起，同时线程2执行，查库存，num=1，此时，线程2被挂起，线程1抢完券，改库存减一，库存为0。线程2继续执行，其挂起前查的num为1，也去扣减库存，此时，就会超卖。先考虑加锁，因为是并发抢夺同一个资源：

时序图：

如此，就解决了问题。但生产环境，一般不是单节点部署，如果抢券接口所在的微服务被部署在了三个节点或者实例上，这三个实例对应三个JVM

此时，线程1、2的请求被路由到8080的实例，线程3、4的请求被路由到8081的实例，则线程1和线程3都能获取到互斥锁。因为：代码里获取的synchronize锁属于本地锁，这个锁是属于JVM里的，现在一份代码跑在多个实例中，每个实例都启动了一个JVM。也就是说，synchronize能解决通一个JVM下的互斥，但解决不了多个JVM下的互斥，所以，集群下，不能使用本地锁来实现了，要用一个外部的锁

由此，引入分布式锁（超出JVM之外的外部锁）：

2、Redis分布式锁

Redis实现分布式锁，依靠setnx命令，setnx即set if not exists，不存在就set：

//获取锁，NX是互斥，EX是设置超时时间
SET lock value NX EX 10

//释放锁，删除即可
DEL key

通过set来获取锁时，之所以设置过期时间，倒不是担心发生异常，导致锁释放失败，这个可以try-finally，如果不是异常，而是获取锁后服务器宕机，则这个锁永远不会被释放。

但这个超时时间如何控制，根据业务时间估算是不靠谱的，考虑开个线程：如果业务还在执行的话，就去给锁续期 ⇒ 关于这个思想的落地：redission

3、Redisson实现分布式锁

和单纯的setnx相比，Redisson除了加锁，还会单开一个线程（看门狗）去给锁续期，没releaseTime/3做一次续期，releaseTime即锁的超时时间，默认30秒。即watch dog线程每10秒给持有分布式锁的线程做一次续期，将其重置为默认的30秒。最后线程释放分布式锁的时候，通知对应的watch dog线程，不用再做监听了。

此外，线程A持有分布式锁的时候，线程B再来尝试获取锁，如果获取失败，会while循环尝试加锁，循环次数达到阈值后，还没获取成功，则返回获取锁失败。

代码实现：

<dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.16.3</version> <!-- 替换需要的版本号 -->
</dependency>

@Resource
private RedissonClient redissonClient;public void redissonLock() {//获取锁（重入锁）RLock lock = redissonClient.getLock("your-key");try {//tryLock方法重载，形参1为获取锁的最大等待时间，形参2为锁超时释放时间，形参3为时间单位boolean isLock = lock.tryLock(10, TimeUnit.SECONDS);//注意下面，如果传了锁超时释放时间，则watch dog机制失效，redisson认为你自己可以控制超时时间，不传或传-1，则有看门狗续期//boolean isLock = lock.tryLock(10, 30, TimeUnit.SECONDS);//获取锁成功if (isLock) {System.out.println("执行业务");}} catch (InterruptedException e) {//打印必要的loge.printStackTrace();} finally {//释放锁lock.unlock();}
}

最后，以上加锁、设置过期时间灯操作是基于Lua脚本完成，原子性有保证

4、Redisson实现的分布式锁是可重入锁

redisson实现的分布式锁是可重入锁：

public void add1(){RLock lock = redissonClient.getLock("your-key");boolean isLock = lock.tryLock();//执行业务add2();//释放锁lock.unlock();
}public void add2(){RLock lock = redissonClient.getLock("your-key");boolean isLock = lock.tryLock();//执行业务//释放锁lock.unlock();
}

判断是同一个线程ID，就可重入，内部用hash结构记录线程ID和可重入的次数

5、Redisson实现分布式锁下的主从一致性

Java应用尝试获取分布式锁（Set lock xx）到master节点，线程获取锁成功，正常接下来应该主从同步。

若此时master宕机，没来得及同步到slave，然后主从故障转移，从slave中选出一个新的master，线程2又来获取锁，此时，对新的master，自然可以set成功，即获取分布式锁成功，如此，就出现了两个线程同时获取到了分布式锁。

针对这个问题，刚第一反应是等同步到slave了再返回写入成功，即抢锁成功，但这样也性能太差了，没意义了。 ⇒ 红锁方案：红锁即ReadLock，指不能只在一个redis实例上创建锁，应该在（n/2+1）个节点上创建锁成功（n为Redis节点的数量），但这样Redis集群运维难度大、性能差，也有局限性，不推荐。

最后，Redis集群优先是AP，即高可用，如果需要数据的强一致性，那可使用zookeeper来实现分布式锁

6、面试