1. 先把为什么需要线程同步讲透从一次线上数据错乱说起1.1 一个看起来人畜无害的计数器程序几年前我维护过一套 Linux 下的高并发服务多线程架构每个线程处理一批请求。其中一个模块做流量统计逻辑极其简单——每收到一个请求就把全局计数器加一。代码长这样long request_count 0; void *worker(void *arg) { for (;;) { process_request(); request_count; } return NULL; }四个线程同时跑。上线第二天运营反馈统计数字不对明明日志里记录了 100 万次请求计数器却只有 97 万。问题就出在request_count这行。你以为是原子操作实际上在 x86 上它被编译成三条指令从内存读值到寄存器、寄存器加一、写回内存。两个线程同时读到 100各自加一后写回结果还是 101 而不是 102。这种多线程共享数据却没有任何访问控制导致的随机错乱就是竞态条件race condition。新手最容易犯的错就是把代码只有一行等同于底层只有一个动作。看起来简单实际是典型的 read-modify-write 序列天然不具备原子性。这个案例几乎可以放在所有 Linux 并发编程教材的第一章因为它精确解释了线程同步到底在解决什么问题。1.2 竞态条件的本质原子操作与内存可见性竞态条件要成立需要两个前提同时出现多个线程访问同一块共享内存。其中至少一个线程在对这块内存做写操作。缺一个都不会出问题。这也是为什么很多面试官会追问只读的全局变量需要加锁吗不需要只要初始化和发布过程是安全有序的只读访问本身没有竞态。除了原子性还有一个容易被忽略的维度是内存可见性。现代 CPU 有 L1/L2/L3 多级缓存每个核在修改共享变量时先写进自己的缓存行再通过缓存一致性协议同步到其他核。这意味着线程 A 写了一个标志位线程 B 立刻去读完全有可能读到旧值。这一点常被误判为编译器或 CPU 坏了其实只是你在同步机制上偷了懒。Linux 下正确的做法要么用锁要么用 C11 的原子类型要么用__sync_synchronize()这样的内存屏障而不是指望过一会儿就能读到。1.3 线程同步到底在同步什么一句话线程同步是在临界区的入口和出口做纪律管理保证同一时刻最多只有一个线程进入同时保证进入临界区后看到的数据是新鲜的。临界区critical section指的就是操作共享资源的那段代码。同步机制四件套——互斥锁、条件变量、读写锁、信号量——本质都是对临界区的访问规则做约定。搞懂了这个本质你就不会在各种 API 之间迷失它们都是工具选哪个取决于你的并发场景而不是谁更高级。2. 互斥锁最基础的同步工具也是最容易死锁的地方2.1 pthread_mutex_t 的标准用法与细节Linux 下互斥锁的 API 属于 POSIX 线程库pthread使用流程固定初始化、加锁、解锁、销毁。#include pthread.h pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; void *worker(void *arg) { for (;;) { pthread_mutex_lock(lock); // 临界区访问共享资源 request_count; pthread_mutex_unlock(lock); // 临界区结束处理其他不共享的数据 } return NULL; }有三个细节值得单独说第一静态初始化PTHREAD_MUTEX_INITIALIZER和动态初始化pthread_mutex_init()二选一不要混用。静态初始化适用于全局锁动态初始化适合锁在结构体里或需要自定义属性比如改为递归锁的场景。第二pthread_mutex_lock在锁被占用时会阻塞线程这种阻塞是让出 CPU 的。换句话说线程被挂起不消耗 CPU 时间。这一点和自旋锁有本质区别后面会细说。第三解锁的线程不一定要和加锁的线程是同一个。POSIX 互斥锁默认类型PTHREAD_MUTEX_NORMAL允许这样只要你确定当前锁确实被你持有。但别搞这种花活谁能解锁就让谁加锁规则简单才不容易出 bug。2.2 死锁的三种经典姿势死锁是互斥锁用错后的经典事故特征是程序卡住、线程全部阻塞、CPU 占用率却可能很高因为存在忙等或反复重试。我归纳了三个最常见的场景场景一忘记解锁。函数里有多个return分支其中某个分支提前 return 了锁没有被释放。这种最隐蔽因为正常流程测不出问题。解决方法是做好代码审查或者用 RAII 风格封装——C 语言里虽然没有 RAII但可以用goto cleanup统一出口。场景二锁的嵌套顺序不一致。线程 A 持有锁 1 等待锁 2线程 B 持有锁 2 等待锁 1互相等下去。这是经典的 ABBA 死锁。解决办法是全局规定加锁顺序所有线程都先锁 1 再锁 2。// 线程 A pthread_mutex_lock(lock1); pthread_mutex_lock(lock2); // ... // 线程 B —— 错误示范先锁 2 再锁 1 pthread_mutex_lock(lock2); pthread_mutex_lock(lock1);场景三在持锁期间调用了可能阻塞的外部函数。比如持锁状态下调用read()等待网络数据对方迟迟不响应你的锁就变成了僵尸锁其他所有线程全部堵在你后面。关于死锁我有一个经验真遇到死锁排查时先不要盯着代码逻辑猜测直接用gdb attach上去thread apply all bt看每个线程的调用栈哪里卡住一目了然。后面有一个专门章节讲这个排查过程。2.3 实际业务中的锁粒度权衡很多人在学会加锁之后就放飞自我了——大锁套小锁整个处理流程全部塞进临界区。性能直接崩掉。锁粒度是并发编程的核心权衡。临界区太大会导致线程之间互相等待的时间变长并发效率退化太小则锁的获取和释放开销占比变高尤其是锁本身需要进入内核态时就亏了。我的经验法则是临界区内的操作不超过几十条指令时开销可以接受。不要在锁内做 IO、网络、sleep 这类耗时代码。能分离的共享资源就分离每把锁只保护自己的那份数据降低锁竞争概率。用pthread_mutex_trylock做非阻塞抢占时注意处理抢占失败后的逻辑不要直接空转。3. 条件变量从忙等到精确唤醒3.1 为什么轮询等待是不可取的互斥锁解决了互斥问题但很多场景需要的是等待某种条件成立后再继续。典型的是生产者-消费者模型消费者需要等队列里有数据才能取。最朴素的实现是轮询加锁while (queue_empty(q)) { pthread_mutex_unlock(lock); usleep(1000); pthread_mutex_lock(lock); }这种忙等轮询的问题是等待期间大量无效的 CPU 消耗而且usleep的粒度不好把握——睡太短浪费 CPU睡太长增加延迟。你是在用 CPU 时间和延迟换简单。条件变量condition variable的存在就是为了解决这个问题让线程挂起等待直到条件真正变为真时被唤醒。这是事件驱动的等待模型等待期间不占 CPU。3.2 pthread_cond_wait 的原子性设计与规范写法条件变量和互斥锁总是配对使用。关键 API 是pthread_cond_wait它的行为堪称教科书级设计——不是先解锁再等待而是在原子操作内部完成解锁 挂起 等待唤醒 重新加锁。#include pthread.h pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond PTHREAD_COND_INITIALIZER; Queue q; // 消费者 void *consumer(void *arg) { for (;;) { pthread_mutex_lock(lock); while (queue_empty(q)) { pthread_cond_wait(cond, lock); } Item item queue_pop(q); pthread_mutex_unlock(lock); process(item); } } // 生产者 void *producer(void *arg) { for (;;) { // 生产数据... pthread_mutex_lock(lock); queue_push(q, item); pthread_cond_signal(cond); pthread_mutex_unlock(lock); } }这个规范写法里有几个点是很重要的面试也常考为什么pthread_cond_wait要在持有锁的情况下调用因为它需要原子性地检查条件并进入等待。如果先解锁再等待中间可能被其他线程插入导致条件已经满足但你还没睡下去的窗口期信号就丢了。为什么等待要包在while里而不是if里因为存在虚假唤醒spurious wakeup。POSIX 标准允许信号在无人发送的情况下唤醒线程你必须有条件检查兜底。生产者为什么也要加锁因为queue_empty/queue_push操作队列本身也涉及共享数据条件变量的等待/唤醒操作只是同步机制不能替代对队列数据本身的互斥保护。3.3 虚假唤醒和惊群效应pthread_cond_broadcast会唤醒所有等待线程pthread_cond_signal至少唤醒一个。唤醒之后所有线程都会去抢锁但只有一个能抢到——这就是惊群效应thundering herd。真实项目里怎么处理分情况如果所有等待线程处理的任务完全同质比如线程池里的任务分发一个唤醒配上while条件检查就够了signal比broadcast更合适省掉无谓的抢锁开销。如果等待的线程做的是不同类型的条件判断用broadcast让所有线程自己检查一下代价是多几把锁的竞争但逻辑正确性更稳。另外很多人在写完条件变量后喜欢用共享变量做事件标志我用过一个比较稳的模式在pthread_cond_wait之外额外加一个bool标志位把条件成立这件事显式记下来防止信号丢失。这是个很朴素的防丢唤醒技巧。4. 读写锁、自旋锁、信号量按场景选型才算入门4.1 读写锁读多写少的现实选择在很多业务场景里读操作的频率远高于写操作。如果所有读写都用一个互斥锁保护读线程之间也会互相排斥——但读操作本来就没有数据竞争大量读线程完全可以并行。读写锁rwlock把锁分为读模式和写模式读模式可以多线程同时持有。写模式独占必须等待所有读锁释放。#include pthread.h pthread_rwlock_t rwlock PTHREAD_RWLOCK_INITIALIZER; // 读线程 pthread_rwlock_rdlock(rwlock); int value shared_config.version; pthread_rwlock_unlock(rwlock); // 写线程 pthread_rwlock_wrlock(rwlock); shared_config.version new_version; pthread_rwlock_unlock(rwlock);我实际用过的场景是配置热更新配置数据由后台线程定期从远端拉取业务线程高频读取。读写锁在这个场景下确实把业务线程之间的竞争从全互斥降到了几乎不互斥。要注意的是在 Linux 上pthread_rwlock_wrlock可能存在写者饥饿问题——如果读请求源源不断写者可能长时间拿不到锁。高负载下需要注意这一点。4.2 自旋锁短临界区的最后选择自旋锁spinlock的理念是临界区极短时与其让线程睡眠再唤醒不如让它在原地自旋、反复检测锁状态。线程调度切换的开销约几微秒如果一个临界区只需要几十纳秒睡眠唤醒的代价反而更高。#include pthread.h pthread_spinlock_t spin; pthread_spin_init(spin, PTHREAD_PROCESS_PRIVATE); pthread_spin_lock(spin); // 极短临界区 pthread_spin_unlock(spin);但自旋锁有两个致命问题持有锁的线程在自旋期间被系统抢占比如时间片耗尽那么其他所有等待线程都会跟着空转。单核 CPU 上自旋没有任何意义等待线程把 CPU 让出来才是上策。我的建议很直接用户态业务代码尽量不要用自旋锁它更适合内核态或极低并发、极短操作的场景。如果你的临界区超过几十条指令老老实实用互斥锁。4.3 信号量跨线程计数的灵活性信号量semaphore在 Linux 下的典型 API 是 POSIX 无名信号量sem_init/sem_wait/sem_post。它是互斥锁的推广——互斥锁是最多一个线程进入信号量是最多 N 个线程进入。#include semaphore.h sem_t slots; sem_init(slots, 0, 5); // 初始允许 5 个线程进入 sem_wait(slots); // 占用一个槽位没有则阻塞 // 有限共享资源区 sem_post(slots); // 释放一个槽位信号量适合做限流、资源池、生产者-消费者计数等场景。一个很实用的点是sem_t的值可以是任意整数所以它不只是计数器锁更是一种通用的条件通知机制。不过要小心和条件变量不同信号量本身不绑定任何数据锁数据共享依旧要自己保证互斥。4.4 选型对比表为了让大家快速对照我把 Linux 下几个同步原语的使用场景和特性列成一个表同步原语核心语义等待方式适合场景不适合场景互斥锁 mutex最多一个线程进入睡眠阻塞临界区较长、竞争不激烈临界区极短、高竞争读写锁 rwlock读共享、写独占睡眠阻塞读多写少写操作频繁自旋锁 spinlock最多一个线程进入CPU 自旋内核/极短临界区临界区长、单核条件变量 cond等待条件成立睡眠阻塞生产消费、任务唤醒简单的互斥保护信号量 sem最多 N 个线程进入睡眠阻塞资源池、限流需要精确互斥保护的场景选型时我的原则默认用互斥锁只有读多写少才考虑读写锁临界区极短且对延迟极度敏感才考虑自旋锁需要等待事件发生就用条件变量需要控制并发数量就用信号量。先满足正确性再谈性能。5. 一个真实项目的同步排错实录程序无缘无故卡死5.1 现象程序偶发卡死CPU 占用却居高不下有一回线上的数据处理服务出现诡异现象进程没有崩溃但业务日志突然不再输出请求全部超时。更奇怪的是top显示进程 CPU 占用率接近 100%这不像是普通死锁——普通死锁应该所有线程睡眠CPU 占用率很低。现象越是反常越说明不是简单的锁没释放大概率是锁已经被占用而某个线程正在忙等。5.2 排查过程三个命令锁定真凶我的排查链路是三步走第一步pstack看调用栈。Linux 下可以用gdb attach更快捷的手段是pstack pid它会打印进程内所有线程的当前调用栈。输出里看到三个工作线程全部都卡在同一个__lll_lock_wait之类的函数上——这是 pthread 互斥锁阻塞等待的典型栈帧。确认方向有锁被某个线程长期持有。第二步top -H -p pid看线程级 CPU。发现有一个线程 CPU 占用率极高基本上可以断定是它在持锁后的临界区里死循环或者长时间自旋。配合第一步的栈锁定这个线程。第三步gdb attach进去用thread apply all bt看完整调用栈。当时看到的情况是高 CPU 线程停在while (!queue_empty(q))的循环里q 永远不为空它一边持锁一边循环处理队列队列又被自己的处理逻辑不断推入新元素生生循环下去。根因挺讽刺的——不是没加锁导致的错乱而是加了锁但临界区逻辑错误本应该在处理完队列事项后break出来的循环没有正确退出条件同时本该在循环内释放锁再重新获取的地方被我写在了循环外。锁正确保护了数据却没有正确处理处理完成的判断。5.3 修复与反思修复并不复杂把循环条件和锁的获取释放调整正确加锁、取元素、解锁、处理再回到加锁。关键动作是取出即释放不要抱着锁去做后续处理。这次排查给我留下的几个经验现在写在这里分享进程卡死不一定是死锁先看 CPU 占用率再决定排查方向。低 CPU 大概率是锁等待或条件变量睡着高 CPU 大概率是忙等或死循环。pstack/thread apply all bt永远比瞪眼读代码高效调用栈直接告诉你哪一行卡住了。临界区里不要做需要反复确认的任务拿一次数据放一次锁是正路。写完同步代码后一定要想一遍如果条件永远不成立怎么办——超时、退出、异常分支都要有兜底。6. 面试和实操中绕不开的那些细节追问6.1 关于线程间通信的边界问题搜 Linux 线程同步的人很多同时在搜进程间通信IPC。这两者经常被混淆。简单区分线程同步处理的是同一进程内的线程之间共享数据访问IPC 处理的是进程之间的数据传递如管道、消息队列、共享内存、socket。如果你的全局变量只在同一进程内的多个线程间共享用 pthread 同步原语就够了不需要上 IPC。反过来如果多个进程共享一块共享内存进程内部的互斥锁是不起作用的——你需要的是进程间同步机制比如pthread_mutexattr_setpshared设置为PTHREAD_PROCESS_SHARED或者直接用文件锁。6.2 内存序和编译器优化带来的那些隐藏坑使用互斥锁和条件变量编译器会默认帮你处理内存乱序和缓存一致性问题——这是锁的语义保证。但如果你为了性能铤而走险不用锁而是用普通变量做标志位那你就要面对编译器优化和 CPU 乱序执行双重挑战。这里给一个硬性建议无论题目怎么变化只要共享数据涉及写操作就老老实实用同步原语。C11 标准下atomic_int、atomic_thread_fence可以处理更细粒度的内存序但那需要你对内存模型有很深的理解不建议在业务代码里频繁使用。6.3 性能实测一次简单的锁竞争基准我自己做过一个粗略的基准测试四个线程同时对同一个全局整数做累加分别使用无保护、原子操作、互斥锁三种方式各跑一千万次。结果虽然和硬件环境强相关但趋势非常典型方式相对耗时无保护1.0x结果错误__atomic_add_fetch约 3xpthread_mutex约 10x这个数据说明了什么锁的开销主要是两大部分内核态的 futex 调用加锁竞争时进入睡眠/唤醒路径和缓存行颠簸cache line bouncing。原子操作避免了内核态切换但依然有缓存一致性开销。所以优化方向也很明确减少锁竞争次数、缩小临界区、让不同线程尽量操作不同内存地址。6.4 Linux 环境下的调试工具清单最后整理一份我常用的线程同步调试工具供参考gdbthread apply all bt看全线程栈set scheduler-locking on单步调试时防止其他线程乱跑。pstack pid快照所有线程调用栈轻量快捷。top -H -p pid按线程查看 CPU 占用定位忙等线程。strace -f -p pid跟踪系统调用看线程卡在哪个 futex 上。valgrind --toolhelgrind检测 pthread 同步原语的误用比如锁顺序错误、遗漏解锁。tsanThreadSanitizer编译时加-fsanitizethread运行时检测数据竞争对隐藏的竞态条件非常有用。我的个人体会是写线程同步代码最忌感觉没问题。CPU 缓存一致性、编译器重排、调度器行为这些因素叠加起来很多 bug 只在特定负载下才会暴露。把同步原语的语义吃透、把锁粒度控制好、把调试工具用熟这三件事做到位Linux 并发这块基本就稳了。
