分布式锁——分布式锁的可重入和自旋优化

分布式锁可以参考我的专栏：分布式锁

锁的可重入和自旋优化相关概念解释可以参考：Java多线程——synchronized同步锁的原理深度解析以及多线程加锁优化

---

分布式锁重入

在分布式锁的使用过成功，同样是存在于锁重入的情况的，不管是“不小心”造成的，还是有意为之，这种情况是存在的。

以redis分布式锁实现原理为例：

1. 在临界区（需要被锁的代码块）执行之前tryLock，在redis中存入一个分布式锁（setnx或者Lua脚本）
2. 执行临界区代码
3. 执行完毕释放锁

大致分为这三部，其中第二部临界区代码的执行过程中，就很可能存在又对当前线程已经持有的redis分布式锁的再次tryLock的情况，这不是问题点。

问题点在于，有时候会出现在重入锁操作之后，释放了锁，导致第一次tryLock的临界区代码还没有执行完毕失效了。

其实我在Redisson分布式锁——加锁原理基本介绍以及源码分析中有提到过Redisson的做法：

if 
    (redis.call('exists', KEYS[1]) == 0) 
then 
    redis.call('hincrby', KEYS[1], ARGV[2], 1); 
    redis.call('pexpire', KEYS[1], ARGV[1]); 
return nil; 
end; 
 
if 
    (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]);

这个KEYS[1]就是我们设置的分布式锁的key

大致逻辑如下：

1. 首先判断redis中是否存在这个key
   1. 如果不存在就使用hset设置这个key对应的value——ARGV[2]为1，然后设置这个key的超时时间——ARGV[1]（顺带提一下hset适合存储对象，所以可得知redisson分布式锁存的是一个对象在redis中）
   2. 如果存在，就是重入锁的操作了
2. 最后返回这个key的剩余存活时间（pttl以毫秒为单位返回 key 的剩余生存时间）

详细说明一下这个重入锁操作干了什么：

hincrby：增加 key 指定的哈希集中指定字段的数值。如果 key 不存在，会创建一个新的哈希集并与 key 关联。如果字段不存在，则字段的值在该操作执行前被设置为 0，HINCRBY 支持的值的范围限定在 64位 有符号整数

返回值：增值操作执行后的该字段的值

使用举栗：

redis> HSET myhash field 5

(integer) 1

redis> HINCRBY myhash field 1

(integer) 6

redis> HINCRBY myhash field -1

(integer) 5

redis> HINCRBY myhash field -10

(integer) -5

redis>

也就是说如果这个key存在，则将ARGV[2] 增加 1（实现可重入锁，同一个线程多次tryLock，每次加1，每次releaseLock就-1，当被减为0的时候，就代表该线程完全释放掉锁）

然后重置这个key的超时时间为ARGV[1]

简而言之：就是在分布式锁中有当前线程的id，只要在当前线程中的每一次操作都会在分布式锁的一个字段中 +1，每次释放锁都会在分布式锁的对应字段中 -1，直到0为止，代表当前线程完全释放锁资源。

解决分布式锁可重入的核心就是提供一个计数器。

分布式锁自旋优化

什么是自旋优化

我们都知道java的重量级锁是有自选优化机制的：

指的就是在竞争失败锁资源之后，在进入Monitor 的 EntryList之前，线程会进行若干次获取锁资源的重试操作。

如果当前持有锁对象的线程执行的很快，可能就在自旋重试的过程中，就释放了锁，被处于自旋重试过程的线程获取到了，就不用进入EntryList，不用进入阻塞状态，也就避免了一些线程间切换的情况。当然自旋优化只能在多核cpu上使用。

自旋对于分布式锁的意义

在分布式锁的使用中，竞争失败的线程可能就直接使用“优雅报错”返回给客户端了，但是这样做在某些业务场景下是不合适的，用户体验可能会很差。

如抢购商品场景会有如下问题：

1. 客户需要反复的点击抢购，用户体验差
2. 客户反复点击抢购的时候，造成更大的带宽和并发压力

