C++ 多线程进阶：互斥锁与竞态条件解析

运行结果可能会让你惊讶：票数竟然跑到了 -4。明明判断条件是 ticket > 0，为什么会出现负数？

为什么会这样？

单线程环境下不会出现这个问题，但在多线程中，竞争是常态。我们放慢过程，看看当票数为 1 时发生了什么：

1. 线程 1 读取 ticket 为 1，判断大于 0，进入休眠（usleep）。
2. 线程 2 启动，同样读取 ticket 为 1，也判断大于 0，进入休眠。
3. 线程 1 醒来，执行减法，ticket 变为 0。
4. 线程 2 醒来，它之前已经做过判断，于是继续执行减法，ticket 变为 -1。

这就是经典的 check-then-act race（检查后执行竞态）。从汇编层面看，判断和修改不是原子操作：

; if (ticket > 0)
LOAD R1, [ticket]   ; R1 = ticket
CMP R1, 0           ; 比较
JLE END_IF          ; 如果 <= 0，跳走
; usleep(1000)
CALL usleep         ; 时间片切换可能发生在这里
; ticket--
LOAD R2, [ticket]   ; 重新读内存
SUB R2, 1           ; 减法
STORE [ticket], R2  ; 写回
END_IF:

关键点在于：判断时用的是寄存器 R1，真正减法时又重新 LOAD R2 读了一次内存。如果中间被其他线程修改了内存，R2 拿到的就是旧情报，导致逻辑错误。

解决方案：互斥锁

为了防止这种乌龙事件，我们需要引入锁的概念。互斥锁（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 sell 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-" + std::to_string(i);
        threads.emplace_back(routine, name);
    }
    for (auto& thread : threads) {
        thread.join();
    }
    return 0;
}

加上锁之后，无论哪个线程先抢到 CPU，它都必须先拿到锁才能访问 ticket。其他线程会被阻塞在 pthread_mutex_lock 处，直到锁被释放。这样就能保证票数不会变成负数。

临界区的概念

为什么要上锁？因为存在临界区（Critical Section）。这是指代码中访问共享资源（如全局变量、外部文件等）的那一部分程序段。

• 核心规则：同一时刻，只允许一个线程进入临界区。
• 保护方式：进入前加锁，离开后解锁。
• 不保护的后果：发生'竞态条件'，导致数据毁坏。

解锁时机与死锁风险

注意上面的代码，无论是在 if 还是 else 分支，我们都调用了 unlock。有人可能会想，能不能把解锁统一放在最后？

// 错误的示范
pthread_mutex_lock(&lock);
if (ticket > 0) {
    ticket--;
    // 忘记解锁
} else {
    break;
}
pthread_mutex_unlock(&lock);

如果在 break 或 return 之前没有解锁，线程就持有了锁却退出了。这会导致其他需要该锁的线程永远等待，形成死锁。死锁产生的四个必要条件包括互斥、占有并等待、不可剥夺和循环等待，其中'持有锁退出'直接违反了资源释放原则。

锁的粒度：别拿着锁睡觉

再看上面的正确代码，我们在 pthread_mutex_lock 和 pthread_mutex_unlock 之间包含了 usleep(1000)。这在生产环境中是非常不合理的。

想象一下，线程 A 拿到了锁，然后去睡了一秒。这一秒内，其他所有想抢票的线程都被挡在门外，哪怕它们根本不需要访问 ticket。这叫锁粒度过大。

最佳实践是：只锁定对共享资源的读写操作，不要包含耗时操作（如 IO、睡眠）。

修正后的代码应该像这样：

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

互斥锁并不公平

加了锁就能保证公平吗？不一定。你可能会发现，某个特定的线程（比如 thread-2）一直在那卖票。这是因为互斥锁只保证互斥，不保证公平性。谁先抢到 CPU 调度，谁就有机会先拿到锁。如果线程 2 频繁获得 CPU 时间片，它就会反复获取锁并释放，其他线程只能干等。

总结

从一张'神奇的负数车票'开始，我们看到了多线程编程中最头疼的问题——竞态条件。当多个线程并发访问公共资源时，如果不加以保护，数据就会像脱缰的野马一样乱套。互斥锁（Mutex）充当了'交通警察'的角色，确保同一时间只有一个线程能进入临界区。

掌握互斥锁不仅仅是调用 API，更要注意细节：锁的范围要刚好覆盖对公共资源的操作，避免'拿着锁睡觉'浪费性能；每一个分支路径都要记得解锁，防止死锁；同时要明白锁不保证公平，谁抢到 CPU谁先执行。理解临界区、掌握锁的粒度、警惕死锁，这些基本功打扎实了，才能写出既高效又安全的多线程程序。