Redis分布式锁（上篇）

约定不等于承诺〃 2024-04-07 12:51 51阅读 0赞

不论面试还是实际工作中，Redis都是避无可避的技术点。在我心里，MySQL和Redis是衡量一个程序员是否“小有所成”的两把标尺。如果他能熟练使用MySQL和Redis，以小化大，充分利用现有资源出色地完成当下需求，说明他已经成长了。

本篇文章我们一起来探讨Redis分布式锁相关的内容。

说到锁，大家第一时间想到的应该是synchronized关键字或ReentrantLock，随即想到偏向锁、自旋锁、重量级锁或者CAS甚至AQS。一般来说，我不喜欢一下子引入这么多概念，可能会把问题弄复杂，但为了方便大家理解Redis分布式锁，这里稍微提一下。

JVM锁

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

什么是锁、怎么锁？

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

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

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

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

多线程环境  
有共享数据  
有多条语句操作共享数据/单条语句本身非原子操作（比如i++虽然是单条语句，但并非原子操作）  
比如线程A、B同时对int count进行+1操作（初始值假设为1），在一定的概率下两次操作最终结果可能为2，而不是3。

![9dec4e1a653a4a63883322c37237313e.png][]  
那么加锁为什么能解决这个问题呢？

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

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

引入“中间人”即可。

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

而JVM锁其实就是线程和线程彼此的“中间人”，多个线程在操作加锁数据前都必须去问问“中间人”它是否允许当前线程操作这个数据：

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

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

Java对象内存结构

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

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

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

Mark Word（锁相关）  
元数据指针（class pointer，指向当前实例所属的类）  
实例数据（instance data，我们平常看到的仅仅是这一块）  
对齐（padding，和内存对齐有关）  
如果此前没有了解过Java对象的内存结构，你可能会感到吃惊：天呐，我还以为Java对象就只有属性和方法！

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

为什么任何对象都可以作为锁？  
Object对象锁和类锁有什么区别？  
synchronized修饰的普通方法使用的锁是什么？  
synchronized修饰的静态方法使用的锁是什么？  
这一切的一切，其实都可以在Java对象内存结构中的Mark Word找到答案：

![ddd8bf9f45864a1394b88776d0cc2824.png][]  
很多同学可能是第一次看到这幅图，会感到有点懵，没关系，我也很头大，都一样的。

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对象作为锁。

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

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

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，类似自旋锁。自旋的意思就是，在发生锁竞争的时候，未争取到锁的线程会在门外采取自旋的方式等待锁的释放，谁抢到谁执行。

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

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

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

![569b377c0d6e4cd4b83b7d7f4aae9837.png][]  
此时是不存在锁竞争的，所以并不会有什么阻塞或等待。

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

大家回忆一下，项目中并发的场景真的这么多吗？并没有吧。大部分项目的大部分时候，某个变量都是单个线程在执行，此时直接向操作系统申请重量级锁显然没有必要，因为根本不会发生线程安全问题。

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

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

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

**synchronized案例**

让我们一起来看几个案例，加深对synchronized的理解。

同一个类中的synchronized method m1和method m2互斥吗？![3acbdca159484e8f8e5f9e9e09aeab17.png][]

t1线程执行m1方法时要去读this对象锁，但是t2线程并不需要读锁，两者各管各的，没有交集（不共用一把锁）  
同一个类中synchronized method m1中可以调用synchronized method m2吗？![1f3e059aa81b45c18962d85caf31b3c6.png][]

synchronized是可重入锁，可以粗浅地理解为同一个线程在已经持有该锁的情况下，可以再次获取锁，并且会在某个状态量上做+1操作（ReentrantLock也支持重入）  
子类同步方法synchronized method m可以调用父类的synchronized method m吗？![154fcb9cd25645f494e4d32e1b74aaf0.png][]

子类对象初始化前，会调用父类构造方法，在结构上相当于包裹了一个父类对象，用的都是this锁对象  
静态同步方法和非静态同步方法互斥吗？![89375277556a4279bb19b90f77a4697a.png][]

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

Redis分布式锁

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

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

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

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

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

![d9ba706266c7413ab8277cfc3857d8c3.png][]  
此时，如何保证每一个JVM上的线程共用一把锁呢？

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

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

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

下篇见。

[9dec4e1a653a4a63883322c37237313e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/3ee3c6b98c7d4aa9ac3c204a4a51a133.png
[f0605a98e3d1446392bd5a5d01f4b564.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/2f70efb0f4554863b29997d6fd8f5493.png
[7d8a0de7404440e3a7ca3abac551fc4f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/674a4daa2dc54cdea505e1c512e7b407.png
[ddd8bf9f45864a1394b88776d0cc2824.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/14ea9e1df5074566ba14d9fe7cbca136.png
[a9571d946e214cd0b92259373aa355c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/821a3c0255c340a7909be4d4b0ea3c4c.png
[61dff8b3f502415ab11bed61a334cca0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/01e83c1057c044329fa4444f495c2ee8.png
[262ced1a82d74faea26e8cc5c7ad9574.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/713f85d23b6f421da587fbcff23bc9c8.png
[569b377c0d6e4cd4b83b7d7f4aae9837.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/1f41aaa8e82a447d85aebb4fb34ee8f4.png
[3acbdca159484e8f8e5f9e9e09aeab17.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/9a4c07a78d6d452c8edde5a94d027f86.png
[1f3e059aa81b45c18962d85caf31b3c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/2931bdb975494a99b956dc5b673ae843.png
[154fcb9cd25645f494e4d32e1b74aaf0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/44b77d1ad8614543808357497afb3b2f.png
[89375277556a4279bb19b90f77a4697a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/838617160f3c473c97bdf162f0d1d0f3.png
[93f01ba758eb4edf8973f9b9e4684351.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/f40e0baef3434fc0828fdfc86ed139f2.png
[d9ba706266c7413ab8277cfc3857d8c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/763dd129afec49a789a297844d495ab6.png
[37d93c9a8f9644f2b42ff2452dbfeefa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/cd54517992fa4c75ac8c51db23899f0f.png