二刷 黑马点评 分布式锁-redission

重入：
获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁
不可重试：
只能尝试一次
超时释放：
在加锁时增加了过期时间，可以防止死锁，有安全隐患
主从一致：
向集群写数据时，主机需要异步地将数据同步给从机

Redission

在Redis基础上实现的Java驻内存数据网络，提供一系列分布式Java常用对象和分布式服务
包括分布式锁的实现

RLock lock = redissonClient.getLock("anyLock");
锁的名称是anyLock,是全局唯一标识，当多个客户端或线程尝试获取相同名称的锁时，就会发生竞争关系
Rlock代表是可重入锁，同一线程能够多次获取同一把锁，不会出现死锁

可重入锁原理

使用一个state变量记录重入状态，当没有人持有这把锁，state=0,假如有人持有,state=1,当前持有这把锁的人再次持有这把锁时，state+1
也就是重入一次加一，释放一次减一，直到减少为0代表这把锁没有被持有

在分布式锁中，使用hash存储锁
加锁代码：

这里共有三个参数：
KEYS[1]:锁名称
ARGV[1]:线程唯一标识
ARGV[2]:锁自动释放时间
首先判断锁是否存在
不存在就直接获取锁

存在就判断是不是自己的是自己的就重入次数加一不是自己的则获取锁失败

释放锁代码：

先判断锁是不是自己的
不是自己的直接返回
是自己的重入次数减一
如果重入次数为0则直接释放锁
不为0说明还不能释放，重制有效期

MutiLock原理

在搭建redis集群和主从的过程中
当执行写命令，写在主机上时，主机会同步数据给从机，但是假如主机在还没来得及把数据写入从机的时候就宕机，哨兵会发现主机宕机，并选举一个slave成为Master,新的Master实际并没有锁信息，此时锁信息就丢失掉了。

为解决这个问题，提出了MutiLock,使用这把锁就不使用主从，每个节点有相同地位
这把锁的逻辑是需要写入每一个主从节点上，只有所有服务器都成功写入才是加锁成功，假设有一个节点挂了，在获取锁时只要有一个节点拿不到就是加锁失败

加锁原理

设置多个锁时，会把多个锁添加到一个集合，用while循环去不停尝试拿锁，但存在一个总加锁时间，这个时间是需要加锁的个数*1500ms，假设在时间内所有锁加锁成功才算成功,只要有线程加锁失败，就会再次重试

总结

1. 可重入锁是如何防止死锁的？
   可重入锁允许同一线程多次获取同一把锁，通过计数器（state）记录重入次数。重入时递增，释放时递减，减至 0 才完全释放锁。这种机制避免了同一线程因重复请求同一锁而导致的阻塞，从而防止死锁。
2. Redisson 的分布式可重入锁如何实现原子性？
   Redisson 使用 Lua 脚本实现分布式锁的原子性操作。加锁时，通过 Lua 脚本原子性地检查锁是否存在、是否自己持有以及递增重入次数；释放锁时，同样通过 Lua 脚本原子性地递减重入次数并判断是否释放锁，确保操作的原子性。
3. 超时释放机制的安全隐患是什么？如何应对？
   超时释放可能导致锁提前释放，引发多个线程同时持有锁的问题。应对方法：
   合理设置超时时间，根据业务执行时间调整
   使用 watchdog 机制自动续期
   业务代码中做好幂等性处理
4. Redisson 的 MultiLock 如何解决主从架构中的锁丢失问题？
   MultiLock 要求在多个独立节点上同时获取锁，只有全部获取成功才算加锁成功。即使主节点宕机，由于其他节点仍持有锁，新选举的主节点不会影响锁的有效性，从而避免锁丢失。
5. MultiLock 加锁失败后的重试机制是怎样的？
   MultiLock 通过 while 循环不断尝试加锁，总加锁时间为锁数量 * 1500ms。若在该时间内所有锁均加锁成功，则加锁成功；否则失败，释放已获取的锁并重新尝试。这种机制平衡了性能和可靠性。