C++多线程与原子操作：并发编程第一步

可视化演示

展示线程生命周期状态转换、CAS原子操作循环及竞态条件与互斥锁保护对比。

线程创建：雇来两位帮厨

大厨老张决定雇两位帮厨。在C++的世界里，“雇人”不是填张表那么简单——你得用std::thread向操作系统正式下聘书：我要创建一条新的执行流。线程创建后，它和主线程并行跑，主线程不用等它也能继续干自己的活。

创建线程的语法简洁得出奇，一行代码就够：std::thread t(make_dish, "红烧肉")。这行代码执行后，系统立刻启动一个全新的执行路径，像店里多了一位手脚麻利的帮厨，马上开始按菜谱干活。

线程跑完之后怎么办？两个选择。t.join()是“原地等他回来交差”，主线程会阻塞，直到子线程结束。t.detach()则是“干完活不用报告，各回各家”。注意detach之后，主线程失去了与这个线程的关联句柄，再也无法等待它。

厨师终于上岗。但厨房只有一张案板、一个盐罐，麻烦也随之而来——他们开始抢盐罐了。

数据竞争：盐罐上的糊涂账

小明要往汤里加盐，小刚也要加。共享的盐罐上，标签写着“已加5次”。问题在于，“加盐”不是一个动作，而是三个：看一眼数字（读）、心算加一（改）、把新标签贴回去（写）。

多线程的世界里，这三个步骤之间随时可能被另一条线程插一脚。小明看到5，刚想写上6，小刚也凑过来，看到的还是5。小刚贴上6，小明也贴上6——两人各加了一次盐，标签却只多了1。这就是经典的“丢失更新”。

这种多个线程同时读写同一块内存、且至少一方在写的现象，就是数据竞争（data race）。在C++标准里，数据竞争属于未定义行为：程序可能崩溃、死循环，或者得出匪夷所思的结果。

盐罐要防抢，就得想个办法让“取、算、放”一气呵成——这正是原子操作要干的事。

原子操作：多功能盐罐

C++准备的特制盐罐叫std::atomic<T>。普通int变量没有防抢能力，但std::atomic<int>的每个操作，底层都映射成CPU提供的原子指令：要么不做，要么瞬间做完，中间不可能被插一脚。

最常用的是fetch_add：原子地完成“读-加-写”。count.fetch_add(1)就是count = count + 1的原子版，不会丢失更新。它还支持load()读取和store()写入——分别是安全的“看标签”和“贴标签”。

更强大的是CAS（compare_exchange）：只有当v等于expected时，才把v更新为desired，否则不更新并返回失败。它像“先核对标签是不是我记的数，是就改，不是就拉倒”，是构建无锁算法的基础。

原子操作守护了单个变量，但复杂的场景远不止保一个数——如果两件事必须同时完成，原子操作就不够用了。这时得动用厨房钥匙。

内存序：纸条的可见顺序

盐罐保住了，新问题浮出水面：纸条的可见性。厨师A明明把盐放好、写了张纸条贴在门口，厨师B却半天看不到。多核CPU里，每个核心有自己的缓存，写操作先落到缓存，什么时候刷进共享内存是另一回事。

内存序（memory_order）管的就是“这张纸条何时对其他核心可见”。宽松序（relaxed）只保证原子变量本身不撕裂，不保证顺序；获取-释放（acquire/release）保证：线程A在release写之前的所有操作，对随后acquire读到该变量的线程B全部可见；顺序一致（seq_cst）则给所有线程一个统一的“全局快照顺序”，最安全也最贵。

一个经典片段：线程A做x.store(1, release)，线程B做y.load(acquire)。B一旦看到x的值，就知道A在发布之前写的所有数据都准备好了——像极了“张老板贴出'已消毒'告示，客人看到告示就知道可以进店”。

内存序是把双刃剑：调对了性能飞升，调错了bug诡异。新手请从顺序一致起步，熟练后再考虑宽松优化。

互斥锁：厨房钥匙

有时候，我们要保护的是一段“复合动作”：比如先看账户余额再扣款，两步必须连着做完，不许别人插进来。原子操作管不了这么宽的场面，于是C++派出了互斥锁（mutex）——厨房钥匙。

规则很简单：进厨房前先lock()拿钥匙，干完活unlock()还钥匙，没拿到钥匙的线程只能在门口排队。被mutex保护的那段代码叫临界区（critical section），同一时刻只允许一个线程进入。

手动lock/unlock容易忘。std::lock_guard是智能钥匙扣，离开作用域自动归还；std::unique_lock更灵活，可以手动解锁，也是条件变量需要的搭档。死锁则像两个厨师各拿一把钥匙、都在等对方先进门——互相谦让造成的僵局。

