线程同步这一块很多读者看完上一篇的互斥锁之后容易把“互斥”和“同步”混为一谈。互斥解决的是“同一份资源不能同时被多个线程写”但实际业务里大量场景是另一类问题一个线程必须等另一个线程把某件事做完才能继续往下走。比如下载线程把缓冲区写满了解析线程才能去读任务队列空了工作线程就得停下来等新任务。这类“按顺序协作”的问题光靠锁是锁不出来的需要条件变量、生产者消费者模型、线程池、读写锁这一整套工具。本文就围绕这几个点用代码和踩坑经验把线程同步的骨架讲透配合上一篇的互斥锁内容基本就能覆盖 Linux 多线程开发最常见的面试题和实战场景了。1. 从“抢锁”到“协作”先理清同步到底要解决什么问题1.1 互斥锁管不了“先后顺序”用互斥锁解决线程同步最直接的后果就是代码变成“轮询空转”。举个例子消费者要从共享队列里取数据队列为空时它该怎么办很多人第一版代码会写成这样while (1) { pthread_mutex_lock(lock); if (队列非空) { data pop(); pthread_mutex_unlock(lock); process(data); } else { pthread_mutex_unlock(lock); usleep(10 * 1000); // 睡 10ms 再试 } }这个方案的问题非常直观sleep 时间设长了数据已经来了消费者还在睡延迟被放大设短了CPU 被无意义的轮询白白烧掉。更麻烦的是这个延迟和 CPU 开销根本没法通过调参调到理想状态因为消费者和生产者之间没有一个“事件通知”机制它只能靠猜。互斥锁的本质是保护临界区它管的是“能不能同时进”它完全不管“什么时候该进来”这就是同步问题必须用专门工具解决的原因。1.2 同步的本质是“条件等待”把同步问题抽象一下你会发现几乎所有场景都是同一个模式一个线程在等某个条件成立另一个线程负责让条件成立并且要在条件成立的那一刻通知等待者。这个模式和餐厅取餐一模一样——你拿到号牌之后不需要每隔几秒去窗口问一次“好了没”你只需要坐在位置上等叫号员喊到你的号你再起身去取。条件变量就是 Linux 里的“叫号员”。它的核心思路是让等待的线程挂起进入睡眠状态把 CPU 让出来等条件满足时由另一个线程主动唤醒它。这个“挂起-唤醒”的机制比轮询省电省 CPU也比定时睡眠延迟更低这才是线程同步的正确打开方式。2. 条件变量给等待的线程装一个“叫号器”2.1 三个核心 API 和标准使用套路条件变量的 API 很少就三个常用函数pthread_cond_t cond PTHREAD_COND_INITIALIZER; pthread_cond_wait(cond, mutex); // 等待条件成立内部会释放 mutex pthread_cond_signal(cond); // 唤醒一个等待线程 pthread_cond_broadcast(cond); // 唤醒所有等待线程标准的使用套路是固定的先看消费者pthread_mutex_lock(mutex); while (条件不成立) { pthread_cond_wait(cond, mutex); } // 走到这里说明条件成立可以安全处理共享数据 pthread_mutex_unlock(mutex);再看生产者pthread_mutex_lock(mutex); // 修改共享数据让条件成立 pthread_cond_signal(cond); pthread_mutex_unlock(mutex);注意一个细节生产者的 signal 放在 unlock 之前还是之后其实都能用但性能上有细微差别。signal 之后当前线程还持有锁被唤醒的线程即使醒来也要去抢同一把锁抢不到就再睡回去白白多一次上下文切换。所以我个人习惯先在锁内改共享数据、signal再 unlock代码可读性也更好。这两种顺序在一些极端的压力测试下确实有差异但差异远小于“用错条件变量”带来的问题不用过分纠结。2.2 wait 为什么必须搭配互斥锁这是条件变量最容易被问倒的一个点。很多人不理解为什么pthread_cond_wait明明传了两个参数其中一个是 mutex答案藏在它的内部行为里。pthread_cond_wait在被调用时会做三件事先原子性地释放传入的 mutex然后把当前线程挂起等被唤醒之后再重新获取 mutex最后才返回。这个“释放锁”和“挂起线程”必须是不可分割的原子操作否则就会出两种典型的竞态。第一种竞态是持锁睡眠导致死锁。如果 wait 不释放 mutex消费者判断条件不成立后仍然握着锁去睡觉生产者想修改条件却抢不到锁条件永远不成立消费者就永远等不到唤醒——这是教科书级的死锁。第二种竞态是信号丢失。假设 wait 先释放锁、再挂起这两步之间有窗口消费者刚释放锁还没挂起生产者抢到锁修改了条件并调用了 signal但此时消费者还没进入睡眠状态signal 根本没被任何人收到等消费者真正挂起之后这次唤醒事件已经永远错过了。pthread_cond_wait的参数设计就是为了消除这两个窗口它保证“释放锁”和“挂起”同时完成也保证“被唤醒后重新抢锁”的流程是安全的。2.3 用 while 不用 if虚假唤醒和竞争条件变量的第二个高频坑是判断条件时用if而不是while。新手最容易写成if (条件不成立) { pthread_cond_wait(cond, mutex); }这个写法至少有两个致命问题。第一是虚假唤醒Linux 上基于 futex 的实现里wait 可能在没有收到 signal 的情况下提前返回这是内核调度层面的客观事实标准写法必须用循环重新检查条件。第二是多消费者竞争问题假设有两个消费者同时被广播唤醒其中一个抢到锁把队列里的数据取空了另一个抢到锁之后再继续处理时条件已经又不成立了用 if 就会直接进入错误的数据处理流程。所以正确的写法永远是while (条件不成立) wait()这个 while 承担了“醒来之后重新确认”的职责是一条保命代码。2.4 signal 和 broadcast 怎么选signal 唤醒一个线程broadcast 唤醒所有线程选择标准取决于唤醒后有多少线程能真正干活。如果资源只有一份用 signal如果资源变更对所有等待线程都有意义用 broadcast。我用 broadcast 踩过一次很深刻的坑多个消费者在同一个条件变量上等任务生产者每生成一个任务就用 broadcast结果每次生产一个任务所有消费者全部被唤醒只有抢到锁的那个能拿到任务其他消费者醒来后重新检查发现条件又没了只好再睡回去。功能上没出错但高并发时大量无效唤醒让 CPU 飙升改成 signal 之后症状立刻消失。记住一个原则叫醒不该干活的人就是浪费系统资源。如果等待方需要设超时pthread_cond_timedwait可以指定一个绝对时间的超时上限返回ETIMEDOUT表示超时这和 wait 一样也需要配合 while 循环处理。它常用于任务队列的“定时检查”场景比如后台线程每隔若干秒做一次心跳检测超时没等到任务就自己醒来干活。3. 阻塞队列生产者和消费者的“传话人”3.1 为什么需要两个条件变量生产者消费者模型是条件变量的经典应用。基于阻塞队列的实现里队列为空时消费者阻塞队列为满时生产者阻塞。这里必须配两个条件变量一个表示“非空”给消费者等一个表示“非满”给生产者等。很多人图省事只用一个条件变量结果就是生产者放完数据后唤醒的可能是另一个生产者它本来应该等“非满”却被叫醒后发现队列还是满的只好睡回去既无效又容易出错。两个条件变量各管一摊生产者只等 not_full消费者只等 not_empty唤醒目标明确逻辑也清晰。3.2 一个可直接参考的阻塞队列实现用数组加环形下标实现一个简单的阻塞队列核心代码就这些#include pthread.h #include stdlib.h typedef struct { int *buf; int cap; int head, tail, size; pthread_mutex_t lock; pthread_cond_t not_empty; pthread_cond_t not_full; } BlockQueue; void bq_push(BlockQueue *q, int val) { pthread_mutex_lock(q-lock); while (q-size q-cap) { pthread_cond_wait(q-not_full, q-lock); } q-buf[q-tail] val; q-tail (q-tail 1) % q-cap; q-size; pthread_cond_signal(q-not_empty); pthread_mutex_unlock(q-lock); } int bq_pop(BlockQueue *q) { pthread_mutex_lock(q-lock); while (q-size 0) { pthread_cond_wait(q-not_empty, q-lock); } int val q-buf[q-head]; q-head (q-head 1) % q-cap; q-size--; pthread_cond_signal(q-not_full); pthread_mutex_unlock(q-lock); return val; }这里面每个操作都要想清楚push 修改共享状态前必须拿锁size 到达 cap 时等待 not_fullpush 成功后 signal not_empty 告诉消费者有货了pop 的逻辑完全对称。这个队列天然支持多生产者多消费者因为锁保证了 tail、head、size 这些共享字段不会并发写坏。3.3 信号位置和队列容量的经验关于 signal 放在 unlock 前后我上面说过两种都能用但在阻塞队列这个场景里有一种优化变体很值得试先改状态、unlock、再 signal。这样被唤醒的消费者不会立刻和生产者抢同一把锁减少了锁竞争。代价是如果 signal 前刚好有另一个消费者抢到锁把队列取空这次 signal 会让一个消费者醒来发现队列又空了再睡回去但不会出错因为 while 循环兜底。容量设置上阻塞队列的容量不是越大越好。容量大意味着生产者能囤很多任务消费者积压处理内存占用高容量太小又会让生产者频繁阻塞。实际项目里一般按“任务平均大小 × 合理并发数”来推比如任务耗时差异大的场景容量可以稍微给大一点起到削峰填谷的作用。4. 环形队列更贴近底层缓冲的 cp 模型4.1 环形结构的好处环形队列和阻塞队列解决的是同一个问题但底层结构不同。数组式环形队列的内存是连续的一块CPU 缓存友好遍历和随机访问都比链表式队列快而且它不需要像链表那样每个节点都做一次 malloc/free避免了频繁的内存分配开销。在音视频帧缓冲、网络收发缓冲区这类对性能和吞吐有要求的场景里环形队列几乎是默认选择。它的核心代价是容量固定满了就不能再放但这正好符合生产者消费者模型的“背压”语义队列慢一点让上游等一下总比无限堆积把内存打爆要好。4.2 判空判满的三种方案环形队列实现里最容易出错的就是判空判满。三种常见方案对比如下方案判空条件判满条件代价记录 size 字段head tail 且 size 0size CAP多维护一个变量空一格不用head tail(tail 1) % CAP head容量实际少 1添加 full 标志位head tail 且 !fullhead tail 且 full逻辑稍复杂我个人最推荐第二种“空一格不用”。它不需要额外的 size 字段判空判满的条件非常对称写多线程版本时共享字段越少越不容易出错。唯一要注意的是容量会少一格定义 CAP 时把这一格算进去就行。4.3 一个带条件变量的环形队列实现结合条件变量环形队列的生产者消费者模型代码骨架如下#define CAP 8 typedef struct { int buf[CAP]; int head, tail; pthread_mutex_t lock; pthread_cond_t has_space; // 有空位 pthread_cond_t has_data; // 有数据 } RingQueue; void rq_push(RingQueue *q, int val) { pthread_mutex_lock(q-lock); while ((q-tail 1) % CAP q-head) { pthread_cond_wait(q-has_space, q-lock); } q-buf[q-tail] val; q-tail (q-tail 1) % CAP; pthread_cond_signal(q-has_data); pthread_mutex_unlock(q-lock); } int rq_pop(RingQueue *q) { pthread_mutex_lock(q-lock); while (q-head q-tail) { pthread_cond_wait(q-has_data, q-lock); } int val q-buf[q-head]; q-head (q-head 1) % CAP; pthread_cond_signal(q-has_space); pthread_mutex_unlock(q-lock); return val; }注意条件变量的命名我看到很多初学者的实现把“有空位”和“有数据”搞反等空位的人被“有数据”的变量叫醒逻辑全乱。写代码的时候想清楚push 只有在 has_space 上等pop 只有在 has_data 上等。4.4 单生产者单消费者能免锁的边界环形队列还有一个很值得知道的优化单生产者单消费者场景可以做到无锁。原因是生产者只操作 tail 和写 buf[tail]消费者只操作 head 和读 buf[head]两个下标不会同时被两个线程写只要用内存屏障保证写数据的顺序数据就能安全传递。很多流式处理框架的 SPSCSingle Producer Single Consumer队列就是基于这个原理做的。但多生产者多消费者就不行了多个生产者会并发更新 tail多个消费者会并发更新 head必须加锁。所以设计时先想清楚你的业务是不是单生产者单消费者能省一把锁就省一把锁。5. 线程池别让线程“打一枪换一个地方”5.1 线程创建销毁的开销有多大线程池的意义就在于线程的创建和销毁不是免费的。先看内核侧创建一个线程要分配内核栈和线程结构加入调度队列再看用户侧每个线程默认要分配 8MB 的虚拟地址空间作为栈pthread_create 在里面还要做一堆初始化。如果任务本身就几十微秒线程创建销毁的时间可能比任务执行时间还长。我做过一个简单压测只是连续创建并销毁一万个空线程耗时都在秒级这个开销放到高频任务场景里完全不可接受。线程池的做法是提前创建一组线程常驻任务来了直接往里丢让线程自己来取省掉重复创建销毁的成本。5.2 线程池核心结构与 worker 循环线程池最简模型就三块一个任务队列、一组工作线程、一套提交接口。任务队列用阻塞队列实现工作线程启动后死循环去队列里取任务执行。核心结构参考typedef struct { void (*func)(void *); void *arg; } Task; typedef struct { Task *tasks; // 任务队列环形数组 int cap, head, tail, size; pthread_mutex_t lock; pthread_cond_t cond; // 任务到达通知 pthread_t *threads; int thread_count; int shutdown; } ThreadPool; void *worker_loop(void *arg) { ThreadPool *pool (ThreadPool *)arg; while (1) { pthread_mutex_lock(pool-lock); while (pool-size 0 !pool-shutdown) { pthread_cond_wait(pool-cond, pool-lock); } if (pool-size 0 pool-shutdown) { pthread_mutex_unlock(pool-lock); break; } Task task pool-tasks[pool-head]; pool-head (pool-head 1) % pool-cap; pool-size--; pthread_mutex_unlock(pool-lock); task.func(task.arg); // 执行任务不持锁 } return NULL; }关键点在执行任务时一定要先把锁释放掉。如果拿着锁执行任务任务里任何阻塞操作都会让其他 worker 在队列前排队整个线程池退化成一个并发度 1 的串行执行器问题非常隐蔽压测时才暴露。5.3 线程池销毁不能直接 pthread_cancel线程池销毁是个特别容易翻车的地方。很多人第一反应是pthread_cancel直接打断线程但取消点不好控制线程可能正在持有锁、正在执行第三方库代码被取消的时机会导致锁没释放、资源没收干净甚至直接崩溃。正确做法是设置shutdown标志然后pthread_cond_broadcast唤醒所有 worker让它们在循环里检查到“shutdown 且任务队列为空”时自己退出。这样每个 worker 都能把手上的最后一个任务干完再走退出时机完全可控也不会出现资源泄漏。5.4 线程池大小怎么定线程池开多少个线程没有唯一答案但判断逻辑是清晰的。CPU 密集型任务线程数一般设为 CPU 核心数或核心数加一再多线程没有计算资源可分反而增加上下文切换开销。IO 密集型任务线程的大部分时间在等磁盘、网络或数据库这时可以把线程数调高到核心数的两倍甚至更高具体要看阻塞占比。最稳的办法是按真实业务做压测先从一个基准值开始观察 CPU 利用率和任务延迟再逐步调整。比线程数更重要的是永远不要因为线程池而阻塞业务调用方——大批量提交任务时如果提交线程也被阻塞在 enqueue 上很容易引发连锁等待。6. 读写锁读多写少场景的“共享读、互斥写”6.1 读写锁的基本语义读写锁的动作分两种读锁和写锁。多个线程可以同时持有读锁但 write 锁是独占的——拿到写锁时既不允许别的写线程进来也不允许读线程进来。这种语义和我们日常读缓存、读配置表的习惯完全一致大家一起读没问题写的时候必须独占避免读到写了一半的脏状态。适用场景非常明确读远多于写比如路由表、参数配置、字典数据这类数据读操作占九成以上用普通互斥锁会把读并行度全部浪费掉读写锁则能最大限度放开读并发。6.2 API 和代码示例Linux 的 pthread 读写锁 API 很简洁pthread_rwlock_t rwlock PTHREAD_RWLOCK_INITIALIZER; // 读者 pthread_rwlock_rdlock(rwlock); int v config.version; pthread_rwlock_unlock(rwlock); // 写者 pthread_rwlock_wrlock(rwlock); config.version; pthread_rwlock_unlock(rwlock);写者一定要用pthread_rwlock_wrlock不能图方便用 rdlock否则两个写操作之间就会互相覆盖。还有一个容易被忽略的坑读写锁默认不允许同一线程递归持有读锁如果你在一个已经持读锁的函数里又去 rdlock行为是未定义的轻则死锁重则直接出错。写代码时尽量避免在持锁路径里调用可能再次加锁的函数。6.3 写饥饿问题与选型建议读写锁最大的隐患是写饥饿。Linux 默认的读写锁倾向于读者优先持续有新的读请求进来时读锁可以反复被获取写者只能排在所有读线程后面干等。在高并发读场景下写线程可能长时间得不到调度表现就是配置更新迟迟不生效服务看起来像“僵住”。系统提供了pthread_rwlockattr_setkind_np可以设置写者优先或写者递归等策略但这是非标准扩展跨平台性不理想。我的实际建议是如果写操作频率不低比如超过 5%别迷信读写锁直接上互斥锁反而更稳。读写锁内部要维护读者计数和等待队列加锁解锁路径比互斥锁长写不频繁时收益才明显。选型前做一次简单的压测对比比拍脑袋靠谱得多。7. 线程安全不是玄学锁粒度与可重入7.1 线程安全的边界与锁粒度“线程安全”其实是个很具体的词不是说一个函数加了锁就叫安全关键看它保护的临界区是否覆盖了所有共享可变状态。典型的反例是strtok它内部用静态变量保存切分状态多个线程同时调用就会互相踩踏所以才有了带_r后缀的strtok_r把状态改成由调用者传入。这就是线程安全设计的思路共享可变状态要么锁起来要么干脆外置。锁粒度同样重要——锁的范围太大比如在锁内执行耗时的文件读写并发度直接塌方锁的范围太小状态保护不完整又会有竞态。经验是在正确性优先的前提下让临界区尽量只包含真正需要保护的共享状态读写。7.2 高频面试题速查表这部分内容太常考了我整理成一张表面试前可以快速过一遍问题核心要点mutex 和条件变量的本质区别mutex 管临界区互斥条件变量管条件等待与唤醒通知为什么 cond_wait 必须配合 mutex防止“释放锁”和“挂起”之间丢失唤醒也防止持锁睡眠死锁为什么等待条件用 while 而不是 if应对虚假唤醒以及多个等待线程竞争后条件可能再次不成立signal 和 broadcast 怎么选资源只能一个线程消费用 signal所有等待者都有意义用 broadcast读写锁适合什么场景读多写少写频繁时用互斥锁反而更好线程池为什么能提升性能避免线程反复创建销毁复用常驻线程执行任务8. 最后分享几个排查同步问题的实用技巧写多线程代码光靠看代码找 bug 太慢了我个人的习惯是直接用工具辅助验证。Valgrind 的 helgrind 模块能检测 pthread 相关的数据竞争和锁顺序问题ThreadSanitizer编译时加-fsanitizethread在运行时能报出很详细的数据竞争点。实测下来tsan 比 helgrind 更容易用在日常开发里因为编译一次就能反复跑。不过工具只能抓“已经发生的问题”抓不到设计层面的缺陷比如锁粒度过大、唤醒策略不当这些还得靠自己对同步模型的理解来把控。最后再提醒一句条件变量的 wait 条件、唤醒信号、锁保护这三样东西必须配套出现缺一个都会以最难查的方式在线上出问题。如果你把这篇文章里的代码都亲手敲一遍再配合工具跑几种多生产者多消费者场景线程同步这关基本就稳了。