当前位置：首页 > article >正文

锁相关的问题（死锁、互斥锁、自旋锁、读写锁、悲观锁、乐观锁）

article 2025/1/23 10:44:41

怎么避免死锁

⾯试过程中，死锁也是⾼频的考点，因为如果线上环境真多发⽣了死锁，那真的出⼤事了。

这次，我们就来系统地聊聊死锁的问题。

死锁的概念；
模拟死锁问题的产⽣；
利⽤⼯具排查死锁问题；
避免死锁问题的发⽣；

死锁的概念

在多线程编程中，我们为了防⽌多线程竞争共享资源⽽导致数据错乱，都会在操作共享资源之前加上互斥锁，只有成功获得到锁的线程，才能操作共享资源，获取不到锁的线程就只能等待，直到锁被释放。

那么，当两个线程为了保护两个不同的共享资源⽽使⽤了两个互斥锁，那么这两个互斥锁应⽤不当的时候，可能会造成 两个线程都在等待对方释放锁 ，在没有外⼒的作⽤下，这些线程会⼀直相互等待，就没办法继续运⾏，这种情况就是发⽣了死锁。

举个例⼦，⼩林拿了⼩美房间的钥匙，⽽⼩林在⾃⼰的房间⾥，⼩美拿了⼩林房间的钥匙，⽽⼩美也在⾃⼰的房间⾥。如果⼩林要从⾃⼰的房间⾥出去，必须拿到⼩美⼿中的钥匙，但是⼩美要出去，⼜必须拿到⼩林⼿中的钥匙，这就形成了死锁。

死锁只有 同时满⾜ 以下四个条件才会发⽣：

互斥条件；
持有并等待条件；
不可剥夺条件；
环路等待条件；

互斥条件

互斥条件是指 多个线程不能同时使⽤同⼀个资源 。

⽐如下图，如果线程 A 已经持有的资源，不能再同时被线程 B 持有，如果线程 B 请求获取线程 A 已经占⽤的资源，那线程 B 只能等待，直到线程 A 释放了资源。

持有并等待条件

持有并等待条件是指，当线程 A 已经持有了资源 1 ，⼜想申请资源 2 ，⽽资源 2 已经被线程 C 持有了，所以线程 A 就会处于等待状态，但是线程 A 在等待资源 2 的同时并不会释放自己已经持有的资源 1 。

不可剥夺条件

不可剥夺条件是指，当线程已经持有了资源， 在自己使用完之前不能被其他线程获取 ，线程 B 如果也想使⽤此资源，则只能在线程 A 使⽤完并释放后才能获取。

环路等待条件

环路等待条件指都是，在死锁发⽣的时候， 两个线程获取资源的顺序构成了环形链 。

⽐如，线程 A 已经持有资源 2 ，⽽想请求资源 1 ，线程 B 已经获取了资源 1 ，⽽想请求资源 2 ，这就形成资源请求等待的环形图。

模拟死锁问题的产生

Talk is cheap. Show me the code.

下⾯，我们⽤代码来模拟死锁问题的产⽣。

⾸先，我们先创建 2 个线程，分别为线程 A 和线程 B ，然后有两个互斥锁，分别是 mutex_A 和

mutex_B ，代码如下：

接下来，我们看下线程 A 函数做了什么。

可以看到，线程 A 函数的过程：

先获取互斥锁 A，然后睡眠 1 秒；
再获取互斥锁 B，然后释放互斥锁 B；
最后释放互斥锁 A；

可以看到，线程 B 函数的过程：

先获取互斥锁 B，然后睡眠 1 秒；
再获取互斥锁 A，然后释放互斥锁 A；
最后释放互斥锁 B；

可以看到线程 B 在等待互斥锁 A 的释放，线程 A 在等待互斥锁 B 的释放，双⽅都在等待对⽅资源的释放，很明显，产⽣了死锁问题。

利用工具排查死锁问题

如果你想排查你的 Java 程序是否死锁，则可以使⽤ jstack ⼯具，它是 jdk ⾃带的线程堆栈分析⼯具。

由于这个死锁代码例⼦是 C 写的，在 Linux 下，我们可以使⽤ pstack + gdb ⼯具来定位死锁问题。

pstack 命令可以显示每个线程的栈跟踪信息（函数调⽤过程），它的使⽤⽅式也很简单，只需要 pstack <pid> 就可以了。

那么，在定位死锁问题时，我们可以多次执⾏ pstack 命令查看线程的函数调⽤过程，多次对⽐结果，确认哪⼏个线程⼀直没有变化，且是因为在等待锁，那么⼤概率是由于死锁问题导致的。

