基于Redis实现的分布式锁的可用性探索1

在现代计算机系统中，随着多核处理器的广泛应用和分布式系统的蓬勃发展，多线程编程已成为常态。多线程环境下，资源共享带来了高效性，但同时也引发了一系列严峻的问题，其中最为突出的便是线程安全问题。当多个线程同时访问和操作共享数据时，数据的一致性和完整性面临巨大挑战，可能导致数据错误、程序异常甚至系统崩溃等严重后果。

在 Java 编程领域，传统的 JVM 锁机制，如 synchronized 关键字和 ReentrantLock，在单进程或单节点应用中有效地解决了线程安全问题。它们基于线程在同一 JVM 内存空间中运行的特性，通过互斥访问共享资源来确保数据一致性。然而，随着分布式系统的兴起，应用架构发生了根本性变化。分布式系统由多个独立的节点组成，这些节点可能分布在不同的服务器上，运行在各自独立的 JVM 中，彼此之间通过网络通信协作。在这种分布式环境下，JVM 锁机制的局限性逐渐显现。由于每个节点的 JVM 内存相互独立，无法实现跨节点的线程互斥，传统的锁机制无法保证分布式系统中共享资源的一致性访问。例如，在一个分布式电商系统中，多个节点可能同时处理订单操作，如果没有有效的分布式锁机制，可能会出现超卖等问题。

为了满足分布式系统对共享资源一致性访问的需求，分布式锁应运而生。它提供了一种在分布式环境下实现互斥访问的机制，确保在任何时刻，只有一个节点能够获取特定资源的锁，从而保证数据的一致性和完整性。Redis，作为一款高性能的内存数据库，以其出色的性能、丰富的数据结构和原子操作特性，成为了实现分布式锁的理想选择之一。其内存存储和快速读写能力使得获取和释放锁的操作能够高效执行，而原子操作保证了锁操作的完整性和可靠性。通过 Redis 实现分布式锁，可以有效地解决分布式系统中的并发冲突问题，为分布式应用的稳定运行提供有力支持。

JVM锁

所谓JVM锁，其实指的是诸如synchronized关键字或者ReentrantLock实现的锁。之所以统称为JVM锁，是因为我们的项目其实都是跑在JVM上的。理论上每一个项目启动后，就对应一片JVM内存，后续运行时数据的生离死别都在这一片土地上。

什么是锁、怎么锁？

明白了“JVM锁”名字的由来，我们再来聊什么是“锁”，以及怎么“锁”。

有时候我们很难阐述清楚某个事物是什么，但很容易解释它能干什么，JVM锁也是这个道理。JVM锁的出现，就是为了解决线程安全问题。所谓线程安全问题，可以简单地理解为数据不一致（与预期不一致）。

什么时候可能出现线程安全问题呢？

当同时满足以下三个条件时，才可能引发线程安全问题：

• 多线程环境

• 有共享数据

• 有多条语句操作共享数据/单条语句本身非原子操作（比如i++虽然是单条语句，但并非原子操作）

比如线程A、B同时对int count进行+1操作（初始值假设为1），在一定的概率下两次操作最终结果可能为2，而不是3。

那么加锁为什么能解决这个问题呢？

如果不考虑原子性、内存屏障等晦涩的名词，加锁之所以能保证线程安全，核心就是“互斥”。所谓互斥，就是字面意思上的互相排斥。这里的“互相”是指谁呢？就是多线程之间！

怎么实现多线程之间的互斥呢？

引入“中间人”即可。

注意，这是个非常简单且伟大的思想。在编程世界中，通过引入“中介”最终解决问题的案例不胜枚举，包括但不限于Spring、MQ。在码农之间，甚至流传着一句话：没有什么问题是引入中间层解决不了的。

而JVM锁其实就是线程和线程彼此的“中间人”，多个线程在操作加锁数据前都必须征求“中间人”的同意：

锁在这里扮演的角色其实就是守门员，是唯一的访问入口，所有的线程都要经过它的拷问。在JDK中，锁的实现机制最常见的就是两种，分别是两个派系：

• synchronized关键字
• AQS

个人觉得synchronized关键字要比AQS难理解，但AQS的源码比较抽象。这里简要介绍一下Java对象内存结构和synchronized关键字的实现原理。

Java对象内存结构

要了解synchronized关键字，首先要知道Java对象的内存结构。强调一遍，是Java对象的内存结构。

它的存在仿佛向我们抛出一个疑问：如果有机会解剖一个Java对象，我们能看到什么？

右上图画了两个对象，只看其中一个即可。我们可以观察到，Java对象内存结构大致分为几块：

• Mark Word（锁相关）

