C++ 多线程互斥锁实战：解决竞态条件与死锁

这里的公共资源是 ticket。按照常理，票数减到 0 就应该停止。但运行结果往往会出现负数，比如 -4。为什么会这样？

原因分析

单线程下不会发生这种事，但在多线程环境下，竞争是常态。我们来看当票数为 1 时的情况：

1. 线程 1 读取 ticket 为 1，判断大于 0，准备休息（usleep）。
2. 线程 2 启动，也读取 ticket 为 1，同样判断大于 0，也准备休息。
3. 线程 1 醒来，执行 ticket--，票数变为 0。
4. 线程 2 醒来，基于之前读取的旧值（认为还是 1），再次执行 ticket--，票数变为 -1。

这就是经典的 Check-Then-Act Race（检查后执行竞争）。从汇编层面看，判断和减法不是原子操作：

; if (ticket > 0)
LOAD R1, [ticket] ; 读入寄存器
CMP R1, 0         ; 比较
JLE END_IF        ; 如果 <= 0 则跳过
usleep(1000)
; ticket--
LOAD R2, [ticket] ; 重新读内存（此时可能已被修改）
SUB R2, 1
STORE [ticket], R2

关键点在于：判断时用的是旧值，真正写回时又读了一次内存。中间的时间窗口被其他线程利用，导致数据不一致。

3. 引入互斥锁

为了防止这种乌龙，我们需要引入锁的概念。互斥锁（Mutex）保证同一时间只有一个线程能持有锁，从而独占临界区。

#include <iostream>
#include <thread>
#include <vector>
#include <string>
#include <cstdio>
#include <unistd.h>
#include <pthread.h>

int ticket = 100;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

void routine(std::string name) {
    while (true) {
        pthread_mutex_lock(&lock);
        if (ticket > 0) {
            usleep(1000);
            ticket--;
            printf("%s shell ticket, now tickets number: %d\n", name.c_str(), ticket);
            pthread_mutex_unlock(&lock);
        } else {
            pthread_mutex_unlock(&lock);
            break;
        }
    }
}

int main() {
    std::vector<std::thread> threads;
    for (int i = 0; i < 5; i++) {
        std::string name = "thread-";
        name += std::to_string(i);
        threads.emplace_back(routine, name);
    }
    for (auto& thread : threads) {
        thread.join();
    }
    return 0;
}

加上锁之后，无论怎么跑，票数都不会变成负数了。这里的核心是 pthread_mutex_lock 和 unlock。

临界区的概念

什么是临界区？就是访问共享资源的那段代码。核心规则是：同一时刻只允许一个线程进入。如果不保护，就会发生竞态条件。保护方式就是在进入前加锁，离开后解锁。

解锁的时机

注意上面的代码，无论是 if 分支还是 else 分支，我们都记得解锁。如果像下面这样写：

pthread_mutex_lock(&lock);
if (ticket > 0) {
    ticket--;
    // 忘记解锁
} else {
    break; // 直接退出，未解锁
}
pthread_mutex_unlock(&lock); // 永远执行不到这里

这就导致了死锁风险。如果一个线程持有锁的情况下直接退出（break/return），而未释放锁，其他需要该锁的线程将永远等待。死锁通常需要满足四个必要条件：互斥、占有并等待、不可剥夺、循环等待。

避免'拿着锁睡觉'

还有一个细节：usleep(1000) 应该放在锁外面。如果在锁内休眠，意味着其他线程即使不需要这个资源，也被迫等待这个线程睡醒。这是非常不合理的资源占用。

修正后的逻辑应该是：

pthread_mutex_lock(&lock);
if (ticket > 0) {
    ticket--;
    printf("...\n");
}
// 计算和 IO 操作尽量在锁外，或者确保锁粒度最小
pthread_mutex_unlock(&lock);

公平性问题

即便有了锁，互斥锁也不能保证公平性。你可能会发现某个线程（比如 thread-2）一直抢到票。这是因为谁先拿到 CPU 调度权，谁就有机会先获取锁。互斥锁只保证互斥，不保证顺序。

4. 总结

这篇文章从一张'神奇的负数车票'开始，带我们走进了多线程编程中最头疼的问题——竞态条件。当我们用五个线程同时去抢那 100 张票时，本该在票数为 0 时就停止的程序，竟然一路狂奔到了 -4。这背后的元凶就是经典的 Check-Then-Act race：线程 A 刚判断完票数大于 0，还没完成减减操作，就被线程 B 抢占了 CPU；等 A 回来继续执行时，手里的'旧情报'已经失效了，却还要对已经变了的票数再做一次减减。

为了解决这个问题，我们引入了互斥锁（Mutex）这个'交通警察'。它保证同一时间只有一个线程能进入临界区——也就是访问共享资源的那段代码。加锁和解锁的时机很有讲究：锁的范围要刚好覆盖对公共资源的操作，但不能太大（比如不能把 usleep 也包进去，否则就是'拿着锁睡觉'，白白浪费别人的时间）；同时每一个分支路径都要记得解锁，不然就会触发死锁，让其他线程永远等在那里。文章最后也提了一个有趣的现象：即便有了锁，线程 2 还是能把票抢光——这说明互斥锁只保证互斥，不保证公平，谁抢到 CPU 谁就有机会先拿到锁。

总的来说，线程互斥是多线程编程的必修课。理解临界区、掌握锁的粒度、警惕死锁的四个必要条件，这些基本功打扎实了，才能写出既高效又安全的多线程程序。毕竟，在这个并发为王的时代，让线程们'有序竞争'比'野蛮抢食'要靠谱得多。