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

这里的公共资源是 ticket。按照常理，一旦没票了就应该停止。但运行结果往往会看到票数变成 -4 甚至更低。

为什么会这样？

如果是单线程，不会发生这种事。但在多线程环境下，竞争是常态。

让我们放慢过程，看看当票数为 1 时发生了什么：

1. 线程 1 读取 ticket 为 1，判断大于 0。
2. 线程 1 执行 usleep(1000) 休眠。
3. 线程 2 启动，读取 ticket 仍为 1，判断大于 0。
4. 线程 2 也休眠。
5. 线程 1 醒来，执行 ticket--，票数变为 0。
6. 线程 2 醒来，基于之前的判断继续执行 ticket--，票数变为 -1。

这就是典型的 Check-Then-Act Race。在汇编层面，这相当于：

; if (ticket > 0)
LOAD R1, [ticket]   ; R1 = ticket
CMP R1, 0           ; 比较 R1 和 0
JLE END_IF          ; 如果 <= 0，跳走
usleep(1000)
; ticket--
LOAD R2, [ticket]   ; R2 = 当前 ticket (此时已被其他线程修改)
SUB R2, 1           ; R2 = R2 - 1
STORE [ticket], R2  ; 写回 ticket
END_IF:

关键点在于：判断时用的是旧值，真正减法时又重新读了一次内存。

解决方案：引入互斥锁

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

加上锁之后，同一时间只有一个线程能持有锁进入临界区，从而保证了数据的原子性。

临界区的概念

什么是临界区？是指代码中访问共享资源（如全局变量、外部文件等）的那一部分程序段。

• 核心规则：同一时刻，只允许一个线程进入临界区。
• 保护方式：进入前加锁，离开后解锁。

锁的粒度与死锁风险

1. 不要抱着锁睡觉

上面的代码中，usleep(1000) 依然在锁内。虽然能解决数据安全问题，但这非常不合理。如果一个线程拿着锁去休眠，其他想抢票的线程只能干等，CPU 利用率会大幅下降。

更优的做法是将耗时操作移出临界区，或者只在读写共享变量时加锁。但在本例中，为了演示逻辑，我们暂时保留，实际工程中应尽量避免。

2. 所有分支都要解锁

有人可能会问，为什么不能在 if 里解锁，然后在函数末尾统一解锁？

// 错误示范
pthread_mutex_lock(&lock);
if (ticket > 0) {
    // ... 业务逻辑 ...
    pthread_mutex_unlock(&lock);
} else {
    break; // 直接退出，未解锁！
}
pthread_mutex_unlock(&lock); // 永远不会执行到这里

如果在 else 分支直接 break 或 return，而没有释放锁，就会导致死锁。后续所有需要该锁的线程将永远等待，因为锁被永久持有了。

死锁产生的四个必要条件（Coffman 条件）包括互斥、占有并等待、不可剥夺、循环等待。避免死锁的关键之一是确保每个加锁路径都有对应的解锁逻辑。

公平性问题

即使加了锁，互斥锁也不能保证公平性。你可能会发现一直是同一个线程在卖票。这是因为该线程先抢到 CPU，进而更容易再次抢到锁。互斥锁只保证互斥，不保证公平。

总结

多线程编程中，理解临界区和掌握锁的粒度至关重要。通过互斥锁，我们可以有效解决竞态条件，确保数据一致性。但要注意：

1. 锁的范围要刚好覆盖对公共资源的操作，避免过大影响性能。
2. 每一个分支路径都要记得解锁，防止死锁。
3. 互斥锁不保证公平，谁抢到 CPU 谁就有机会先拿到锁。

打好这些基本功，才能写出既高效又安全的多线程程序。