线程、互斥锁与原子操作：先从会出错的地方开始

我第一次写多线程程序时，导师只丢下一句话，加个互斥锁就好了。后来我花了一个星期才明白，这句话错得有多离谱。锁只是让两个线程不同时碰同一块内存，它没有告诉我为什么需要锁，也没有告诉我锁后面藏着什么。Ted Koomen 在《Threads, Mutexes, and Atomics》系列里想做的，就是把这个“后面藏着什么”讲清楚。这个系列从进程和线程开始，然后深入互斥锁、原子操作和内存排序，最后把想法落到实现上，用测量说话。第一句话他就把底牌亮了出来。添加线程本身并不一定让程序更快。他语气很硬，说的就是“本身并不”，没有留余地。来源：原文

从进程到线程：共享地址空间的双刃剑

先捋清基础。进程是运行中的程序实例，它有自己的虚拟地址空间和操作系统管理的资源，包括打开的文件、内存映射。线程是进程里的一条执行路径，每个线程有自己的执行状态，包括寄存器、栈和线程局部存储。同一个进程里的线程共享地址空间，所以它们能访问相同的堆对象和全局变量。来源：原文

共享地址空间既是吸引力，也是问题。把数据交给另一个线程，简单到递一个指针。但传递指针的同时，你还得保证对象保持存活，保证访问时机正确。这两个保证，编译器不会替你写。它们还是你的责任。作者用“own stack”提醒大家，线程自己的栈并不受保护，你把局部变量的指针传给别的线程，那个线程就能碰这块内存。来源：原文

作者还提醒了一个容易混淆的点。thread这个词也用在硬件上。OS线程是调度器能运行的单元，硬件线程是处理器暴露的执行上下文，常被称为逻辑CPU。在同时多线程（SMT）下，一个物理核心会暴露多个逻辑CPU。这两个概念经常被混在一起，但它们的作用层面完全不同。来源：原文

同步机制的三层理解：代码保证、OS行为与CPU细节

作者的目标是超越“放个互斥锁”和“原子操作更快”这种说法。这三个问题是相关的，但不能互换。代码保证什么、操作系统做什么、CPU上实际发生什么，是三个不同的层面。很多人把这三层混在一起想，结果出了问题只能瞎猜。来源：原文

系列示例用C++20，可以跑起来，也可以放进Compiler Explorer里看x86-64汇编。故意破坏的示例是编译期检查，不会运行。打印放在worker热路径之外，这样不会引入额外的共享I/O瓶颈。实现讨论聚焦Linux，但在x86和Arm架构上会提到一些相关细节。来源：原文

作者强调要从错误模式入手，而不是从API入手。这有点反直觉。大多数人学多线程是先学API，再学怎么用错。Koomen的意思是反过来，先看会坏成什么样，再学怎么修。这就像学开车之前先看事故统计，听起来吓人，但至少你知道要防什么。标题直接点题，Start with What Can Go Wrong，先从会出错的地方开始。来源：原文

反直觉发现：添加线程本身并不一定让程序更快

这是系列里最反直觉的声明。添加线程本身并不一定让程序更快。来源：原文 这挑战了常见的多线程加速假设。很多程序员默认认为，加线程就能加性能。但线程之间的同步开销、缓存争用、上下文切换，都可能让加线程变成减法。

作者没有绕开这个问题，而是直接把它摆在开头。这个系列要做的，就是弄清楚什么时候线程是助力，什么时候是阻力。我自己写过多线程代码，踩过不少坑，读到这句的时候有一种被戳穿的感觉。很多问题不能用“加锁”两个字解决，很多性能问题也不能用“加线程”解决。来源：原文

系列展望：从理解到实现与测量

这是系列的第一篇，从进程和线程的基础开始。接下来会探讨互斥锁、原子操作和内存排序，以及这些机制出错的几种方式。来源：原文

下一部分将把这些想法放进实际实现里，并测量它们。来源：原文 这才是关键。光理解不测量，永远是纸上谈兵。作者说“Adding threads does not, by itself, make a program faster”，这不仅是结论，也是一个可以验证的命题。测量不是附带的，测量是检验判断的唯一方式。

我读完这篇，最大的感受是，多线程编程的大部分坑，跟API关系不大，跟模型关系很大。你脑子里的共享内存模型，跟OS实际提供的模型和CPU硬件执行的模型，是三层东西。把这三层分清，比背十个锁的用法有用得多。Koomen把这个系列叫Critical Section，临界区，本身就是个提醒。你要处理的问题，往往在临界区的边界上，API文档帮不了你。来源：原文

原文：

Threads, Mutexes, and Atomics: Start with What Can Go Wrong · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月31日