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

运行结果往往令人意外：票数竟然跑到了 -4。本该在 0 时停止的程序，却继续执行了减法操作。

问题根源分析

单线程环境下不会出现此问题，但在多线程中，竞争是常态。核心原因在于 Check-Then-Act Race（检查后执行竞争）。

当票数为 1 时，线程 A 读取到 ticket 为 1，判断大于 0，随后进入休眠。此时线程 B 启动，同样读取到 ticket 为 1，也认为可以扣减。线程 A 醒来后执行减法，票数变为 0；线程 B 醒来后再次执行减法，票数变为 -1。这是因为判断和修改不是原子操作，中间被其他线程插入了。

从汇编层面看，逻辑大致如下：

; if (ticket > 0)
LOAD R1, [ticket]   ; R1 = ticket
CMP R1, 0           ; 比较 R1 和 0
JLE END_IF          ; 如果 <= 0，跳走
usleep(1000)
; ticket--
LOAD R2, [ticket]   ; 重新读取内存
SUB R2, 1           ; R2 = R2 - 1
STORE [ticket], R2  ; 写回
END_IF:

关键点在于：判断时用的是寄存器 R1，真正减法时又重新 LOAD R2 读了一次内存。两次读取之间，内存值可能被其他线程修改。

解决方案：互斥锁

为了避免上述问题，我们需要引入互斥锁（Mutex）。它保证同一时间只有一个线程能持有锁，从而独占临界区。

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

// ... main 函数保持不变

加上锁之后，无论多少个线程同时尝试抢票，同一时刻只有一个线程能进入 if 或 else 分支，确保票数不会变成负数。

临界区与锁的使用

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

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

锁的释放与死锁风险

解锁的时机非常关键。如果在某个分支路径下忘记解锁，或者在持有锁的情况下直接退出（如 break 或 return），可能导致死锁。

例如，如果这样写：

pthread_mutex_lock(&lock);
if (ticket > 0) {
    ticket--;
} else {
    break; // 错误：未解锁直接退出
}
pthread_mutex_unlock(&lock);

一旦进入 else 分支，锁就永远无法释放，其他等待该锁的线程将永久阻塞。这就是典型的死锁诱因之一。

死锁产生的四个必要条件包括：互斥、占有并等待、不可剥夺、循环等待。虽然本例主要涉及死锁风险，但理解这些条件有助于排查更复杂的并发问题。

性能陷阱：锁住期间休眠

另一个常见误区是在持有锁的时候进行耗时操作，比如 usleep。这被称为'拿着锁睡觉'，会严重降低系统吞吐量，因为其他线程即使不需要访问当前资源，也被迫等待。

正确的做法是将耗时操作移出临界区，或者仅在访问共享数据时加锁：

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

互斥锁不保证公平

即便有了锁，也不能保证所有线程都能公平地获得执行机会。在某些调度策略下，某个线程可能反复抢到 CPU 并立即获取锁，导致其他线程长时间饥饿。互斥锁只保证互斥性，不保证公平性。

总结

多线程编程中，共享资源的并发访问常引发竞态条件，导致数据异常。核心原因在于检查与执行非原子性。引入互斥锁可确保临界区同一时刻仅一个线程访问，避免数据破坏。需注意锁的粒度，避免持有锁时休眠，且每个分支路径必须解锁以防死锁。此外，互斥锁保证互斥但不保证公平，线程调度仍依赖操作系统。掌握临界区保护与锁机制是编写安全并发程序的基础。