• 元数据指针（class pointer，指向当前实例所属的类）

• 实例数据（instance data，我们平常看到的仅仅是这一块）

• 对齐（padding，和内存对齐有关）

如果此前没有了解过Java对象的内存结构，你可能会感到吃惊：天呐，我还以为Java对象就只有属性和方法！

是的，我们最熟悉实例数据这一块，而且以为只有这一块。也正是这个观念的限制，导致一部分初学者很难理解synchronized。比如初学者经常会疑惑：

• 为什么任何对象都可以作为锁？

• Object对象锁和类锁有什么区别？

• synchronized修饰的普通方法使用的锁是什么？

• synchronized修饰的静态方法使用的锁是什么？

这一切的一切，其实都可以在Java对象内存结构中的Mark Word找到答案：

Mark Word包含的信息还是蛮多的，但这里我们只需要简单地把它理解为记录锁信息的标记即可。上图展示的是32位虚拟机下的Java对象内存，如果你仔细数一数，会发现全部bit加起来刚好是32位。64位虚拟机下的结构大同小异，就不特别介绍。

Mark Word从有限的32bit中划分出2bit，专门用作锁标志位，通俗地讲就是标记当前锁的状态。

正因为每个Java对象都有Mark Word，而Mark Word能标记锁状态（把自己当做锁），所以Java中任意对象都可以作为synchronized的锁：

synchronized(person){
}
synchronized(student){
}

所谓的this锁就是当前对象，而Class锁就是当前对象所属类的Class对象，本质也是Java对象。synchronized修饰的普通方法底层使用当前对象作为锁，synchronized修饰的静态方法底层使用Class对象作为锁。

但如果要保证多个线程互斥，最基本的条件是它们使用同一把锁：

对同一份数据加两把不同的锁是没有意义的，实际开发时应该注意避免下面的写法：

synchronized(Person.class){
    // 操作count
}

synchronized(person){
    // 操作count
}

或者

public synchronized void method1(){
    // 操作count
}

public static synchronized void method1(){
    // 操作count
}

synchronized与锁升级

大致介绍完Java对象内存结构后，我们再来解决一个新疑问：

为什么需要标记锁的状态呢？是否意味着synchronized锁有多种状态呢？

在JDK早期版本中，synchronized关键字的实现是直接基于重量级锁的。只要我们在代码中使用了synchronized，JVM就会向操作系统申请锁资源（不论当前是否真的是多线程环境），而向操作系统申请锁是比较耗费资源的，其中涉及到用户态和内核态的切换等，总之就是比较费事，且性能不高。

JDK为了解决JVM锁性能低下的问题，引入了ReentrantLock，它基于CAS+AQS，类似自旋锁。自旋的意思就是，在发生锁竞争的时候，未争取到锁的线程会在门外采取自旋的方式等待锁的释放，谁抢到谁执行。

自旋锁的好处是，不需要兴师动众地切换到内核态申请操作系统的重量级锁，在JVM层面即可实现自旋等待。但世界上并没有百利而无一害的灵丹妙药，CAS自旋虽然避免了状态切换等复杂操作，却要耗费部分CPU资源，尤其当可预计上锁的时间较长且并发较高的情况下，会造成几百上千个线程同时自旋，极大增加CPU的负担。

synchronized毕竟JDK亲儿子，所以大概在JDK1.6或者更早期的版本，官方对synchronized做了优化，提出了“锁升级”的概念，把synchronized的锁划分为多个状态，也就是上图中提到的：

• 无锁

• 偏向锁

• 轻量级锁（自旋锁）

• 重量级锁

无锁就是一个Java对象刚new出来的状态。当这个对象第一次被一个线程访问时，该线程会把自己的线程id“贴到”它的头上（Mark Word中部分位数被修改），表示“你是我的”：

此时是不存在锁竞争的，所以并不会有什么阻塞或等待。

为什么要设计“偏向锁”这个状态呢？

其实大部分项目的大部分时候，某个变量都是单个线程在执行，此时直接向操作系统申请重量级锁显然没有必要，因为根本不会发生线程安全问题。

而一旦发生锁竞争时，synchronized便会在一定条件下升级为轻量级锁，可以理解为一种自旋锁，具体自旋多少次以及何时放弃自旋，JDK也有一套相关的控制机制，大家可以自行了解。

同样是自旋，所以synchronized也会遇到ReentrantLock的问题：如果上锁时间长且自旋线程多，又该如何？

此时就会再次升级，变成传统意义上的重量级锁，本质上操作系统会维护一个队列，用空间换时间，避免多个线程同时自旋等待耗费CPU性能，等到上一个线程结束时唤醒等待的线程参与新一轮的锁竞争即可。

