手撸Redis分布式锁（8个版本的渐进式源码实践解读）_redislock哪个版本才有

最后

Java架构进阶面试及知识点文档笔记

这份文档共498页，其中包括Java集合，并发编程，JVM，Dubbo,Redis，Spring全家桶，MySQL，Kafka等面试解析及知识点整理

Java分布式高级面试问题解析文档

其中都是包括分布式的面试问题解析，内容有分布式消息队列，Redis缓存，分库分表，微服务架构，分布式高可用，读写分离等等！

互联网Java程序员面试必备问题解析及文档学习笔记

Java架构进阶视频解析合集

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

public boolean lock() {
    // 等价于原生命令 set key 1 ex 10 nx
    Boolean ok = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
    return Boolean.TRUE.equals(ok);
}

这样就彻底解决了死锁问题💪💪💪

---

四、v4 解铃还需系铃人

上面代码里的unlock方法只是单纯的删除key，这样的代码是不安全的，如果占有锁的线程还在执行业务逻辑，这时被未上锁的线程调用了unlock释放了锁，可想而知，那么这时其它线程就又可以抢锁成功了，结果就不正确了，所以我们要确保解锁还需上锁线程。
解决方案：对每个锁对象生成唯一的id，加锁时保存在value中，解锁时需要判断value=id再解锁。

我们修改代码如下：

---

五、v5 解锁 - 原子性

其实unlock还是会有一点小问题的，因为unlock时GET + DEL 是两条指令，又会遇到我们前面讲的原子性问题了。假设持有锁的进程在del之前锁过期自动释放了，这时马上被其它线程加锁了，那么此时再删除就会把别人刚加的锁删除了。
我们修改成执行lua脚本方式：

public void unlock() {
    String script = "if (redis.call('get', KEYS[1]) == ARGV[1] ) then " +
            "redis.call('del', KEYS[1]); " +
            "return 1; " +
            "end;" +
            "return 0;";
    executeLua(script, Long.class, Collections.singletonList(key), id);
}

private <T> T executeLua(String script, Class<T> resultType, List<String> keys, Object... args) {
    RedisScript<T> redisScript = new DefaultRedisScript<>(script, resultType);
    RedisSerializer<String> argsSerializer = new StringRedisSerializer();
    RedisSerializer<T> resultSerializer = new Jackson2JsonRedisSerializer<>(resultType);
    return (T) stringRedisTemplate.execute(redisScript, argsSerializer, resultSerializer, keys, args);
}

至此，解锁的流程就更严谨了 💪💪💪

---

六、v6 可重入性

接下来，我们做一个完善：可重入。
可重入性是指线程在持有锁的情况下再次请求加锁，如果一个锁支持同一个线程的多次加锁，那么这个锁就是可重入的。比如synchronized和ReentrantLock就是可重入锁。
对于可重入性的解决方案：加锁时，增加锁的持有计数; 释放锁时，减少锁的持有计数。
对于锁的持有计数保存在哪？一般会保存在本地，或者Redis服务端。

1. 本地使用ThreadLocal或全局静态变量保存锁的持有计数
2. Redis端将持有计数保存在value中

对于方案2是开源框架Redisson的RedissonLock的解决方案，但是可重入性是在本地就能解决的，所以为了更好的性能我们采用方案1。

增加一个全局静态变量Map：

// 可重入map：key= this.key+threadId; value=重入次数
private final static ConcurrentHashMap<String, AtomicInteger> refMap = new ConcurrentHashMap<>();

加锁：
加锁前调用isShouldAcquire判断是否应该抢锁，加锁成功将持有计数放入refMap

isShouldAcquire方法如下：加锁时如果发现该线程已持有锁，refCount++

解锁：
解锁前调用isShouldUnlock判断是否应该释放锁

isShouldUnlock方法如下：解锁时如果发现该线程已持有锁，refCount--，减1后如果refCount仍大于0，说明是仍持有锁，不应该释放锁。如果需要释放锁，应从refMap中移除。

至此，我们手写的分布式锁就支持可重入了 💪💪💪

---

七、v7 锁等待

我们抢锁往往不是一锤子买卖，需要不断重试抢锁，直到成功，所以我们来尝试写一个最简单的锁等待，方案就是使用循环 + Thread.sleep不断重试抢锁

---

八、v8 锁等待 - 优化

上面的锁等待，运行结果没问题，可能性能稍微差了一点，所以我们做一下优化。

优化方案：

1. 使用Redis的订阅发布功能，锁等待的线程订阅channel，持有锁的线程释放锁时发布channel
2. 使用Semaphore，当锁释放时，通知本进程的锁等待线程。其它进程的锁等待线程依然使用Thread.sleep。

对于方案1是开源框架Redisson的RedissonLock的解决方案，由于引入了订阅发布channel，提高了复杂了度，另外由于Redis发布订阅不能持久化，有可能丢失，所以权衡过后为了更稳定我们采用方案2。

这里更改的点 较多，慢慢品味：
先增加一个Semaphore计数器，目的是当没有锁等待时，能将Semaphore释放。

