C++ 多线程进阶：互斥锁原理与实战

这里的公共资源是 ticket，五个线程去抢这个票数。我们用 usleep(1000) 来模拟抢票消耗的时间。按照常理，一旦没票了就应该停止。

但实际运行结果可能会显示票数变成了负数（例如 -4）。为什么会这样？

原因分析

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

观察代码逻辑：每个线程进入函数后都会读取 ticket 的值，随后休息一秒，再进行减减操作。

让我们放慢过程，详细看看当票数为 1 时的情况：

1. 线程 1 拿到 ticket 为 1，发现大于 0，执行 usleep(1000)。
2. 线程 2 启动，此时它可能也读取到 ticket 为 1（因为线程 1 还没写完），同样认为可以减减，也执行 usleep(1000)。
3. 线程 1 醒来，对 ticket 减减，变成 0。
4. 线程 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)
CALL usleep         ; 耗时操作
; ticket--
LOAD R2, [ticket]   ; R2 = 当前 ticket (注意这里重新读了一次内存)
SUB R2, 1           ; R2 = R2 - 1
STORE [ticket], R2  ; 写回 ticket
END_IF:

最关键的一点在于：判断时用的是 R1，真正减法时又重新 LOAD R2, [ticket] 读了一次内存。这意味着两个线程可能在判断阶段都拿到了旧值，导致重复扣减。

引入互斥锁

为了防止上述问题，我们引入锁的概念。先不深究原理，直接看效果。

#include <iostream>
#include <thread>
#include <vector>
#include <string>
#include <cstdio>
#include <unistd.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;
        }
    }
    return;
}

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;
}

这次运行结果正常，票数准确归零。这里的锁就是 互斥锁 (Mutex)。

• 特点：同一时间只有一个线程能持有锁。
• 用法：pthread_mutex_lock() 加锁，pthread_mutex_unlock() 解锁。

临界区概念

我们需要上锁是因为线程竞争导致公共资源混乱。访问共享资源（如全局变量、外部文件）的那部分代码段称为 临界区 (Critical Section)。

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

解锁的时机

注意上面的代码中，无论 if 还是 else 分支，我们都进行了解锁。有人可能会问：为什么不像下面这样统一放在最后解锁？

pthread_mutex_lock(&lock);
if (ticket > 0) {
    ticket--;
    printf(...);
    // pthread_mutex_unlock(&lock);
} else {
    // pthread_mutex_unlock(&lock);
    break;
}
pthread_mutex_unlock(&lock);

如果 break 发生在 unlock 之前，且该路径没有解锁，就会导致死锁。这是一种典型的死锁诱因：一个线程在持有锁的情况下直接退出（如 break、return 或异常），而未释放锁，导致其他需要该锁的线程永远等待。

死锁产生的四个必要条件（Coffman 条件）包括互斥、占有并等待、不可剥夺和循环等待。避免死锁的关键之一就是确保所有分支路径都能正确释放资源。

线程拿着锁睡觉

另一个潜在问题是 usleep 的位置。如果在持有锁期间让线程休眠，会阻塞其他所有线程，这是非常低效的。

所以综合下来，程序应该是这样的：

// ... 同上 ...
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);
            pthread_mutex_unlock(&lock);
        } else {
            pthread_mutex_unlock(&lock);
            break;
        }
    }
    return;
}

公平性问题

即便有了锁，也可能出现某个线程一直抢到票的情况。这并非互斥锁的 bug，而是调度器的行为。互斥锁保证的是互斥性，并不保证公平性。谁先抢到 CPU 和时间片，谁就有机会先获取锁。

总结

多线程环境下共享资源访问易引发竞态条件，导致数据异常如票数变负。通过引入互斥锁（Mutex）可确保临界区同一时刻仅一个线程访问。需正确掌握加锁解锁时机，避免死锁及'持锁休眠'浪费资源。互斥锁保证互斥性但不保证公平性，是并发编程的基础保障。