synchronized案例

• 同一个类中的synchronized method m1和method m2互斥吗？

t1线程执行m1方法时要去读this对象锁，但是t2线程并不需要读锁，两者各管各的，没有交集（不共用一把锁）

• 同一个类中synchronized method m1中可以调用synchronized method m2吗？

synchronized是可重入锁，可以粗浅地理解为同一个线程在已经持有该锁的情况下，可以再次获取锁，并且会在某个状态量上做+1操作（ReentrantLock也支持重入）

• 子类同步方法synchronized method m可以调用父类的synchronized method m吗？

子类对象初始化前，会调用父类构造方法，在结构上相当于包裹了一个父类对象，用的都是this锁对象

• 静态同步方法和非静态同步方法互斥吗？

各玩各的，不是同一把锁，谈不上互斥

Redis分布式锁的概念

谈到Redis分布式锁，总是会有这样或那样的疑问：

• 什么是分布式

• 什么是分布式锁

• 为什么需要分布式锁

• Redis如何实现分布式锁

前3个问题其实可以一起回答，至于Redis如何实现分布式锁，我们放在下一篇。

什么是分布式？这是个很复杂的概念，我也很难说准确，所以干脆画个图，大家各花入各眼吧：

分布式有个很显著的特点是，Service A和Service B极有可能并不是部署在同一个服务器上，所以它们也不共享同一片JVM内存。而上面介绍了，要想实现线程互斥，必须保证所有访问的线程使用的是同一把锁（JVM锁此时就无法保证互斥）。

对于分布式项目，有多少台服务器就有多少片JVM内存，即使每片内存中各设置一把“独一无二”的锁，从整体来看项目中的锁就不是唯一的。

此时，如何保证每一个JVM上的线程共用一把锁呢？

答案是：把锁抽取出来，让线程们在同一片内存相遇。

但锁是不能凭空存在的，本质还是要在内存中，此时可以使用Redis缓存作为锁的宿主环境，这就是Redis能构造分布式锁的原因。

Redis的锁长啥样

synchronized关键字和ReentrantLock，它们都是实实在在已经实现的锁，而且还有标志位啥的。但Redis就是一个内存…怎么作为锁呢?

有一点大家要明确，Redis之所以能用来做分布式锁，肯定不只是因为它是一片内存，否则JVM本身也占有内存，为什么无法自己实现分布式锁呢？

我个人的理解是，要想自定义一个分布式锁，必须至少满足几个条件：

• 多进程可见（独立于多节点系统之外的一片内存）

• 互斥（可以通过单线程，或者某种顺序机制）

• 可重入

还有个条件，默认要支持：只有持有这把锁的客户端才能解锁

以上三点Redis都能满足。在上面三个条件下，其实怎么设计锁，完全取决于个人如何定义锁。就好比现实生活中，通常我们理解的锁就是有个钥匙孔、需要插入钥匙的金属小物件。然而锁的形态可不止这么一种，随着科技的发展，什么指纹锁、虹膜锁层出不穷，但归根结底它们之所以被称为“锁”，是因为都保证了“互斥”（我行，你不行）。

如果我们能设计一种逻辑，它能造成某个场景下的“互斥事件”，那么它就可以被称为“锁”。比如，某家很有名的网红店，一天只接待一位客人。门口没有营业员，就放了一台取号机，里面放了一张票。你如果去迟了，票就没了，你就进不了这家店。这个场景下，没票的顾客进不去，被锁在门外。此时，取票机造成了“互斥事件”，那么它就可以叫做“锁”。

而Redis提供了setnx指令，如果某个key当前不存在则设置成功并返回true，否则不再重复设置，直接返回false。这不就是编程界的取号机吗？当然，实际用到的命令可不止这一个，具体如何实现，请看下一篇~

这一篇从JVM锁聊到了Redis分布式锁，还介绍了Java的对象内存结构及synchronized底层的原理，相信大家对“锁”已经有了自己的感性认识。下一篇我们将通过分布式定时任务的案例介绍Redis分布式锁的使用场景。

思考一个问题：分布式系统是否一定要分布式锁？

分布式系统如果要加锁是否一定要使用分布式锁呢？

可能未必。

如果你需要的是写锁，那么可能确实需要分布式锁保证单一线程处理数据，而如果是为了防止缓存击穿（热点数据定时失效），那么使用JVM本地锁也没有太大关系。比如某个服务有10个节点，在使用JVM锁的情况下，即使某一时刻每个节点各自涌入1000个请求，虽然总共有1w个请求，但最终打到数据库的也只有10个，数据库层面是完全可以抗住这点请求量的，又由于本身是查询，所以不会造成线程安全问题。