我⽤ pstack 输出了我前⾯模拟死锁问题的进程的所有线程的情况，我多次执⾏命令后，其结果都⼀样，如下：

可以看到， Thread 2 和 Thread 3 ⼀直阻塞获取锁（ pthread_mutex_lock ）的过程，⽽且 pstack 多次输出信息都没有变化，那么可能⼤概率发⽣了死锁。

但是，还不能够确认这两个线程是在互相等待对⽅的锁的释放，因为我们看不到它们是等在哪个锁对象，于是我们可以使⽤ gdb ⼯具进⼀步确认。

整个 gdb 调试过程，如下：

我来解释下，上⾯的调试过程：

1. 通过 info thread 打印了所有的线程信息，可以看到有 3 个线程，⼀个是主线程（LWP 87746），另外两个都是我们⾃⼰创建的线程（LWP 87747 和 87748）；

2. 通过 thread 2 ，将切换到第 2 个线程（LWP 87748）；

3. 通过 bt ，打印线程的调⽤栈信息，可以看到有 threadB_proc 函数，说明这个是线程 B 函数，也就说 LWP 87748 是线程 B;

4. 通过 frame 3 ，打印调⽤栈中的第三个帧的信息，可以看到线程 B 函数，在获取互斥锁 A 的时候阻塞了；

5. 通过 p mutex_A ，打印互斥锁 A 对象信息，可以看到它被 LWP 为 87747（线程 A）的线程持有着；

6. 通过 p mutex_B ，打印互斥锁 A 对象信息，可以看到他被 LWP 为 87748 （线程 B）的线程持有着；

因为线程 B 在等待线程 A 所持有的 mutex_A, ⽽同时线程 A ⼜在等待线程 B 所拥有的 mutex_B, 所以可以断定该程序发⽣了死锁。

避免死锁问题的发生

前⾯我们提到，产⽣死锁的四个必要条件是：互斥条件、持有并等待条件、不可剥夺条件、环路等待条件。

那么避免死锁问题就只需要破环其中⼀个条件就可以，最常⻅的并且可⾏的就是使用 资源有序分配法，来 破环环路等待条件 。

那什么是资源有序分配法呢？

线程 A 和线程 B 获取资源的顺序要⼀样，当线程 A 是先尝试获取资源 A ，然后尝试获取资源 B 的时候，线程 B 同样也是先尝试获取资源 A ，然后尝试获取资源 B 。也就是说，线程 A 和线程 B 总是以相同的顺序申请⾃⼰想要的资源。

我们使⽤资源有序分配法的⽅式来修改前⾯发⽣死锁的代码，我们可以不改动线程 A 的代码。

我们先要清楚线程 A 获取资源的顺序，它是先获取互斥锁 A ，然后获取互斥锁 B 。

所以我们只需将线程 B 改成以相同顺序的获取资源，就可以打破死锁了。

线程 B 函数改进后的代码如下：

执行结果如下，可以看，没有发生死锁。

总结

简单来说，死锁问题的产⽣是由两个或者以上线程并⾏执⾏的时候，争夺资源⽽互相等待造成的。

死锁只有同时满⾜互斥、持有并等待、不可剥夺、环路等待这四个条件的时候才会发⽣。

所以要避免死锁问题，就是要破坏其中⼀个条件即可，最常⽤的⽅法就是使⽤资源有序分配法来破坏环路等待条件。

什么是乐观锁、悲观锁

⽣活中⽤到的锁，⽤途都⽐较简单粗暴，上锁基本是为了防⽌外⼈进来、电动⻋被偷等等。

但⽣活中也不是没有 BUG 的，⽐如加锁的电动⻋在「⼴⻄ - 窃 · 格瓦拉」⾯前，锁就是形同虚设，只要他愿意，他就可以轻轻松松地把你电动⻋给「顺⾛」，不然打⼯怎么会是他这辈⼦不可能的事情呢？⽜逼之⼈，必有⽜逼之处。

那在编程世界⾥，「锁」更是五花⼋⻔，多种多样，每种锁的加锁开销以及应⽤场景也可能会不同。

如何⽤好锁，也是程序员的基本素养之⼀了。

⾼并发的场景下，如果选对了合适的锁，则会⼤⼤提⾼系统的性能，否则性能会降低。

所以，知道各种锁的开销，以及应⽤场景是很有必要的。

接下来，就谈⼀谈常⻅的这⼏种锁

多线程访问共享资源的时候，避免不了资源竞争⽽导致数据错乱的问题，所以我们通常为了解决这⼀问题，都会在访问共享资源之前加锁。

最常⽤的就是互斥锁，当然还有很多种不同的锁，⽐如⾃旋锁、读写锁、乐观锁等，不同种类的锁⾃然适⽤于不同的场景。