根据自旋的特点可以大致分析出分布式锁场景下的实现逻辑：

1. 多服务实例中多线程竞争锁资源
2. 其中一个tryLock成功，其他竞争失败的线程阻塞
3. 阻塞之后进入循环，在循环中执行tryLock直到成功

这个逻辑中的实现自旋的关键是竞争失败的线程进入无限的循环tryLock，将会造成如下问题：

1. CPU资源占用高
2. 对redis的请求压力过度增加

这里可能有人想到每次循环的时候让线程sleep一定的时间，但是这个sleep的时间设置多少合适呢？所以很明显在这里使用sleep不是一种好的方式。

最理想的状态还是只要分布式锁被释放，就会通知阻塞的线程去竞争一下锁。

解决方案1:MQ+JUC的Semaphore（信号量）

为了实现阻塞的分布式锁的自旋，其中一个方案是使用MQ+JUC的Semaphore（信号量）

Semaphore信号量是什么？

是java.util.concurrent包下的一个类，属于高级并发的使用。

因为前文分析出了我们要实现一个阻塞的分布式锁，用sleep又不是很好的方式，所以就引出了Semaphore。

Semaphore的特性

demo：

package com.leolee.multithreadProgramming.juc.semaphore;

import lombok.extern.slf4j.Slf4j;

import java.util.concurrent.Semaphore;

/**
 * @ClassName Test
 * @Description: Semaphore信号量
 * 主要作用：
 *      1.用于多个共享资源的互斥使用
 *      2.控制并发线程数
 * @Author LeoLee
 * @Date 2020/12/4
 * @Version V1.0
 **/
@Slf4j
public class Test {

    /*
     * 功能描述: <br>
     * 〈Semaphore 的一般使用〉
     * 使用抢车位的场景，车多车位少
     * @Param: []
     * @Return: void
     * @Author: LeoLee
     * @Date: 2020/12/4 15:56
     */
    public void semaphoreTest() {

        Semaphore semaphore = new Semaphore(3);
        //有6辆车来抢车位
        for (int i = 0; i < 6; i++) {
            new Thread(() -> {
                try {
                    //Semaphore的3会-1，即一个资源被占用了(acquire方法是占用一个资源，如果没有占用到资源将一直等待下去)
                    semaphore.acquire();
                    log.info("Thread{}占用了一个停车位", Thread.currentThread().getName());
                    //三秒钟之后车就开走了，即释放资源
                    Thread.sleep(3*1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    //释放资源,+1
                    semaphore.release();
                }
            }, String.valueOf(i)).start();
        }
    }

    public static void main(String[] args) {

        Test test = new Test();
        test.semaphoreTest();
    }
}

执行结果：
16:52:38.687 [0] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread0占用了一个停车位
16:52:38.687 [2] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread2占用了一个停车位
16:52:38.687 [1] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread1占用了一个停车位
16:52:41.716 [4] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread4占用了一个停车位
16:52:41.716 [3] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread3占用了一个停车位
16:52:41.716 [5] INFO com.leolee.multithreadProgramming.juc.semaphore.Test - Thread5占用了一个停车位

利用Semaphore限流的特性回到上图中：

1. 当一个线程拿到分布式锁
2. 其他线程将会去订阅一个MQ的消息
3. 开始循环，也就是自旋tryLock，并且实例化一个Semaphore(0)，然后调用Semaphore.acquire()方法进入阻塞
4. 当持有分布式锁的线程释放掉锁之后，会向MQ中发送一条带有资源标识的消息
5. 进入阻塞的线程监听到该消息之后，将会用同一个Semaphore对象调用Semaphore.release()方法跳出阻塞，即开启下一次自旋
   1. 如果获取到分布式锁，就开始执行之后的业务代码，最终就释放锁，并向MQ发送一条带有资源标识的消息
   2. 如果没有获取到锁，就又进入step2

还有其他的方案，之后再续~~~