• JUC提供的锁机制，可以保证在同一个JVM进程中同一时刻只有一个线程执行操作逻辑；
• 多服务多节点的情况下，就意味着有多个JVM进程，要做到这样，就需要有一个中间人；
• 分布式锁就是用来保证在同一时刻，仅有一个JVM进程中的一个线程在执行操作逻辑；

JUC的锁和分布式锁都是一种保护系统资源的措施。尽可能将并发带来的不确定性转换为同步的确定性；

特性2：不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

特性3：解铃还须系铃人。加锁和解锁必须是同一个客户端（线程），客户端自己不能解别人加的锁。

特性4：可重入性。同一个现线程已经获取到锁，可再次获取到锁。

特性5：具有容错性。只要大部分的分布式锁节点正常运行，客户端就可以加锁和解锁。

03特性——不会发生死锁

很多线程去上锁，谁锁成功谁就有权利执行操作逻辑，其他线程要么直接走抢锁失败的逻辑，要么自旋尝试抢锁；

比方说A线程竞争到了锁，开始执行操作逻辑（代码逻辑演示中，使用 Jedis客户端为例）；

public static void doSomething() { // RedisLock是封装好的一个类 RedisLock redisLock = new RedisLock(jedis); // 创建jedis实例的代码省略，不是重点 try { redisLock.lock(); // 上锁
// 处理业务 System.out.println(Thread.currentThread().getName() + " 线程处理业务逻辑中..."); Thread.sleep(2000); System.out.println(Thread.currentThread().getName() + " 线程处理业务逻辑完毕");
redisLock.unlock(); // 释放锁 } catch (Exception e) { e.printStackTrace(); }}

正常情况下，A 线程执行完操作逻辑后，应该将锁释放。如果说执行过程中抛出异常，程序不再继续走正常的释放锁流程，没有释放锁怎么办？所以想到：

释放锁的流程一定要在 finally{} 块中执行，当然，上锁的流程一定要在 finally{} 对应的 try{} 块中，否则 finally{} 就没用了，如下：

public static void doSomething() { RedisLock redisLock = new RedisLock(jedis); // 创建jedis实例的代码省略，不是重点 try { redisLock.lock(); // 上锁，必须在 try{}中
// 处理业务 System.out.println(Thread.currentThread().getName() + " 线程处理业务逻辑中..."); Thread.sleep(2000); System.out.println(Thread.currentThread().getName() + " 线程处理业务逻辑完毕"); } catch (Exception e) { e.printStackTrace(); } finally { redisLock.unlock(); // 在finally{} 中释放锁 }}

写法注意：redisLock.lock(); 上分布式锁，必须在try{}中。

3-1 redisLock.unlock() 放在 finally{} 块中，还需要设置超时时间

注意，上锁时，设置key和设置超时时间这两个操作是原子性的，要么都执行，要么都不执行。

set k vexipre k time

3-2 锁的超时时间该怎么计算？

刚才假设的超时时间1s是怎么计算的？这个时间该设多少合适呢？

锁中的业务逻辑的执行时间，一般是在测试环境进行多次测试，然后在压测环境多轮压测之后，比方说计算出平均的执行时间是 200ms，锁的超时时间放大3-5倍，比如这里设置为 1s，因为如果锁的操作逻辑中有网络 IO操作，线上的网络不会总一帆风顺，需要给网络抖动留有缓冲时间。另外，如果设置 10s，果真发生了宕机，那意味着这 10s中间，这个分布式锁的服务全部节点都是不可用的，这个和业务以及系统的可用性有挂钩，要衡量，要慎重（后边3-13会再详细聊）。那如果一个节点宕机之后可以通知 redis-server释放锁吗？注意，由于是宕机存在不可控力，断电不能通知。

如果是停机，不是 kill -9，也不是断电，这样似乎可以去做一些编码去释放锁，可以参考 JVM的钩子、Dubbo的优雅停机、或者 linux进程级通信技术来做这件事情。当然也可以手动停服务后，手动删除掉 redis中的锁。

04特性——解铃还须系铃人

如果说 A线程在执行操作逻辑的过程中，别的线程直接进行了释放锁的操作，是不是就出问题了？

联想 ReentrantLock中的 isHeldByCurrentThread()方法，所以必须在锁上加个标记，只有上锁的线程 A线程知道，相当于是一个密语，也就是说释放锁的时候，首先先把密语和锁上的标记进行匹配，如果匹配不上，就没有权利释放锁；

private boolean tryLock() { SetParams setParams = new SetParams(); setParams.ex(1); // 超时时间1s setParams.nx(); // nx String response = jedis.set(lock_key, "", setParams); // 转换为redis命令就是：set zjt_key "" ex 1 nx return "OK".equals(response); }
// 别的线程直接调用释放锁操作，分布式锁崩溃！ public void unlock() { jedis.del(encode(lock_key)); System.out.println("线程：" + threadName + " 释放锁成功！☆☆☆"); }
private byte[] encode(String param) { return param.getBytes(); }

4-1 这个密语value（约定）设置成什么呢？

上锁之前，在该线程代码中生成一个 UUID，将这个作为秘钥，存在锁键的 value中，释放锁的时候，用这个进行校验，因为只有上锁的线程知道这个秘钥，别的线程是不知道的。

String releaseLock_lua = "if redis.call(\"get\",KEYS[1]) == ARGV[1] \n" + "then\n" + " return redis.call(\"del\", KEYS[1])\n" + "else\n" + " return 0\n" + "end";
private boolean tryLock(String uuid) { SetParams setParams = new SetParams(); setParams.ex(1); // 超时时间1s setParams.nx(); // nx String response = jedis.set(lock_key, uuid, setParams); // 转换为redis命令就是：set zjt-key "" ex 1 nx return "OK".equals(response); }
public void unlock(String uuid) {
List<byte[]> keys = Arrays.asList(encode(lock_key)); List<byte[]> args = Arrays.asList(encode(uuid));
// 使用lua脚本，保证原子性 long eval = (Long) jedis.eval(encode(releaseLock_lua), keys, args); if (eval == 1) { System.out.println("线程：" + threadName + " 释放锁成功！☆☆☆"); } else { System.out.println("线程：" + threadName + " 释放锁失败！该线程未持有锁！！！"); }
}
private byte[] encode(String param) { return param.getBytes(); }

为什么使用 lua脚本？因为保证原子性。

05特性——可重入性

作为一把锁，在使用 synchronized、ReentrantLock的时候是不是有可重入性？

那分布式锁该如何实现可重入呢？如果 A线程的锁方法逻辑中调用了 x()方法，x()方法中也需要获取这把锁，按照这个逻辑，x()方法中的锁应该重入进去即可，那是不是需要将刚才生成的这个 UUID秘钥传递给 x()方法？怎么传递？用参数传递就会侵入业务代码。

5-1、不侵入业务代码实现可重入：Thread-Id

如果 A线程执行逻辑中间开启了一个子线程执行任务，这个子线程任务中也需要重入这把锁，因为子线程获取到的线程 id不一样，导致重入失败。那意味着需要将这个秘钥继续传递给子线程，JUC中 InheritableThreadLocal 派上用场。这种方式存在一些问题，因为线程间传递的是父线程的 id。

微服务中多服务间调用的话可以借用系统自身有的 traceId作为秘钥即可。比如sgm中的traceId或者利用RPC框架的隐式传参。

以上内容的主要注意力在怎么重入进去，而分布式锁要考虑的事情还有很多，重入进去后，超时时间随便设吗？

比方说 A线程在锁方法中调用了 x()方法，而 x()方法中也有获取锁的逻辑，如果 A线程获取锁后，执行过程中，到 x()方法时，这把锁是要重入进去的，但是请注意，这把锁的超时时间如果小于第一次上锁的时间，比方说 A线程设置的超时时间是 1s，在 100ms的时候执行到 x()方法中，而 x()方法中设置的超时时间是 100ms，那么意味着 100ms之后锁就释放了，而这个时候 A线程的主方法还没有执行完呢！却被重入锁设置的时间搞坏了！这个怎么解决？

如果说在内存中设置一个这把锁设置过的最大的超时时间，重入的时候判断下传进来的时间，重入时expire的时候始终设置成最大的时间，而不是由重入锁随意降低锁时间导致上一步的主锁出现问题。

上边举例中，调用的 x()方法是在一个 JVM中，如果是调用远程的一个 RPC服务呢（像这种调用的话就需要将秘钥value通过 RpcContext传递过去了）到另一个节点的服务中进行锁重入，这个时间依然是要用当前设置过锁的最大时间的，所以这个最大的时间要存在 redis中而非 JVM内存中。经过这一步的分析，重入 lua脚本就修改为这样了：

其实，还有另外一种方案比较简单，就是锁的超时时间=第一次上锁的时间+后面所有重入锁的时间。也就是（expire = 主ttl + 重入exipre），这种方案是放大的思想，一放大就又有上边提到过的一个问题：expire太大怎么办，参考上边。

5-5、重入锁的方法中直接执行 unlock？考虑重入次数

A线程执行一共需要500ms，执行中需要调用 x()方法，x()方法中有一个重入锁，执行用了 50ms，然后执行完后，x()方法的 finally{} 块中将锁进行释放。

为啥能释放掉？因为秘钥我有，匹配成功了我就直接释放了。

这当然是有问题的，所以我们要通过锁重入次数来进行释放锁时候的判断，也就是说上锁的时候需要多维护一个 key来保存当前锁的重入次数，如果执行释放锁时，先进行重入次数 -1，-1后如果是0，可以直接 del，如果>0，说明还有重入的锁在，不能直接 del。

5-6、考虑如何存储锁的属性（锁的key 重入次数key 最大超时时间key）

目前为止，算上上一步中设置最大超时时间的key，加上这一步重入次数的key，加上锁本身的key，已经有3个key，需要注意的事情是，这三个key的超时时间是都要设置的！为什么？假如说重入次数的 key没有设置超时时间，服务A节点中在一个JVM中重入了5次后，调用一次 RPC服务，RPC服务中同样重入锁，此时，锁重入次数是 6，这个时候A服务宕机，就意味着无论怎样，这把锁不可能释放了，这个分布式锁提供的完整能力，全线不可用了！

所以，这几个 key是要设置超时时间的，如何设置？

最大超时时间的 key和重入次数的 key，都附属于锁，它们都是锁的属性，如果锁不在了，谈它们就毫无意义，这个时候用什么存储呢？redis的 hash数据结构，就可以做，key是锁，里边的 hashKey分别是锁的属性， hashValue是属性值，超时时间只设置锁本身 key就可以了。这个时候锁的数据结构就要改变一下了。

06看门狗机制

在设置超时时间时，预估锁方法执行时间是 200ms，放大5倍后，设置超时时间是 1s（过期时间确定）。假想一下，如果生产环境中，锁方法中的 IO操作，极端情况下超时严重，比方说 IO就消耗了 2s（业务执行时长不确定），那就意味着，在这次 IO还没有结束的时候，这把锁已经到期释放掉了，就意味着别的线程趁虚而入，分布式锁崩溃！

一把分布式锁的目的是同一时刻只有一个线程持有锁，作为服务而言，这个锁现在不管是被哪个线程上锁成功了，服务应该保证这个线程执行的安全性，怎么办？锁续命（看门狗机制）。当锁出现了上锁操作，就意味着这把锁开始投入使用，这时服务中需要有一个 daemon线程定时去守护我的锁的安全性，怎么守护？比如说锁超时时间设置的是 1s，那么这个定时任务是每隔 300ms去 redis服务端做一次检查，就像 session会话的活跃机制一样。看个例子，超时时间设置的是 1s，实际方法执行时间是 3s，定时线程每隔 300ms就会去把这把锁的超时时间重新设置为 1s，每隔 300ms一次，成功将锁续命成功。

public class RedisLockIdleThreadPool { private String threadAddLife_lua = "if redis.call(\"exists\", KEYS[1]) == 1\n" + "then\n" + " return redis.call(\"expire\", KEYS[1], ARGV[1])\n" + "else\n" + " return 0\n" + "end";
private volatile ScheduledExecutorService scheduledThreadPool;
public RedisLockIdleThreadPool() {
if (scheduledThreadPool == null) { synchronized (this) { if (scheduledThreadPool == null) { scheduledThreadPool = Executors.newSingleThreadScheduledExecutor(); // 我这样创建线程池是为了代码的易读性，大家务必使用ThreadPoolExecutor去创建
scheduledThreadPool.scheduleAtFixedRate(() -> { addLife(); }, 0, 300, TimeUnit.MILLISECONDS); } } } }
private void addLife() { // ... 省略jedis的初始化过程
List<byte[]> keys = Arrays.asList(RedisLock.lock_key.getBytes()); List<byte[]> args = Arrays.asList(String.valueOf(1).getBytes());
jedis.eval(threadAddLife_lua.getBytes(), keys, args); }
}

除此之外，如果每个服务中都像如此续命锁，假如说A服务还在执行过程中的时候，还没有执行完，就是说还没有手动释放锁的时候，宕机，此时 redis中锁还在有效期。

续命的前提是，得判断是不是当前进程持有的锁，也就是 APP_ID，如果不是就不进行续命。续命锁的 lua脚本发生改变，如下：

THREAD_ADD_LIFE("local v=redis.call(\"get\", KEYS[1]) \n" + // get key "if v==false \n" + // 如果不存在key，读出结果v是false "then \n" + // 不存在不处理 "else \n" + " local match = string.find(v, ARGV[1]) \n" + // 存在，判断是否能和APP_ID匹配，匹配不上时match是nil " if match==\"nil\" \n" + " then \n" + " else \n" + " return redis.call(\"expire\", KEYS[1], ARGV[2]) \n" + // 匹配上了返回的是索引位置，如果匹配上了意味着就是当前进程占有的锁，就延长时间 " end \n" + "end")

6-1 等待锁超时释放

即便设置了一个很合理的 expire，比如 10s，但是线上如果真出现了A节点刚拿到锁就宕机了，那其他节点也只能干等10s，之后才能拿到锁。主要还是业务能不能接受。而如果是 To C的业务中，大部分场景无法接受的，因为可能会导致用户流失。所以需要另外一个监控服务，定时去监控 redis中锁的获得者的健康状态，如果获取者超过n次无法通信，由监控服务负责将锁摘除掉，让别的线程继续去获取到锁去干活。

07结语

分布式锁的五大特性：互斥、不会发生死锁、解铃还须系铃人、可重入性、具有容错性 非常重要。不同的分布式锁的实现方式中蕴含着相同的五大特性，目前的系统开发中普遍存在五大特性对应的场景，因此了解每个特性背后的技术尤其重要，了解分布式锁的背后原理，在适合的场景使用锁，不要盲目加锁，不要盲目扩大锁的范围，知其然知其所以然。

参考阅读：

• 腾讯专家10年沉淀：后海量时代的架构设计

• 阿里、字节跳动等知名架构师分享：2023年最新架构演进与发展趋势
  

• vivo 推送系统的容灾建设与实践
  

• 百度工程师的软件质量与测试随笔

• 深入浅出带你走进Redis！
  

本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