《锁饥饿：能抢却抢不到的并发困境》

前言

在多线程编程中，锁饥饿（Lock Starvation）是一个容易被忽视但后果严重的并发问题。很多开发者听说过“死锁”，但对“饥饿”的理解往往停留在“线程拿不到锁”的模糊概念上。本文将用生动的比喻、可运行的代码以及底层原理分析，带你彻底搞懂锁饥饿的本质、产生原因及解决方案，让你在使用ReentrantLock等锁时不再踩坑。

一、锁饥饿 vs 死锁，别再傻傻分不清

在正式讲解之前，我们先明确两个容易混淆的概念：

简单来说，死锁是“大家都动不了”，饥饿是“有人一直在跑，有人永远轮不到”。

二、生活化比喻：从银行办业务秒懂锁饥饿

想象你去银行办理业务，有两种不同的叫号机制：

1. 公平锁场景：银行严格按取号顺序叫号。即使你是普通客户，VIP客户来了也得取号排队——先到的人一定先办业务，不会有人被“饿死”。
2. 非公平锁场景：银行允许新进门的客户直接冲到窗口（如果窗口刚好空闲）。
   - 你排队等了1小时，终于轮到你了，窗口刚空，突然冲进来一个新客户直接办业务——你被截胡了。
   - 如果新客户源源不断，每次窗口一空就有人冲上去，那么你永远轮不到，这就是锁饥饿。

在这个比喻中：

• 你 =等待队列的队首线程（最早开始等待的线程）
• 新客户 =新尝试抢锁的线程
• 窗口 =锁
• 办业务 =拿到锁执行代码
• 锁饥饿 =队首线程被新线程持续截胡，永远拿不到锁

三、代码复现：用ReentrantLock直观演示锁饥饿

下面我们用ReentrantLock的非公平模式（默认）来复现锁饥饿场景。代码中有一个“受害者线程”最先开始等待锁，随后启动10个“插队线程”疯狂抢锁，看看会发生什么。

import java.util.concurrent.locks.ReentrantLock; public class LockStarvationDemo { // 非公平锁（默认）：新线程可以插队 private static final ReentrantLock unfairLock = new ReentrantLock(false); public static void main(String[] args) { // 受害者线程：第一个来等待锁，却一直被插队 Thread victimThread = new Thread(() -> { int count = 0; while (true) { unfairLock.lock(); try { // 如果能拿到锁，打印次数 System.out.println("受害者线程拿到锁！次数：" + (++count)); Thread.sleep(1); // 模拟业务操作，很快释放锁 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { unfairLock.unlock(); } } }, "受害者线程"); victimThread.start(); // 让受害者线程先启动，确保它最先进入等待队列 try { Thread.sleep(10); } catch (InterruptedException e) { } // 启动10个插队线程，持续抢锁 for (int i = 1; i <= 10; i++) { int index = i; Thread insertThread = new Thread(() -> { while (true) { unfairLock.lock(); try { System.out.println("插队线程" + index + "抢到锁"); Thread.sleep(1); // 同样快速释放 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { unfairLock.unlock(); } } }, "插队线程" + i); insertThread.start(); } } }

运行结果观察（可能因环境略有不同）：

• 控制台几乎被“插队线程X抢到锁”刷屏。
• “受害者线程拿到锁！次数：1”可能偶尔出现一两次，之后几乎不再出现。
• 即使程序运行很久，受害者线程也很难再拿到锁——这就是典型的锁饥饿。

四、核心拆解：为什么新线程能一直截胡队首线程？

可能会疑惑：那假如有10个插队线程，肯定只有一个可以抢到，其他不应该变为等待线程吗？为什么上述结果中其他9个线程不是新线程了，还能一直插队？

4.1 非公平锁的“插队规则”

非公平锁的抢锁逻辑是：

• 当锁被释放时，等待队列中的队首线程（受害者）被唤醒，准备参与竞争。
• 但与此同时，新来的线程（或者刚释放锁的线程）可以直接尝试CAS抢锁，不需要排队。
• 如果新线程抢锁成功，队首线程的唤醒就白费了，它只能再次进入等待。

4.2 插队线程的循环逻辑：为什么它们几乎不进队列？

仔细观察插队线程的行为：

- 抢锁 → 拿到锁 → 执行1ms → 释放锁 → 立刻再次抢锁（又变成“新线程”）

它们永远处于“抢锁成功→释放→立刻再抢”的循环中。
- 在非公平锁下，这些线程抢锁的成功率极高，因为锁刚释放，它们立刻尝试，几乎每次都能成功。
-只有抢锁失败的线程才会进入等待队列。而这些线程很少失败，所以它们几乎不会进入队列，永远是“新线程”身份。

用银行比喻再细化：这10个插队线程永远是“窗口旁的新客户”——办完业务后不排队，就在窗口边等着，窗口一空又立刻冲上去，全程没有机会进入等待队列，自然永远是“能插队的新线程”。

4.3 路径+时序优势：新线程抢赢队首线程的底层原因

即使偶尔有插队线程抢锁失败，队首线程也往往抢不过其他插队线程，原因有两个：

1. 路径优势：
   - 新线程抢锁只需在用户态执行CAS操作，非常快。
   - 队首线程被唤醒需要从内核态切换回用户态（涉及上下文切换），存在延迟。
2. 时序优势：
   - 新线程是“主动轮询”，可以持续检测锁状态。
   - 队首线程是“被动唤醒”，必须等待操作系统调度，往往慢一拍。

即使有多个插队线程竞争，失败的线程也会进入短暂的自旋等待（忙等），在用户态反复尝试CAS，不会立刻进入等待队列。只有当自旋次数超过阈值，才会进入内核态等待队列。但因为锁释放极快，它们很快又被唤醒，继续自旋抢锁——所以很难成为“长期等待线程”。

五、解决锁饥饿：从非公平到公平，代价与取舍

解决锁饥饿最直接的方法就是使用公平锁。只需将锁的创建改为：

private static final ReentrantLock fairLock = new ReentrantLock(true);

公平锁强制新线程必须排队，不允许插队。修改后再次运行代码，你会发现：

• 受害者线程和插队线程会交替拿到锁，每个线程都能公平执行。
• 不会再出现某个线程长期得不到执行的情况。

公平锁的代价

公平锁虽然解决了饥饿，但付出了性能代价：

• 需要维护一个FIFO队列，增加了锁管理的开销。
• 吞吐量通常比非公平锁低，因为严格排队可能降低并发度。

其他缓解措施

除了公平锁，还可以通过控制新线程的创建速度、增加线程的休眠时间等方式降低插队频率，但无法从根本上杜绝饥饿。如果系统对实时性要求高，建议直接使用公平锁。

六、总结：三句话牢记锁饥饿

1. 锁饥饿只发生在非公平锁：新线程持续截胡等待队列的队首线程。
2. 饥饿≠死锁：饥饿是“能抢但永远抢不到”，死锁是“互相等，根本没法抢”。
3. 解决饥饿的核心：用公平锁（放弃插队），或限制新线程的抢锁频率。