简介面向重庆大学软件学院操作系统课程实验三的线程同步实现资料适合正在学习并发编程与Linux多线程开发的学生。资源聚焦互斥锁、信号量、条件变量、读写锁、死锁避免等核心同步机制并给出哲学家就餐问题等经典场景的代码参考可帮助读者理解竞态条件与临界区保护提升实验完成效率。压缩包约1.49MB共294个文件以C语言源码和头文件为主辅以makefile构建脚本、txt说明、汇编文件.s以及docx实验文档等能支撑从源码阅读、编译运行到实验报告撰写的完整流程。截至目前已有574人学习适合需要快速理清线程同步实验思路的同学参考。通过阅读和运行这些代码既能看到互斥锁、信号量、条件变量的典型用法也可以观察读写锁与死锁避免的设计差异从而在实际项目中合理选用同步机制为后续操作系统进阶实验打下基础。1. 线程同步实验为什么你的多线程程序跑起来像抽签某高校软件学院的操作系统实验三通常都是同一个套路给你一个多线程框架让你用信号量或条件变量把一个并发程序改成“正确”的样子。许多同学把 pthread_mutex_lock 和 pthread_mutex_unlock 往代码里一塞跑了几遍测试都通过以为完事大吉结果换一个调度顺序就翻车——输出错乱、死锁、甚至直接段错误。这个实验真正要考察的不是你会调用几个 API而是你是否理解临界区、竞态条件、忙等待和阻塞唤醒之间的根本区别。本文先把线程同步的几个原语和适用场景讲清楚再给出生产者消费者、读者写者两个经典实验题的可复现代码然后单独用一章讲我在调试中遇到的高频坑。全文核心是 POSIX 线程接口这是 Linux 下 C 语言实验的事实标准。你不需要读任何源码包跟着本文的命令和代码走就能在本地把实验跑通并且能解释清楚每一步为什么这么写。2. 同步原语选型mutex、信号量、条件变量到底该用哪个2.1 三个原语的本质区别锁、计数器、通知机制很多教材把 mutex、信号量、条件变量放在一章里讲但它们的定位完全不同。互斥锁的核心语义是“我进去了你不许进”它只有 0 和 1 两个状态做的事情是保护临界区。信号量的核心是“还剩多少个资源”它的值是计数器可以大于 1既能做互斥也能做资源计数。条件变量的核心是“状态变了我来通知”它本身不保护任何数据必须搭配一把互斥锁使用。从实现层面看mutex 的 lock 和 unlock 是成对出现的谁 lock 谁 unlock同一个线程不能连续 lock 两次否则就是死锁除非用递归锁。信号量的 wait 和 signal 不需要成对任意线程都可以 signal 一个自己不持有的信号量这使得它天生适合做“生产者唤醒消费者”这类跨线程通知。条件变量的 wait 调用会把锁释放掉并挂起线程被 signal 唤醒后自动重新拿锁这个“释放锁挂起重新拿锁”的原子操作正是它不可被信号量替代的关键。选型的经验法则如果你只需要保护一个共享变量的读写就用 mutex如果需求是“最多有 N 个线程同时访问某资源”用计数信号量最自然如果线程在等待某个条件成立比如队列非空、缓冲区有位置用条件变量 mutex。实验里最常见的错误就是把信号量当成万能药比如用信号量去保护一个本就该用 mutex 的临界区代码也能跑但语义是错的——信号量的值会泄漏最终导致同步逻辑漂移。2.2 POSIX 线程同步 API 对照参数与返回值Linux 下的线程同步实验绕不开 pthread 系列接口。互斥锁用 pthread_mutex_t 声明初始化可以静态用 PTHREAD_MUTEX_INITIALIZER也可以动态用 pthread_mutex_init。信号量不在 pthread 库而在 POSIX 信号量接口里头文件是 semaphore.h类型是 sem_t。条件变量是 pthread_cond_t必须配合 pthread_mutex_t 使用。我一般建议实验里全部用动态初始化即调用 init 函数并在程序结束前调用 destroy 回收。原因很简单静态初始化的变量没法处理初始化失败的情况而且排查问题时你不知道它是被谁初始化的。下面是三个接口族的参数要点表接口族类型关键函数返回值约定典型错误互斥锁pthread_mutex_tpthread_mutex_init / lock / unlock成功返回 0失败返回错误码忘记解锁导致死锁信号量sem_tsem_init / sem_wait / sem_post成功返回 0失败返回 -1 并置 errnosem_wait 返回后未检查 EINTR条件变量pthread_cond_tpthread_cond_init / wait / signal / broadcast成功返回 0失败返回错误码wait 前没加锁导致未定义行为一个特别容易被忽视的细节pthread_mutex_lock 返回的错误码中EOWNERDEAD 表示上一个持有锁的线程已死这在实验里几乎遇不到但如果你用 trylock 做非阻塞获取一定要处理 EBUSY 而不是直接认为锁没拿到。信号量的 sem_wait 如果被信号打断会返回 -1errno 是 EINTR严谨的做法是用循环重试。条件变量的 wait 更是必须在循环里调用我在第 5 章会专门讲原因。2.3 实验给的框架代码先别动先画图再写码我见过太多人拿到实验框架后直接往临界区插锁连共享变量有几个、哪些线程在读写都没数。正确动作是先画一张数据流图把所有线程写下来标出它们访问的每个全局变量然后圈出“至少两个线程同时访问且至少一个是写”的变量集合这些就是临界区候选。一个常见的判断麻烦是某个变量只在临界区内被访问但临界区加锁的方式错了加锁粒度太粗或太细。太粗就是整个程序串行化多线程毫无意义太细就是漏保护隐藏着数据竞争。画完图之后再决定每个临界区用什么原语。比如共享一个无界队列队列本身的操作是互斥的用 mutex 保护消费者的等待条件“队列非空”用条件变量表达如果要限制缓冲区容量上限额外加一个计数信号量。反过来如果直接用两个信号量一个空位数、一个满位数也能解决经典的生产者消费者就是这么写的。实验三通常不会限制你用什么原语所以选一个你能解释清楚的最简方案即可不要炫技。3. 生产者消费者模型一份能在本地跑通的最小实现3.1 循环缓冲区的设计与线程参数传递生产者消费者是实验三最核心的题目几乎每家高校都会考。它的本质是让两类线程通过一个有界缓冲区协作生产者往缓冲区放数据消费者从缓冲区取数据要求不丢数据、不重复取、不忙等待。标准的解法是用循环数组维护一个 FIFO 队列配合 mutex 保护队首队尾指针再用两个条件变量分别表示“缓冲区不满”和“缓冲区非空”。先定义共享数据结构。缓冲区大小取 8用 int 数组存储也可以取结构体数组以便后续扩展。队头队尾都维护索引count 记录当前元素个数这样判断满和空只需比较 count 和容量。代码里把结构体命名为 shared_buffer方便线程函数通过参数拿到同一个实例。#include pthread.h #include stdio.h #include stdlib.h #include unistd.h #define BUFFER_SIZE 8 typedef struct { int data[BUFFER_SIZE]; int head; // 队头索引消费者从此处取 int tail; // 队尾索引生产者从此处放 int count; // 当前元素个数 pthread_mutex_t mutex; pthread_cond_t not_full; // 生产者等待缓冲区不满 pthread_cond_t not_empty; // 消费者等待缓冲区非空 } shared_buffer; void buffer_init(shared_buffer *buf) { buf-head 0; buf-tail 0; buf-count 0; pthread_mutex_init(buf-mutex, NULL); pthread_cond_init(buf-not_full, NULL); pthread_cond_init(buf-not_empty, NULL); }这里的 head 和 tail 都指向真实索引而不是“下一个位置”逻辑上更直观。入队时先写 data[tail] 再更新 tail (tail 1) % BUFFER_SIZE出队时先读 data[head] 再更新 head。count 字段是冗余的因为 head 和 tail 相等时可能是满也可能是空必须靠 count 区分。调试时打印 head、tail、count 三个值一眼就能看出状态是否异常。线程函数入参是 void*不能直接把整数当指针传。常见做法是 malloc 一个结构体里面放线程编号和生产/消费的总数量线程结束后在 main 里统一 free。另一种做法是把线程编号直接强转为 void*比如 (void*)(long)i在 64 位系统上这样可以但可读性差。我推荐前者代码长一点但不会出现地址转换的潜在问题。3.2 生产者与消费者线程函数条件变量版完整实现生产者的逻辑是先加锁然后检查缓冲区是否已满。如果满了就用 pthread_cond_wait 进入等待状态此时锁会被自动释放。等被消费者唤醒后重新持有锁再次检查是否满了这个循环检查在 5.1 节会讲为什么必要。确认有空位后写入数据更新 tail 和 count然后唤醒一个正在等待的消费者。最后解锁。void *producer(void *arg) { int i; int item 0; shared_buffer *buf (shared_buffer *)arg; for (i 0; i 20; i) { item rand() % 1000; // 生产一个随机数 pthread_mutex_lock(buf-mutex); while (buf-count BUFFER_SIZE) { // 缓冲区满等待消费者取走数据 pthread_cond_wait(buf-not_full, buf-mutex); } // 写入缓冲区 buf-data[buf-tail] item; buf-tail (buf-tail 1) % BUFFER_SIZE; buf-count; printf([生产者] 放入 %d缓冲区剩余 %d 个\n, item, buf-count); // 唤醒一个可能等待中的消费者 pthread_cond_signal(buf-not_empty); pthread_mutex_unlock(buf-mutex); usleep(rand() % 10000); // 模拟生产耗时 } return NULL; }重点解释三个地方第一while 循环而不是 if 判断这是条件变量使用的铁律。当生产者被唤醒时可能有另一个生产者抢先拿到了锁并填满了缓冲区你必须重新检查条件。第二pthread_cond_signal 放在 unlock 之前和之后都合法但放之前可以减少一次线程切换因为刚 signal 完的线程会尝试抢锁而此时锁还在当前线程手里。第三printf 放在临界区内部是为了让输出和缓冲区状态保持一致性实验里为了调试方便可以这么做生产代码会把这些日志去掉。消费者线程是对称的检查缓冲区是否为空为空就等待 not_empty 通知取走数据后更新 head 和 countsignal 一下 not_full让可能阻塞的生产者知道有空位了。void *consumer(void *arg) { int item; shared_buffer *buf (shared_buffer *)arg; for (;;) { pthread_mutex_lock(buf-mutex); while (buf-count 0) { // 缓冲区空等待生产者放入数据 pthread_cond_wait(buf-not_empty, buf-mutex); } item buf-data[buf-head]; buf-head (buf-head 1) % BUFFER_SIZE; buf-count--; printf([消费者] 取出 %d缓冲区剩余 %d 个\n, item, buf-count); pthread_cond_signal(buf-not_full); pthread_mutex_unlock(buf-mutex); usleep(rand() % 10000); } return NULL; }消费者用了 for(;;) 死循环因为没有结束条件。实验里通常会让生产者在生产完指定数量后设置一个共享的 done 标志消费者看到 done 且缓冲区为空时才退出。更规范的做法是生产者所有线程结束后main 里调用 pthread_cond_broadcast 唤醒所有消费者消费者检查 count 0 done 就 break。这里为了演示最小模型保持消费者一直运行测试完成后用 CtrlC 终止进程。3.3 main 函数与编译运行注意线程创建的数量分配main 里需要初始化缓冲区、创建线程、等待线程结束join。线程数量分配取决于实验要求常见组合是 2 个生产者 2 个消费者。创建线程时把 shared_buffer 实例的地址作为参数传给每个线程注意所有线程共享同一个缓冲区实例所以 buffer_init 只调用一次。int main(void) { pthread_t prod_threads[2], cons_threads[2]; shared_buffer buf; int i; srand((unsigned)time(NULL)); buffer_init(buf); for (i 0; i 2; i) { pthread_create(prod_threads[i], NULL, producer, (void *)buf); pthread_create(cons_threads[i], NULL, consumer, (void *)buf); } for (i 0; i 2; i) { pthread_join(prod_threads[i], NULL); } // 生产线程结束消费者仍在阻塞等待这里简单 sleep 后返回 sleep(1); printf(测试结束缓冲区最终剩余 %d 个元素\n, buf.count); pthread_mutex_destroy(buf.mutex); pthread_cond_destroy(buf.not_full); pthread_cond_destroy(buf.not_empty); return 0; }编译命令是 gcc -o producer_consumer producer_consumer.c -lpthread。这里必须加 -lpthread 链接线程库不加会报未定义引用错误。如果你的环境是较新版本的 glibc可能不再需要显式 -lpthread但写上不会错。运行后输出应该能看到生产者和消费者的日志交替出现最终的 count 值接近或等于 0 或 8具体取决于退出时序。如果把生产者和消费者的数量调成 4 和 1或者 1 和 4观察输出。你会发现当消费者远少于生产者时缓冲区经常处于满状态输出里“剩余 8 个”频繁出现反过来则是“剩余 0 个”频繁出现。这说明你的同步逻辑在极端负载下保持了正确的状态不是数据错乱或卡死。4. 读者写者问题优先级策略与信号量实现4.1 读者优先与写者优先公平性决策读者写者问题是实验三的另一个经典变形相比生产者消费者它的难点在于同一类线程之间不互斥不同类线程之间必须互斥。也就是说多个读者可以同时读共享数据但写者和读者、写者和写者之间必须互斥。这道题在操作系统中通常有两种要求读者优先读者来了就能进写者可能饿死和写者优先写者来了之后新读者不许进写者先执行。某高校的实验通常两种都要求实现但核心代码差异只有一处读者优先只需要一个读者计数器和一把读写互斥锁写者优先需要额外的“写者等待队列”信号量和读者排队机制。我给出的建议是先实现读者优先跑通后再改造成写者优先这样你能直观地感受到优先级策略改变的只是入口处的排队逻辑核心的临界区保护没有变化。先明确术语readercount 是当前正在读的读者数量它本身是一个共享变量被多个读者线程同时修改所以必须用一把小锁保护——不要觉得读者之间不互斥就不需要锁readercount 的 操作不是原子的。真正禁止写者进入的操作是 rw_mutex 这把锁第一个读者进入时加锁最后一个读者离开时解锁中间若干个读者只修改 readercount 而不碰 rw_mutex。4.2 读者优先的完整代码读者计数器的边界操作下面的代码实现了读者优先。维护两个全局变量readercount 和两个锁。read_mutex 保护 readercountrw_mutex 保护共享数据的读写。读者进入的第一个动作是 lock read_mutexreadercount如果发现自己是第一个读者就 lock rw_mutex然后解锁 read_mutex。这样后续读者看到 readercount 0 就直接进入不需要等待 rw_mutex。#include pthread.h #include stdio.h #include unistd.h #include semaphore.h #define READER_NUM 3 #define WRITER_NUM 2 int shared_data 0; int readercount 0; pthread_mutex_t read_mutex PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t rw_mutex PTHREAD_MUTEX_INITIALIZER; void *reader(void *arg) { int id *(int *)arg; for (int i 0; i 5; i) { pthread_mutex_lock(read_mutex); readercount; if (readercount 1) { // 第一个读者需要拦住写者 pthread_mutex_lock(rw_mutex); } pthread_mutex_unlock(read_mutex); printf([读者 %d] 读取 shared_data %d当前读者数 %d\n, id, shared_data, readercount); usleep(rand() % 5000); pthread_mutex_lock(read_mutex); readercount--; if (readercount 0) { // 最后一个读者释放写者 pthread_mutex_unlock(rw_mutex); } pthread_mutex_unlock(read_mutex); usleep(rand() % 10000); } return NULL; }这段代码最容易出错的地方在“第一个读者加锁 rw_mutex”和“最后一个读者解锁 rw_mutex”这两个条件判断。如果你把条件写反比如判断 readercount 0 时加锁那么第二个读者进来时发现没有加锁就会直接进入多个读者可以同时读没问题但第一个写者也会同时进入数据竞争就出现了。调试时在 printf 里加一个状态字段当前共享数据是否被写者占用就能立刻发现问题。写者线程就简单多了直接 lock rw_mutex写数据unlock。因为写者之间天然通过 rw_mutex 互斥读者也通过第一个进入的读者挡住写者两个互斥方向都满足了。void *writer(void *arg) { int id *(int *)arg; for (int i 0; i 3; i) { pthread_mutex_lock(rw_mutex); shared_data rand() % 100; printf([写者 %d] 写入 shared_data %d\n, id, shared_data); pthread_mutex_unlock(rw_mutex); usleep(rand() % 8000); } return NULL; }注意 main 里线程 id 的传递。如果你用循环变量 i 的地址作为参数传给 pthread_create所有线程拿到的都是同一个地址循环结束后那个地址里的值变成了最终 i 的值。我见过很多同学在这里翻车三个读者线程打印出的 id 全部是 3 或全部是 0。正确写法是 malloc 一个 int 数组每个线程一份拷贝或者直接传 (void*)(long)i。但这里读者函数里把 void* 转成了 int*所以你必须 malloc。下面的 main 函数代码展示了正确姿势。int main(void) { pthread_t readers[READER_NUM], writers[WRITER_NUM]; int *id_r[READER_NUM], *id_w[WRITER_NUM]; srand((unsigned)time(NULL)); for (int i 0; i READER_NUM; i) { id_r[i] malloc(sizeof(int)); *id_r[i] i 1; pthread_create(readers[i], NULL, reader, id_r[i]); } for (int i 0; i WRITER_NUM; i) { id_w[i] malloc(sizeof(int)); *id_w[i] i 1; pthread_create(writers[i], NULL, writer, id_w[i]); } for (int i 0; i READER_NUM; i) { pthread_join(readers[i], NULL); } for (int i 0; i WRITER_NUM; i) { pthread_join(writers[i], NULL); } // 防止内存泄漏 for (int i 0; i READER_NUM; i) free(id_r[i]); for (int i 0; i WRITER_NUM; i) free(id_w[i]); return 0; }读者优先的潜在问题是写者饥饿只要读者不断进入写者就永远拿不到 rw_mutex。你可以连续多跑几次观察写者输出的频率会发现写者的输出数远小于理论预期。如果实验要求写者优先常见的改造是引入第二个信号量或锁新读者必须先等待“没有写者等待”才能开始读。具体的实现方案因实验指导书而异这里不展开重点是你理解读者优先的缺陷。4.3 信号量版本对比什么时候用 sem_t 替代 mutex有的实验会明确要求用信号量实现读者写者。信号量实现读者优先的经典思路是read_mutex 用 sem_init(read_mutex, 0, 1) 初始化rw_mutex 同样初始化为 1逻辑和 mutex 版本完全一一对应。区别在于 sem_wait 和 sem_post 没有 pthread_mutex_lock/unlock 那么好用的所有权概念——任何线程都能调用 sem_post这其实是信号量的优势你可以由任意线程释放资源。但信号量版本的读者写者代码有一个经典的坑sem_wait 不能用于中断处理且不具备“同一线程两次 sem_wait 同一信号量”的保护。如果一个读者线程意外地连续两次 sem_wait(rw_mutex)第一次是合法加锁第二次就死锁了。相比 mutex 的 EDEADLK 检测信号量的错误更隐蔽。我的建议是如果实验没有强制要求优先用 mutex readercount 方案。如果强制用信号量就把 sem_wait 封装成带错误检查的函数至少保证每对 wait/post 之间有日志输出。5. 线程同步避坑指南死锁、数据竞争与假唤醒5.1 条件变量必须配 while 循环假唤醒与扰动的真相现象代码明明用的是 pthread_cond_wait运行几千次后偶尔出现一次消费者取到了“空数据”取值是随机内存里的垃圾。把 if 换成 while 循环后问题消失。原因POSIX 标准明确说条件变量可能存在 spurious wakeup即没有线程调用 signal 或 broadcast等待的线程也会被唤醒。更常见的原因是信号干扰比如进程收到 SIGCHLD 或 SIGALRMpthread_cond_wait 会返回并重新拿锁但此时条件并没有满足。如果你用 if 判断条件那么这次唤醒就会直接越过检查进入临界区访问无效数据。这不是 pthread 的实现缺陷而是 POSIX 允许的调度行为。解决所有 pthread_cond_wait 必须放在 while (条件为真) 的循环里。唤醒后重新检查条件不满足继续等。同时用 pthread_cond_signal 只唤醒一个线程pthread_cond_broadcast 唤醒所有。当多个线程等待同一个条件时broadcast 是更安全的选择虽然会有额外的上下文切换但保证不会漏唤醒。补充一点pthread_cond_wait 返回后并不保证锁一定在你手里因为它是通过传入的 mutex 来关联状态的。如果你在调用 wait 之前没有成功 lock 那个 mutex行为是未定义的常见的表现是直接段错误或死锁。务必检查你的代码路径确保每次 wait 之间都有 lock 和 unlock 配对。5.2 多线程 printf 输出错乱不是同步的错但会误导你现象代码逻辑看起来完全正确但运行后 printf 输出的行被截断比如“[生产者] 放入 42缓冲区剩”打印到一半下一行的“[消费者]”就插进来了。很多人以为这是线程同步没做对开始往 printf 外面加锁结果越搞越乱。原因stdio 的 printf 在大多数实现内部有自己的锁能保证单次输出调用的原子性但你的 printf 如果包含多个参数和计算表达式编译器可能拆成多个输出操作。更重要的是两个线程各自调用 printf 的顺序并不确定即使输出不交错你也会看到日志顺序和实际加解锁顺序不一致。解决把 printf 输出集中到临界区内是实验允许的简化做法。真正要避免的是在临界区外打印共享变量的值比如打印 buf-count此时你已经释放锁了另一个线程可能立刻修改了它你打印的值是滞后的。调试并发程序时我习惯在每条日志里加一个时间戳使用 clock_gettime这样事后分析输出文件时能还原真实的执行序列。5.3 忘记 join 线程导致的数据段错误现象程序运行期间一切正常但 main 函数结束后报段错误或者输出“Tcl_AsyncDelete: async handler deleted by the wrong thread”之类的崩溃信息。原因main 进程退出时如果还有子线程在运行进程会直接终止子线程的资源没有回收指向栈上变量的指针变成悬垂引用。更隐蔽的情况是你在 main 的栈上定义了 shared_buffer线程还在运行但 main 已经返回了栈内存被回收线程再次访问就是非法内存访问。解决所有线程都要 pthread_join这个函数会阻塞直到目标线程结束并回收其资源。创建几个线程就 join 几个。如果你的线程是死循环类型的消费者需要设计好退出条件不要用 pthread_cancel 强杀——它可能导致互斥锁永远不释放。正确的退出流程是设置全局退出标志然后 broadcast 条件变量让消费者检查标志后退出最后再 join。5.4 死锁的定位技巧用 GDB 查看线程堆栈现象程序卡住不动CtrlC 也杀不死必须 kill -9。用 top 看 CPU 占用率接近 0说明线程全部在等待状态。原因互斥锁死锁的典型场景是 A 线程持有锁 L1 等待 L2B 线程持有 L2 等待 L1两个线程互相等待。还有隐式死锁一个线程在持有锁的路径上调用了 pthread_cond_wait但另一个线程忘记了 signal整个程序就永久阻塞了。解决先用 ps -ef 找到进程 PID然后用 gdb attach 到进程输入 thread apply all bt 查看所有线程的堆栈。你会看到每个线程卡在哪个锁的等待上。遇到类似 pthread_mutex_lock 加锁等待就看它上面一个栈帧是哪一行代码。一般的经验是死锁集中在两个写者互相争夺 rw_mutex或条件变量 wait 后无人唤醒。我在实验中用的最多的是 gdb 加 breakpoint 设置在线程函数的入口然后 run 后用 info threads 看线程数量和状态。如果是死锁你会看到至少两个线程处于“锁定”状态下一步就是查看它们各自持有哪把锁。用 gdb 调试多线程程序比加 printf 高效得多——printf 本身会改变线程时序这是著名的观察者效应。5.5 编译加 -fsanitizethread 的简单数据竞争检测现象普通运行测试都通过但偶发出现错误结果。这种 bug 是最烦人的因为它不是必现的换个编译优化级别可能就消失了。原因数据竞争的定义是至少两个线程同时访问同一内存位置至少一个是写操作且没有同步保护。编译器在开启 -O2 后会对无保护访问做重排使问题更严重。你的代码可能在 -O0 下碰巧正常在 -O2 下就崩溃。解决编译时加入 -fsanitizethread运行程序时 ThreadSanitizer 会检测数据竞争并报告具体的内存地址和访问线程。注意这个选项必须配合 -g 使用否则报错信息没有行号。另一个常用工具是 valgrind --toolhelgrind它能检测锁的顺序违反和竞争但运行速度会慢几十倍适合小规模测试用例。我第一次用 ThreadSanitizer 查一个“偶发数据错乱”的问题五分钟就定位到了是在释放锁之后又访问了共享变量的一行代码。提示 如果 ThreadSanitizer 报告了竞争但你觉得代码逻辑没问题请把重点放在“临界区边界”上要么锁的粒度不够要么某条路径绕过了锁。实验里最常见的绕过路径是直接在 main 线程访问共享缓冲区而不是通过线程函数。6. 验证你的实验是否真的“同步了”三个比跑通更有效的检验方法验证线程同步程序的正确性不能靠“跑了几次没问题”。最有效的做法是设计对抗性测试人为制造激烈的竞争条件再检查输出的不变量。第一个不变量是生产者和消费者各自完成的总计数。我在生产者和消费者线程里各维护一个本地计数器程序结束后打印两个总数要求相等。如果生产者生产了 40 个数据消费者必须恰好消费 40 个不丢不重——这不依赖任何锁的正确性只是业务逻辑要求但能立刻发现同步失败导致的数据覆盖。第二个检验是用高负债参数跑压力测试。把生产者数量提到 8消费者提到 4生产总数提到 1000同时把 usleep 的随机时间去掉让线程没有任何人为节流CPU 跑满竞争强度达到最大。配合 -fsanitizethread 编译运行 10 次任何一次出现竞争警告都算失败。这个测试的目的是让同步原语的边界条件暴露在极限调度下。如果代码通过压力测试基本可以放心。第三个检验方法是绘制线程运行时间线。不用装什么复杂工具在关键临界区的入口和出口各打印一行带时间戳的日志重定向到文件然后用 awk 分析每条临界区记录的占用时段。检查两个条件任意两个写者临界区的时间段不重叠任意一个写者临界区与所有读者临界区的时间段不重叠。如果发现重叠不管输出结果是否正确你的同步逻辑都有漏洞。我一般写一个 20 行的 Python 脚本解析日志用集合运算快速找出重叠区间。这个方法花费的时间比肉眼观察长不了多少但能发现隐藏很深的时序问题。最后说一个我在做这个实验时踩过最深的坑为了赶时间我把 pthread_cond_signal 换成了 pthread_cond_broadcast以为“多唤醒几个总比漏唤醒好”。结果在读者写者实验里多个读者同时被唤醒readercount 的加减顺序错乱导致最后一个读者提前释放了 rw_mutex写者趁虚而入共享数据被覆盖。这个错误花了我一整个晚上才定位到。从此之后我给自己定了一条规矩每次修改同步代码后必须从头到尾解释一遍“在并发最极端的情况下这个改动为什么不会破坏不变量”。如果你也能逼自己做到这一点这个实验带给你的收获会比分数值钱得多。希望帮到你。本文还有配套的精品资源点击获取