static class SemaphoreCounter {
    private final Semaphore semaphore = new Semaphore(0);
    private final AtomicInteger acquireCount = new AtomicInteger(0);

    public void tryAcquire(long timeout, TimeUnit unit) throws InterruptedException {
        acquireCount.incrementAndGet();
        semaphore.tryAcquire(timeout, unit);
        acquireCount.decrementAndGet();
    }

    public int getAcquiredCount() {
        return acquireCount.get();
    }

    public void release() {
        semaphore.release();
    }
}

再增加一个全局静态变量Map：记录当前key的SemaphoreCounter

// 锁等待map：key= this.key; value=信号量
private static final ConcurrentHashMap<String, SemaphoreCounter> waitMap = new ConcurrentHashMap<>();

加锁：
加锁成功，将SemaphoreCounter放入waitMap
加锁失败，如果map中有key，说明本进程其它线程持有锁，使用Semaphore等待锁释放，否则使用Thread.sleep

解锁：
正式解锁前，判断如果本进程没有锁等待，将key从waitMap移除
解锁后：使用Semaphore通知其它等待线程

至此，我们手写的分布式锁就支持锁等待了，我们手写的功能就大功告成了 💪💪💪

---

测试

我们的共享资源就以内存中减库存为例 (如果分布式锁有效，就不会超卖)

private void deductProduct(Integer productId){
    String count = stringRedisTemplate.opsForValue().get("product:count:" + productId);
    // 假设现在库存1000：内存里--，如果没有分布式锁，就是出现超卖的情况
    int newCount = count == null ? 999 : (Integer.parseInt(count) - 1);
    stringRedisTemplate.opsForValue().set("product:count:" + productId, String.valueOf(newCount));
}

用Springboot开放一个API：

我们设置一下库存productId为1的库存为1000

用Nginx部署两个实例，用Jmeter测一下：
100个线程在1秒钟之内发起减库存：

最终也在1秒之内结束。

我们看下结果是否正确：

我们再看下两个实例的执行情况（也正是抢到锁100次）：

最后

锁超时问题

如果在加锁和释放锁之间的逻辑执行的时间太长，以至于超出了锁的超时限制，就会出现问题。因为这时侯第一个线程持有的锁过期了，逻辑还没有执行完，而同时第二个线程就提前重新持有了这把锁，导致可能2个线程同时持有一把锁，问题就出现了。
我觉得这是一个棘手的问题，也是一个架构上的问题，笔者也确实没有打算解决它，不要看我的代码里只写了10s的超时时间，正式用的话这个超时时间是需要做成参数来配置的，是需要提供一个方法来重载的，提供更高的灵活性，因为总可能有一些特殊场景是需要特殊处理的。
我的建议是Redis分布式锁不要用于较长时间的任务，在使用分布式锁时我们也应该尽可能缩小锁的控制范围，尽量细粒度，尽可能设置长一些的超时时间，根据你的业务评估一个足够长的过期时间，比如你们业务逻辑普遍都执行在10秒以内，那过期时间设置30秒就差不多了，如果你就是担心，那设置成100秒也是OK的。
当然，这里还有一个解决方案：Redisson帮我们实现的看门狗机制，锁自动延期。关于它的原理简单来说是这样的：抢到锁的线程开启一个守护线程，默认30秒超时，定时每10秒检测一下，如果逻辑未执行完就将锁超时间重新修改为30秒。
这个方案实际要考虑的细节很多，说起来容易但想完善还真不容易，所以我们要感谢Redisson😏😏😏

锁丢失问题

锁超时我们可以避免，但是锁丢失才是Redis做分布式锁的致命缺陷，是无法100%解决的。这里需要提前一些 Redis持久化和 Redis主从复制原理的知识。

单节点：

• 线程1通过SET命令加锁成功
• 此时，单节点宕机，SET命令尚未持久化
• 节点恢复后，线程1依然在执行，但这个锁因为尚未持久化已经无法恢复了，所以其它线程也可以获得锁了😲

主从/哨兵/集群： 都是基于主从，所以都是一样的问题

• 线程1通过SET命令加锁成功
• 此时，Master节点宕机，SET命令尚未主从复制给Slave节点
• Slave节点通过人工或选举做了Master，线程1依然在执行，但这个锁因为尚未同步，所以在新的Master上丢失了！所以其它线程也可以获得锁了😲

RedLock

感受：

其实我投简历的时候，都不太敢投递阿里。因为在阿里一面前已经过了字节的三次面试，投阿里的简历一直没被捞，所以以为简历就挂了。

特别感谢一面的面试官捞了我，给了我机会，同时也认可我的努力和态度。对比我的面经和其他大佬的面经，自己真的是运气好。别人8成实力，我可能8成运气。所以对我而言，我要继续加倍努力，弥补自己技术上的不足，以及与科班大佬们基础上的差距。希望自己能继续保持学习的热情，继续努力走下去。

也祝愿各位同学，都能找到自己心动的offer。

分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

[外链图片转存中…(img-ILDcwTRD-1715545065349)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取