互斥锁解决了“完整执行”，但它太重：一个厨师进厨房，其他人都得晾着。能不能让等待的人去睡一觉，被通知了再干活？条件变量登场。

条件变量：厨房铃铛

煲汤要等水烧开。厨师B不想空转锅铲，他想在旁边眯一会儿，水开了有人摇铃喊他。条件变量（condition_variable）就是那口铃铛。

使用模式：一个线程持锁后调用cv.wait(lk, pred)——它会原子地释放锁并进入睡眠。另一个线程在条件准备好后调用cv.notify_one()或cv.notify_all()，把沉睡者摇醒。醒来后线程重新拿锁，然后检查谓词是否成立。

虚假唤醒是著名的坑：线程可能没接到铃铛也自己醒了，或醒后发现条件其实没满足。所以wait的谓词必须用循环重新检查——这也是wait第二个参数存在的意义。C++标准明确允许虚假唤醒，所以必须while循环防御。

生产者-消费者模型就是靠铃铛完成的：生产者做好菜摇铃，消费者睡醒取菜。多线程协作的世界终于顺畅了。

常见陷阱：灶台上的坑

灶台上最滑的地板有几块：死锁、悬垂引用、volatile误区。死锁我们已经见过——两个线程互相持锁等待，像两位厨师各拿一把钥匙，互不相让。破解之道：所有线程按相同顺序给多个锁排队，或用std::lock同时锁多个。

悬垂引用往往藏在detach里。一个被分离的线程还在执行，但它引用的局部变量早已被主线程销毁，就像被解雇的帮厨还回去用已经回收的旧案板——未定义行为。永远不要detach一个引用了栈变量的线程。

volatile更是经典误区：它只告诉编译器“别优化我”，却不保证CPU缓存一致性和原子性，用它防并发等于刻舟求剑。

知道了坑的边界，就能画出安全地图。最后看看真正的高手怎么用多线程。

并发实践：多核厨房的功力

多线程的最终目标是榨干多核CPU。但线程是昂贵的资源，每创建一个线程，操作系统都要分配独立的栈空间。一百个厨师挤在一个厨房里，除了比手肘长，效率反而更差。

线程池就是“固定雇佣量”的方案：一次性创建N个线程，它们常态待命，任务来了按需分配，避免了反复“雇人/解雇”的开销。无锁编程则是用原子操作+CAS实现高并发数据结构，在极热点数据上免去锁竞争。

衡量并发收益的金标准是Amdahl定律：假设程序可并行部分比例为p，有n个核，理想加速比是1 / ((1-p) + p/n)。哪怕核数无穷大，加速比上限也只有1 / (1-p)。再精巧的多线程设计，也胜不过串行瓶颈。

故事来到尾声：小明和小刚用原子操作管好盐罐，用互斥锁守住厨房门，用条件变量协调上菜顺序……一桌年夜饭在井然有序的并发中准时出锅。你，也迈出了并发编程的第一步。

AI 应用场景

Python 演示

import threadingimport time  class BankAccount:    def __init__(self, balance=2000):        self.balance = balance        self._lock = threading.Lock()     def withdraw(self, amount):        tmp = self.balance        time.sleep(0.0005)        tmp -= amount        self.balance = tmp     def safe_withdraw(self, amount):        with self._lock:            tmp = self.balance            time.sleep(0.0005)            tmp -= amount            self.balance = tmp  def run_unsafe(num_workers):    acc = BankAccount(2000)    threads = [threading.Thread(target=acc.withdraw, args=(50,))               for _ in range(num_workers)]    for t in threads:        t.start()    for t in threads:        t.join()    return acc.balance  def run_safe(num_workers):    acc = BankAccount(2000)    threads = [threading.Thread(target=acc.safe_withdraw, args=(50,))               for _ in range(num_workers)]    for t in threads:        t.start()    for t in threads:        t.join()    return acc.balance  if __name__ == "__main__":    n = 10    expect = 2000 - n * 50    got = run_unsafe(n)    print(f"无锁: 期望余额 {expect}, 实际 {got}")    got_safe = run_safe(n)    print(f"有锁: 期望余额 {expect}, 实际 {got_safe}")

1. tmp = self.balance先把余额读到本地，模拟C++里count从共享内存读进寄存器。
2. time.sleep(0.0005)人为放大时间窗，让线程在此刻被切换，制造竞争。
3. self.balance = tmp写回共享变量，如果多个线程同时写，就会互相覆盖。
4. with self._lock:拿到互斥锁进入临界区，等价于C++的lock_guard。
5. threading.Thread(target=acc.withdraw, args=(50,))像std::thread一样创建线程，指明执行函数和参数。
6. t.start()启动线程。
7. t.join()主线程等待所有子线程结束。
8. balance_no_lock = run_unsafe(n)对比无锁与有锁的最终余额差异。

常见误区

面试题