如果选择了错误的锁，那么在⼀些⾼并发的场景下，可能会降低系统的性能，这样⽤户体验就会⾮常差了。

所以，为了选择合适的锁，我们不仅需要清楚知道加锁的成本开销有多⼤，还需要分析业务场景中访问的共享资源的⽅式，再来还要考虑并发访问共享资源时的冲突概率。

对症下药，才能减少锁对⾼并发性能的影响。

那接下来，针对不同的应⽤场景，谈⼀谈「 互斥锁、自旋锁、读写锁、乐观锁、悲观锁 」的选择和使⽤。

互斥锁和自旋锁

互斥锁和自选锁，谁更轻松自如？

最底层的两种就是「互斥锁和⾃旋锁」，有很多⾼级的锁都是基于它们实现的，你可以认为它们是各种锁的地基，所以我们必须清楚它俩之间的区别和应⽤。

加锁的⽬的就是保证共享资源在任意时间⾥，只有⼀个线程访问，这样就可以避免多线程导致共享数据错乱的问题。

当已经有⼀个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理⽅式是不⼀样的：

互斥锁加锁失败后，线程会释放 CPU ，给其他线程；
自旋锁加锁失败后，线程会忙等待，直到它拿到锁；

互斥锁是⼀种「独占锁」，⽐如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，只要线程 A 没有释放⼿中的锁，线程 B 加锁就会失败，于是就会释放 CPU 让给其他线程， 既然线程 B 释放掉了 CPU ，自 然线程 B 加锁的代码就会被阻塞 。

对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的 。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执⾏。如下图：

所以，互斥锁加锁失败时，会从⽤户态陷⼊到内核态，让内核帮我们切换线程，虽然简化了使⽤锁的难度，但是存在⼀定的性能开销成本。

那这个开销成本是什么呢？会有 两次线程上下文切换的成本 ：

当线程加锁失败时，内核会把线程的状态从「运⾏」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运⾏；
接着，当锁被释放时，之前「睡眠」状态的线程会变为「就绪」状态，然后内核会在合适的时间，把CPU 切换给该线程运⾏。

线程的上下⽂切换的是什么？当两个线程是属于同⼀个进程， 因为虚拟内存是共享的，所以在切换时，虚 拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

上下切换的耗时有⼤佬统计过，⼤概在⼏⼗纳秒到⼏微秒之间，如果你锁住的代码执⾏时间⽐较短，那可能上下⽂切换的时间都⽐你锁住的代码执⾏时间还要⻓。

所以， 如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥 锁。

⾃旋锁是通过 CPU 提供的 CAS 函数（ Compare And Swap ），在「⽤户态」完成加锁和解锁操作，不会主动产⽣线程上下⽂切换，所以相⽐互斥锁来说，会快⼀些，开销也⼩⼀些。

⼀般加锁的过程，包含两个步骤：

第⼀步，查看锁的状态，如果锁是空闲的，则执⾏第⼆步；
第⼆步，将锁设置为当前线程持有；

CAS 函数就把这两个步骤合并成⼀条硬件级指令，形成 原⼦指令 ，这样就保证了这两个步骤是不可分割的，要么⼀次性执⾏完两个步骤，要么两个步骤都不执⾏。

使⽤⾃旋锁的时候，当发⽣多线程竞争锁的情况，加锁失败的线程会「忙等待」，直到它拿到锁。这⾥的「忙等待」可以⽤ while 循环等待实现，不过最好是使⽤ CPU 提供的 PAUSE 指令来实现「忙等待」，因为可以减少循环等待时的耗电量。

⾃旋锁是最⽐较简单的⼀种锁，⼀直⾃旋，利⽤ CPU 周期，直到锁可⽤。 需要注意，在单核 CPU 上，需 要抢占式的调度器（即不断通过时钟中断⼀个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用 ，因为⼀个自旋的线程永远不会放弃 CPU 。

⾃旋锁开销少，在多核系统下⼀般不会主动产⽣线程切换，适合异步、协程等在⽤户态切换请求的编程⽅式，但如果被锁住的代码执⾏时间过⻓，⾃旋的线程会⻓时间占⽤ CPU 资源，所以⾃旋的时间和被锁住的代码执⾏的时间是成「正⽐」的关系，我们需要清楚的知道这⼀点。

⾃旋锁与互斥锁使⽤层⾯⽐较相似，但实现层⾯上完全不同： 当加锁失败时，互斥锁⽤「线程切换」来应 对，自旋锁则用「忙等待」来应对 。

它俩是锁的最基本处理⽅式，更⾼级的锁都会选择其中⼀个来实现，⽐如读写锁既可以选择互斥锁实现，也可以基于⾃旋锁实现。