1. 三个线程按序打印到底在考什么1.1 题目描述与表面难点这道题我先后在几个刷题平台和多轮面试复盘里见过算是多线程入门必刷的经典题目。题目描述很短有三个线程分别调用同一个对象上的三个方法每个方法内部会打印一个英文单词分别是 first、second、third。三个线程被同时启动操作系统层面的调度顺序完全随机有可能 second 先跑有可能 third 先跑甚至三个线程交错着推进。要求只有一个不管系统怎么调度最终输出必须永远是 first second third 这个顺序反复运行多少轮都不能乱。表面上看这好像是在考给线程排队怎么排。但真正动起手来你会发现 sleep、线程优先级这些常规手段全都不靠谱。sleep 是赌运气你睡 1 秒另一个线程可能 2 秒才轮到你睡 100 毫秒高并发下又可能不够。线程优先级也只是调度建议不是保证。要稳定做到second 必须发生在 first 完成之后third 必须发生在 second 完成之后唯一正确的思路是引入线程间的显式协作机制让后一个线程在没有收到前一个线程的完成信号之前直接挂起等待而不是抱着 CPU 空转。1.2 这道题背后真正的考法真正刷过一遍之后你会发现这道题考的并不是会不会写 Semaphore 的 API而是你对几种并发协作原语的理解边界互斥锁解决的是同一时刻不能同时进入临界区条件变量和信号量解决的是条件没准备好就别继续执行原子变量则介于两者之间能凑合但不见得优雅。把这些边界想清楚比多背几个函数签名有用得多。另一个隐藏考点是顺序依赖在工程上的普遍性。我举几个真实场景数据处理管线的多个阶段必须按序执行系统启动时网络模块必须在配置模块之后初始化又比如渲染循环必须等物理计算完成后再开始。这些场景和按序打印就像同一个骨架换了一层皮。所以这道题不是刷完就扔的玩具题它的抽象模式可以直接迁移到工作里。这篇文章既适合准备面试、想把这题吃透的人也适合刚入门的并发学习者想搞懂信号量到底是什么同样适合那些需要实现阶段依赖需求的开发者来找一个可以直接抄的方案。下面我从方案选型讲起把为什么最终落到信号量讲明白再给出三种主流语言的实现和踩坑记录。2. 方案选型为什么信号量最合适2.1 忙轮询 原子标志逻辑简单代价是吃 CPU不引入任何复杂原语最朴素的做法是用一个原子整数记录当前允许执行到第几步。比如用一个 state 字段值为 1 表示该 first 执行值为 2 表示该 second 执行值为 3 表示该 third 执行。每个线程启动后循环读取这个 state直到它变成自己对应的数字才继续往下走否则就在循环里转圈。这段逻辑确实能保证输出不乱但代价相当大。第一个问题是 CPU 空转所有还没轮到执行的线程都在自旋占据着完整的内核时间片反复执行原子读操作。第二问题是调度抖动一个自旋线程能不能及时看到另一个线程写入的 state取决于它多久能拿到一次时间片也取决于 CPU 缓存之间的同步延迟最坏情况下明明前一个阶段已经完成后面的线程还要空转很久才能反应过来。我并不是说原子变量方案一无是处。如果等待时间极短、对延迟不敏感或者你只是想快速验证算法思路它可以当原型。但作为这道题的正式答案忙轮询几乎总是被打回因为它在真实服务器上属于资源浪费大户。2.2 条件变量 状态标志通用但代码偏重条件变量是教科书标配。思路是用一把互斥锁保护一个状态变量second 线程发现状态不对就调用 wait 释放锁并挂起first 线程做完后修改状态然后调用 notify 唤醒 secondthird 同理。条件变量方案的优点是通用几乎能建模所有等待某个条件满足的场景。缺点是模板代码多而且有几个必须记牢的细节wait 之前必须持锁被唤醒后必须重新检查条件也就是要写成 while (!条件) { wait(); } 而不是 if否则碰上虚假唤醒会跑错最后还要记得调用 notify。这些细节都是真实项目里翻车的高发区。放到按序打印这道题上条件变量方案当然正确但你会发现大量代码都在做管理状态、加锁解锁、循环检查这些和业务无关的事。这就像在一个只需要装两颗螺丝的场合你搬来了一整套工具箱。2.3 信号量的闸门模型最贴合这道题的语义信号量就不一样了。从抽象层面看信号量维护一个计数器acquire 尝试把计数减一减不了就挂起等待release 把计数加一并唤醒一个等待者。你不需要维护额外的状态变量不需要 while 循环重新检查条件也不需要考虑虚假唤醒。我更愿意把信号量理解成一个通行令牌池。初始池子里有多少令牌就允许多少次通过。按序打印需要的是second 线程在没有收到 first 的完成信号之前必须被挡在门外。这正是把两个信号量的初始计数都设成 0让它们变成两道锁死的闸门first 打印完成后 release 一道闸门second 穿过闸门打印再 release 下一道闸门放行 third。这个模型和题意的对应关系是一一对应的代码量最少也不需要额外状态。所以最终选信号量不是因为它高级而是因为它恰好提供了等待并放行这个最贴合的抽象别的方案要么太粗糙要么太啰嗦。3. 照着写就行三种语言的完整实现与注意事项3.1 C20 的 counting_semaphore 标准写法C 标准库直到 C20 才加入了信号量头文件是 提供 std::counting_semaphore 和 std::binary_semaphore 两个模板类。前者允许计数最大值超过 1后者固定为 1。本题只需要有没有令牌两种状态所以 binary_semaphore 也能用但我个人更习惯用 counting_semaphore1少记一个类型语义上也更直观。#include semaphore #include functional class Foo { public: // 两个信号量初始计数均为0表示两道闸门一开始都处于锁住状态 Foo() : gate1(0), gate2(0) {} void first(std::functionvoid() printFirst) { printFirst(); // 打印 first gate1.release(); // 放行 second } void second(std::functionvoid() printSecond) { gate1.acquire(); // 等待 first 放行 printSecond(); // 打印 second gate2.release(); // 放行 third } void third(std::functionvoid() printThird) { gate2.acquire(); // 等待 second 放行 printThird(); // 打印 third } private: std::counting_semaphore1 gate1; std::counting_semaphore1 gate2; };有几个细节要叮嘱。首先编译时必须开启 C20 支持比如用 g -stdc20老版本编译器不认识 。如果你还在用 C11 或 C14就得降级用条件变量方案或者去包系统提供的信号量接口但接口风格就不统一了。其次counting_semaphore 的模板参数是最大计数上限。这里设成 1是因为每道闸门只需要一个令牌。把上限调高在这个场景里没有任何意义反而会引入混乱别手痒乱改。最后acquire() 是阻塞版本另外还有 try_acquire()、acquire_for()、acquire_until() 等变体。这道题用阻塞版就够了但调试时可以试试带超时的版本后面排查章节会说为什么。自测时用 std::thread 启动三个线程为了验证信号量真的管用可以故意把启动顺序打乱先启动 third再启动 first最后启动 second。不要忘记 join否则主线程退出了子线程可能被强制终止。3.2 Java Semaphore 的接口与中断陷阱Java 的 java.util.concurrent.Semaphore 从 Java 5 开始就是标准库的一部分API 稳定也是实际项目里最常见的实现。写法如下import java.util.concurrent.Semaphore; class Foo { private final Semaphore gate1 new Semaphore(0); private final Semaphore gate2 new Semaphore(0); public Foo() {} public void first(Runnable printFirst) throws InterruptedException { printFirst.run(); gate1.release(); } public void second(Runnable printSecond) throws InterruptedException { gate1.acquire(); printSecond.run(); gate2.release(); } public void third(Runnable printThird) throws InterruptedException { gate2.acquire(); printThird.run(); } }Java 版本最容易踩的坑是 acquire() 会抛出受检异常 InterruptedException。很多刷题平台要求你的方法签名不能带 throws这意味着你要在方法内部 try/catch。这里有个隐藏很深的问题如果 second 线程在 gate1.acquire() 上等待时收到中断它会抛出 InterruptedException但这个线程并没有消费令牌gate1 的计数仍然是 0。如果你在 catch 里只是打印日志然后 return那么 second 永远不会打印third 也永远等不到 gate2.release()整条链子就断了。正确做法是 catch 到 InterruptedException 之后调用 Thread.currentThread().interrupt() 恢复中断标志再根据业务决定是重试还是优雅退出。刷题场景里一般没人会中断你的线程但真实项目中这绝对是必须考虑的分支特别是把任务提交给线程池执行的时候。另外Java 的 Semaphore 构造时还有一个 fair 参数比如 new Semaphore(0, true)。本题用默认的非公平版就够了因为闸门一旦打开任意一个等待线程被唤醒都可以我们并不关心 second 和 third 谁先被唤醒反正 second 被唤醒后还要继续等 gate2顺序依然被保证。但如果你在做多个消费者抢一个令牌的业务就要认真考虑公平性参数了。3.3 Python threading.Semaphore 的实现与自测方法Python 的实现是三份里最短的import threading class Foo: def __init__(self): self.gate1 threading.Semaphore(0) self.gate2 threading.Semaphore(0) def first(self, printFirst): printFirst() self.gate1.release() def second(self, printSecond): self.gate1.acquire() printSecond() self.gate2.release() def third(self, printThird): self.gate2.acquire() printThird()Python 的 threading.Semaphore 属于标准库内部基于 Condition 实现acquire() 同样是阻塞操作。有一点要提醒Python 的多线程受 GIL 影响纯计算密集型任务并不能真正并行但这种靠阻塞来协调执行顺序的场景完全不碍事因为阻塞时线程会被挂起调度交给操作系统。我建议你自己写一个测试脚本故意乱序启动线程import threading def make_printer(text): def _print(): print(text) return _print def run_one_round(): foo Foo() threads [ threading.Thread(targetfoo.third, args(make_printer(third),)), threading.Thread(targetfoo.first, args(make_printer(first),)), threading.Thread(targetfoo.second, args(make_printer(second),)), ] # 故意乱序启动验证闸门是否真的锁得住 for t in threads: t.start() for t in threads: t.join()本地至少连续跑 1000 轮确认输出永远是 first second third这样比只看一次输出更有说服力。如果你想让测试更狠一点可以在每轮之间加随机睡眠或者一次性并发启动几十个线程。4. 常见问题与排查记录4.1 程序卡死不退出先查谁没过闸这道题在自测里出现频率最高的故障就是程序一直跑却没有任何输出或者输出了一部分就停住。原因几乎都是同一个某个 acquire 永远等不到对应的 release。常见的分支我整理成了表格现象根因处理方式first 正常打印second/third 没输出gate1 的 release 没执行比如 first 方法里 printFirst 抛了异常跳过了 release用 try/finally 保证 release 一定执行检查异常路径三个线程全部没输出信号量初始值被误设成非 0或者线程根本没被调度确认初始化确实为 0检查线程是否 join某一轮正常下一轮卡死复用了带状态的对象上一轮的令牌残留或丢失每轮测试都新建对象别复用同一个 Foo 实例Java 里个别线程被中断后链条中断InterruptedException 被吞掉或没有恢复中断标志catch 后恢复中断标志按业务重试或优雅结束特别是最后一种情况我在真实项目里见过不止一次一个线程池里的任务被取消恰好它阻塞在 acquire 上被中断后整个流程断掉后续任务全部卡死。排查这类问题要盯住所有 acquire 点的中断处理。4.2 输出顺序偶尔混乱多半不是信号量的锅如果你确认代码逻辑和上面一样但输出偶尔还是乱十有八九是 stdout 本身没有被保护。在这道题的评测环境里传入的三个打印函数通常被假设为单次调用就能输出完整字符串但你自己写 demo 时如果打印逻辑里有多次 write 操作两个线程的字符可能在系统层交错出现 sefirstcond 这种鬼东西。解决方案是给打印函数加上一把专门的输出锁或者保证一次调用输出完整字符串比如用 print(text, flushTrue) 并确保 logger 的 handler 是线程安全的。另一个可能的乱序原因你用的根本不是信号量而是 sleep 加状态标志的混合方案。这种方案在低负载下看着正常压测一上来就乱。遇到这种问题直接重构成信号量版本不要在拍脑袋方案上打补丁。4.3 信号量初始值设成 1 会怎样这个错误在我带过的同事里出现过写完 Semaphore(0) 之后翻文档看到计数为 0 时 acquire 会阻塞于是心里一慌改成 Semaphore(1)觉得1 总比 0 安全。结果 second 线程一启动就直接拿到令牌打印 second 抢在 first 前面和题意直接冲突。理解初始值的关键是初始值等于一开始就存在的令牌数。我们需要闸门一开始是锁死的所以是 0。若初始值是 1闸门一开始就是开的就失去了等待 first 完成的意义。这两个信号量都必须从 0 开始没有例外。4.4 实用调试技巧有界等待 随机压测开发过程中我强烈建议在调试版本里给 acquire 加超时避免程序因为一个 bug 而无限挂起。Python 里可以这么写if not self.gate1.acquire(timeout3): raise RuntimeError(等待 gate1 超时)Java 对应的是 tryAcquire(3, TimeUnit.SECONDS)C20 的 counting_semaphore 有 acquire_for 和 acquire_until。线上代码如果对延迟敏感也建议把无界等待改成有界等待至少让该醒的没醒这类故障能及时发现而不是让整个服务挂在那里。5. 从一道题到真实工程扩展与心得5.1 把闸门链推广到 N 个阶段按序打印是三个阶段的特例。真实业务里一段数据处理往往要经过多道工序读取、清洗、解析、落库每一道都不能提前。这个模式可以轻松扩展。我的做法是准备一个长度为 N-1 的信号量数组第 i 个闸门控制第 i1 个工序的放行class OrderedStage: def __init__(self, n): # 有 n 个步骤需要 n-1 道闸门 self.gates [threading.Semaphore(0) for _ in range(n - 1)] self.total n def run(self, index, action): if index 0: self.gates[index - 1].acquire() action() if index self.total - 1: self.gates[index].release()这样就把一道题里学到的闸门链抽象成了现成的编排器。实际接入流水线时把每个阶段丢一个工作线程进去就行。需要说明的是这解决的只是阶段之间严格按序推进如果你需要的是多个任务并发执行但最终结果按原始顺序返回那是另一个话题别混用。5.2 闸门与限流信号量两种用法别混淆信号量除了做这道题里单向放行的闸门更常见的用途是限流把初始值设置成允许并发进入的最大数量然后每个线程 acquire 进入临界资源release 离开。典型的场景是数据库连接池、下游接口的并发配额。闸门和限流是两种截然不同的用法。区别在于闸门的初始值是 0只放行一次或少量几次限流的初始值是 N可以被反复获取和释放。写代码前先想清楚是哪种能省很多调试时间。我曾经把一个限流信号量的初始值写成 0结果所有请求一进来全部排队超时排查了很久才发现是初始化时手滑。5.3 信号量还是条件变量我给个经验法则写到这里我给出一个选型建议。如果你只需要一个线程干完放行另一个线程选信号量它最直接、最不容易写错如果需要在等待过程中依赖复杂的共享状态比如队列长度大于 10 时才能消费选条件变量因为它和互斥锁配合可以安全地检查和修改多个变量如果你的语言环境没有好用的信号量实现或者团队对条件变量更熟用条件变量也完全没问题只要记住while 循环检查条件这条铁律。5.4 几条多线程调试的通用经验最后分享几条和语言无关的心得。第一反复验证确定性用随机启动顺序跑几百轮再把并发压力调大输出依然稳定才算过。第二无界等待是调试的天敌任何 acquire 和 wait 都尽量留超时出口线上故障时一张线程转储就能看出谁在等什么。第三优先使用现成的同步原语别自己拿原子变量造轮子内存序、缓存一致性和调度器交互这些细节已经有很多人替你踩过坑了。我个人在实际操作中的体会是这道题最大的价值不在于记住那份信号量代码而在于建立线程协作的心智模型谁在等待谁负责放行等待和放行之间必须一一对应。把这个模型刻进脑子里再看各种阶段依赖的并发问题基本都能一眼找到解法。