简介Linux多线程编程实例解析是一份面向系统开发者和编程学习者的技术参考文档围绕多线程这一并发编程核心主题系统梳理了线程与进程的区别、线程引入的多种优势以及实际开发中的常见问题。内容不仅解析了POSIX线程接口中创建、等待、退出等基础函数还结合可运行示例代码演示了线程并发调度并讨论了互斥锁、读写锁、条件变量等同步机制以及线程局部存储、调度优先级等进阶用法帮助读者避开竞态条件和死锁陷阱。整个资源打包为单个PDF文件体积仅134KB便于下载后随时查阅文档结构清晰覆盖从入门概念到工程实践的诸多要点。目前已有1282人学习浏览说明其内容对Linux多线程技术的学习具有一定参考价值。综合来看内容由浅入深适合作为系统学习Linux多线程编程的补充既能帮助初学者建立知识框架也能为开发者提供排错思路与进阶指引。1. 多线程不是加速器而是并发容器Linux下的线程模型长什么样做Linux服务端和嵌入式Linux的同行应该都有这种体会单线程程序逻辑简单、好调试但一旦遇到高并发IO或批量计算CPU开始空转卡顿和超时接踵而来。多线程编程就是在这种场景下被反复提起的——它不是为了把单核算到更快而是为了把等待占用的CPU时间腾出来干别的活。这篇笔记我会沿着pthread这条主线把线程创建、同步、常见的崩溃现场和一个能直接编译的生产者消费者模型完整拆开讲。写给正在写Linux多线程程序、或者准备Linux面试题想搞透线程模型的开发者。pthread接口不难难的是知道什么时候该用哪个原语以及出了问题去哪查。2. pthread基础线程API创建、退出与回收的次序不能乱先说结论pthread_create、pthread_exit、pthread_join这三个函数顺序错一个程序就可能从“偶尔抽风”变成“必现崩溃”。Linux下的多线程编程主线就是pthread这套POSIX线程接口glibc自带C和C通用嵌入式Linux的交叉编译工具链里也是标配。JVM线程和Go的goroutine底层在Linux上最终也是落到pthread或者类似的内核线程上所以把这一层吃透看其他语言线程模型会轻松很多。2.1 从pthread_create说起第四个参数的坑最多pthread_create的函数签名里第一个参数是pthread_t*用来接收线程标识第三个参数是线程入口函数第四个参数是传给入口函数的指针。很多人第一次写多线程喜欢直接把循环变量i的地址传进去然后发现四个线程打出来的id全是4或者全是同一个数——这就是典型的传参生命周期问题。线程入口函数的执行时机不受pthread_create调用时刻约束等线程真正跑到取参那一步循环变量i可能已经走完了整个循环甚至已经被栈回收了。这里给一个最小的完整例子编译和运行都能走得通是入门最稳妥的骨架。#include stdio.h #include stdlib.h #include pthread.h #define THREAD_NUM 4 void* worker(void* arg) { int id *(int*)arg; printf(thread %d start\n, id); /* 模拟一段耗时的业务处理 */ for (volatile int i 0; i 1000000; i); printf(thread %d done\n, id); return NULL; } int main() { pthread_t tids[THREAD_NUM]; int ids[THREAD_NUM]; for (int i 0; i THREAD_NUM; i) { ids[i] i; int ret pthread_create(tids[i], NULL, worker, ids[i]); if (ret ! 0) { fprintf(stderr, pthread_create failed, errcode%d\n, ret); exit(1); } } for (int i 0; i THREAD_NUM; i) { pthread_join(tids[i], NULL); } return 0; }这段代码的逻辑分两部分看循环里ids[i]和ids[i]的搭配是保证每个线程拿到独立id值的关键。如果把id数组换成循环变量i再取地址编译期可能不报错运行时就是典型的随机崩溃。main末尾的pthread_join是必须的它阻塞等待四个线程结束并回收其资源。attr传NULL表示使用默认线程属性——默认栈大小通常是8MB可以用ulimit -s确认。pthread_create的返回值要强调一下它成功返回0失败返回非0错误码而不是设置errno。常见错误码有EAGAIN资源不足线程数到了上限和EINVALattr参数非法。很多人在服务端代码里不检查这个返回值结果线程没创建成功后面的业务逻辑全乱了。在这里做一次if判断是成本最低的防御。2.2 join还是detach两种回收姿势的代价线程退出后资源不会自动还给系统必须由另一个线程调用pthread_join取回它的退出状态或者在线程创建时通过attr设为detach状态。detach的意思是“分离”线程结束后内核直接回收资源不需要join。这个选择要在设计阶段定下来不能边跑边改。常见的错误是既没join也没detach。主线程不退出、子线程频繁创建销毁每次泄漏一点线程资源几天后就会撞上EAGAIN。避免这种局面的做法是能join就join让线程生命周期有明确的汇合点只有那种“启动后长驻、直到进程退出”的工作线程才适合detach。使用attrd设置分离状态和线程栈大小的写法如下pthread_attr_t attr; pthread_t t; pthread_attr_init(attr); /* 嵌入式Linux上默认8MB栈太大压到2MB省内存 */ pthread_attr_setstacksize(attr, 2 * 1024 * 1024); pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED); int ret pthread_create(t, attr, worker, arg); pthread_attr_destroy(attr); if (ret ! 0) { /* 处理创建失败 */ }注意pthread_attr_destroy要在pthread_create之后调用因为创建线程时需要读取attr里的配置销毁attr只是释放属性对象本身不影响已经创建好的线程。线程自己也可以调用pthread_detach(pthread_self())偶尔能看到这种写法效果一样但不建议把分离状态的控制集中到创建方更清晰。2.3 线程退出与返回值别在栈上返回入口函数的return值就是线程的返回值会被pthread_join的第二个参数收到。业务代码里常见的一个坑线程内部定义了一个局部变量然后return local_varjoin那边拿到指针后访问到的内容已经不可预期。正确做法有两种返回一个堆上的值调用方负责free或者返回整数强转的void*。64位平台上整数直接强转没问题32位平台上用intptr_t更稳。如果线程中途想主动结束调用pthread_exit而不是直接return。在主线程里调用pthread_exit时进程不会立即退出其他线程会继续跑。这个行为适合在服务端程序里做优雅关闭主线程退出管理代码让工作线程处理完手头任务再自然结束。3. 同步机制选型互斥锁、读写锁与条件变量的分工与取舍线程之间的竞争靠锁和条件变量来协调。很多初学者上来就是一把互斥锁锁住所有临界区功能能跑性能一测就露馅。Linux下pthread提供三套主流原语pthread_mutex互斥锁、pthread_rwlock读写锁、pthread_cond条件变量。选型的核心不是“哪个好用”而是“数据访问长什么样”。3.1 互斥锁默认选项但要控制好临界区长度互斥锁保护的是“不满足原子性就必须串行”的代码段。典型场景是计数器累加、链表插入、缓冲区读写。标准用法是先初始化、进入临界区前加锁、退出临界区后解锁。初始化有静态和动态两种静态用PTHREAD_MUTEX_INITIALIZER全局或静态变量可以直接用动态用pthread_mutex_init适合需要配置属性的场景比如递归锁、错误检测锁。static pthread_mutex_t counter_mtx PTHREAD_MUTEX_INITIALIZER; int counter 0; void* inc_task(void* arg) { for (int i 0; i 100000; i) { pthread_mutex_lock(counter_mtx); counter; pthread_mutex_unlock(counter_mtx); } return NULL; }这段代码如果去掉锁counter的最终值会小于200000因为counter在汇编层级拆成读取、加一、写回三步两个线程会互相覆盖中间结果。加锁之后每次累加都串行但代价是性能锁的宽度是这个for循环每次都要走一遍加锁解锁。更高效的做法是把整个循环变成一次加锁、循环内累加、最后解锁把临界区压缩到最小。锁的范围和粒度是互斥锁调优的核心。提示临界区里不要放打印、网络IO、磁盘读写这类慢操作。持锁时间越长其他线程等待越久整个程序的并发能力退化得越快。3.2 读写锁读多写少才划算不是银弹读写锁把访问模式分成读者和写者多个读者可以同时持有读锁写者必须独占。逻辑上很完美但实现代价不低——读锁的获取和释放同样需要原子操作和内存屏障在纯读负载下读写锁通常比互斥锁慢。它真正划算的场景是配置表、路由表、缓存这类数据结构读操作占绝大多数写操作很少但必须立即生效。我一般会在压测里对比一把同样多线程读操作互斥锁和读写锁各跑一遍数据更新频率低于1%时读写锁收益明显一旦写入比例超过10%读写锁整体吞吐可能反而不如互斥锁。判断标准不是“读写锁听起来高级”而是先统计你的实际读写比例。3.3 条件变量让线程睡到该干活的时候再醒条件变量解决的问题是“怎么让线程不空转”。互斥锁只保证互斥不能表达“缓冲区有数据了”这种状态变化。条件变量必须和互斥锁配对使用它本身没有状态职责只有一个阻塞当前线程直到其他线程通知它重新检查条件。pthread_mutex_t mtx PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond PTHREAD_COND_INITIALIZER; int queue_empty 1; void consumer_wait() { pthread_mutex_lock(mtx); while (queue_empty) { pthread_cond_wait(cond, mtx); } /* 走到这说明 queue_empty 为0可以消费 */ pthread_mutex_unlock(mtx); }注意两个关键点。第一pthread_cond_wait被调用后当前线程挂起mtx在挂起过程中处于释放状态其他线程可以进入被唤醒后线程先重新拿回mtx再返回调用方感知不到中间的切换过程。第二循环里的判断必须是while而不是if因为POSIX允许虚假唤醒——没有任何线程signal的情况下cond_wait也可能返回。用if判断只会检查一次条件直接越过检查执行消费逻辑拿到空数据或重复消费。这个while设计是Linux面试题里考察线程安全的高频考点。多线程等待同一个条件时pthread_cond_signal只唤醒一个线程pthread_cond_broadcast唤醒全部。多个消费者被同时唤醒后会重新竞争锁然后逐个检查条件所以while循环兜住了“唤醒多了”的情况。能用signal就不用broadcast减少无谓的锁竞争。三种同步原语的选型参考如下原语适用场景主要开销常见风险互斥锁 pthread_mutex短临界区写操作加锁解锁原子操作临界区过长拖垮并发读写锁 pthread_rwlock读远多于写读锁仍需原子操作写比例超过10%性能反降条件变量 pthread_cond等待状态变化线程挂起唤醒切换虚假唤醒需要while重判4. 实践中的多线程避坑记录五条常见的崩溃现场多线程程序的坑有个特点不在压测环境跑个几小时很难复现一上线就隔三差五出问题。以下这五条都是我在Linux多线程开发里踩过或者帮别人排查过的按现象、原因、解决三步记录。4.1 线程创建失败但业务代码毫无感知现象系统运行几天后某些任务突然消失日志里没有报错资源监控显示进程线程数非常高。原因每次请求都创建新线程线程退出后没有join也没有detach资源泄漏最终触达系统上限pthread_create返回EAGAIN。调用方没检查返回值继续执行后面的逻辑等于任务没提交成功但流程照走。少数情况是attr传入了非法值返回EINVAL。解决创建后立即detach或者改用固定线程池复用线程pthread_create的返回值必须判断EAGAIN出现时记录日志并做降级处理而不是默默吞掉。系统线程数上限用ulimit -u查看进程当前线程数看/proc/ /status里的Threads字段。4.2 加锁顺序不一致导致死锁现象程序跑着跑着完全卡死CPU占用降到0gdb attach上去两个线程各自握着一把锁等待另一把。原因线程A先锁资源X再锁资源Y线程B先锁Y再锁X两个线程在某个时刻互相等锁谁也不让。解决全局规定加锁顺序所有线程统一先X后Y或者第二次加锁时改用pthread_mutex_trylock抢不到就释放已有的锁重试用回退打破环路。死锁检测手段见第6章gdb的thread apply all bt能直接看出两个线程各自的等待位置。4.3 条件变量用if判断等来了虚假唤醒现象生产者消费者程序在低负载时正常高负载时偶尔消费到无效数据或者元素计数错乱。原因pthread_cond_wait被唤醒后不保证条件真正满足。多个消费者同时醒来一个消费完数据另一个醒来发现缓冲区空了但用的是if判断直接越过检查去读。解决等待条件一律用while循环这是POSIX标准明确要求的写法——wakeup之后必须重新检查条件。代码review时可以直接搜索pthread_cond_wait后面紧跟的if凡是这种写法基本都有隐患。4.4 errno不是共享变量小心被覆盖现象线程A里打开文件失败perror打印的错误信息却是“Success”。原因Linux下errno被实现为线程私有存储TLS大多数情况下互不干扰。但如果你把errno传给其他线程去处理或者在线程入口里保存了errno指针跨线程解引用就拿到了另一个线程的errno副本时序一错就全乱了。解决出错后立刻用int e errno保存值。只能保存值不能保存地址更不要把errno的地址塞进任务队列。这类线程私有状态的坑同样出现在strtok、localtime这类非线程安全函数上POSIX为此提供了带_r后缀的线程安全版本多线程代码里优先用strtok_r和localtime_r。4.5 线程栈默认8MB递归踩爆只给一个段错误现象程序随机段错误core dump的地址在栈附近单独跑主流程没有问题加多线程后出现。原因每个线程默认栈大小8MBpthread_create创建时不立即分配物理内存但一旦栈顶访问超界就直接段错误。业务代码里递归深度深、或者入口函数里定义了大数组栈很容易被压爆。解决创建线程前用pthread_attr_setstacksize显式设置栈大小。嵌入式Linux上内存紧张一般设1MB到2MB配合pthread_attr_init设置attr再传给pthread_create。但也不要把栈压到512KB以下除非你精确算过递归深度和局部变量占用。排查时先怀疑栈再看野指针——栈撑爆产生的core往往长得像非法访问。5. 生产者消费者完整实例一个可直接编译的pthread工厂模型前面几章把原语拆开讲了这一章把它们组合成一个完整的多线程实例。生产者和消费者是Linux多线程编程里最经典的模型消息队列、日志采集、任务分发都能套这个架子。5.1 完整代码与编译命令下面这个程序可以照抄保存为prod_cond.c用gcc直接编译就能跑。#include stdio.h #include stdlib.h #include unistd.h #include pthread.h #define BUFFER_SIZE 8 /* 环形缓冲区in是写位置out是读位置count是当前元素个数 */ int buffer[BUFFER_SIZE]; int in 0, out 0, count 0; pthread_mutex_t mtx PTHREAD_MUTEX_INITIALIZER; pthread_cond_t not_full PTHREAD_COND_INITIALIZER; pthread_cond_t not_empty PTHREAD_COND_INITIALIZER; void* producer(void* arg) { int item 0; while (1) { item; pthread_mutex_lock(mtx); while (count BUFFER_SIZE) { pthread_cond_wait(not_full, mtx); /* 缓冲区已满等消费者取走数据 */ } buffer[in] item; in (in 1) % BUFFER_SIZE; count; printf(produce %d, count%d\n, item, count); pthread_cond_signal(not_empty); /* 唤醒正在等待的消费者 */ pthread_mutex_unlock(mtx); usleep(200000); } return NULL; } void* consumer(void* arg) { while (1) { pthread_mutex_lock(mtx); while (count 0) { pthread_cond_wait(not_empty, mtx); /* 缓冲区为空等生产者写入数据 */ } int item buffer[out]; out (out 1) % BUFFER_SIZE; count--; printf(consume %d, count%d\n, item, count); pthread_cond_signal(not_full); pthread_mutex_unlock(mtx); usleep(300000); } return NULL; } int main() { pthread_t pid, cid; pthread_create(pid, NULL, producer, NULL); pthread_create(cid, NULL, consumer, NULL); pthread_join(pid, NULL); pthread_join(cid, NULL); return 0; }编译命令gcc -O2 -g -Wall -pthread prod_cond.c -o prod_cond运行后能看到produce和consume交替打印count值始终在0和8之间波动。逻辑拆解分四层第一层是buffer、in、out、count四个状态变量它们被多个线程共享必须由mtx保护第二层是互斥锁mtx保证同一时间只有一个线程操作缓冲区第三层是not_full和not_empty两个条件变量分别代表“缓冲区有空位”和“缓冲区有数据”第四层是两个while循环负责在条件不满足时挂起线程。producer生产前检查count是否等于BUFFER_SIZE满了就等在not_full上consumer消费前检查count是否为0空了就等在not_empty上。代码里printf放在锁内是为了让初学者直观看到count变化。真实项目中打印本身是慢操作应该先在锁内把数据拷贝到局部变量解锁后再打印避免持锁调用printf拖慢整个队列。参数说明里最值得讲的是BUFFER_SIZE。设成8生产者和消费者的竞争会很频繁程序打印里能看到明显的等待现象适合教学理解。真实场景里这个值决定吞吐和延迟的平衡——缓冲区越大消费者能一次性攒更多数据但消息从生产到消费的延迟也变高。IO型任务我用128到1024计算密集任务建议16以内不要让数据在缓冲区里放太久。usleep的200000和300000是模拟生产消费速度差异的换成真实业务就是读文件、收网络包、处理协议这些动作。5.2 为什么是两个条件变量而不是一个这个模型完全可以只用一个条件变量满和空都往同一个cond上signal。但那样的话缓冲区满时生产者等待consumer消费后signal同一个cond如果此时又有一个consumer也在等它可能被误唤醒醒来发现缓冲区是空的继续等——多一次无谓的锁竞争和线程切换。两个条件变量把“不满”和“不空”两种信号拆开producer只唤醒consumerconsumer只唤醒producer语义清晰效率也更高。代码里not_full和not_empty的命名也是一看就知道用途。多消费者场景下还有一个选择signal还是broadcast。上面代码里consumer消费一个元素后只signal一个生产者这对单生产者足够如果生产者也变成多个应该改成pthread_cond_broadcast(not_full)避免多个等待的生产者里只有一个被唤醒其他生产者在缓冲区还有空位的情况下继续睡。判断标准很简单等待方只有一个就signal有多个就broadcast。5.3 这个模型怎么扩展成线程池生产者消费者模型再往前走一步就是线程池。把buffer从int数组换成任务结构体数组生产者的任务变成“往队列里塞任务”消费者变成固定的工作线程启动时创建好长期驻留。规模上CPU密集任务的工作线程数通常设成CPU核数超线程机器上可以设成核数的1到2倍IO密集任务因为线程经常阻塞在读写上可以适当放多经验比例是核数乘以(1 等待时间/计算时间)。嵌入式Linux开发里特别注意线程池每个线程有自己的栈4个工作线程按1MB栈算就是4MB有的板子内存总共才64MB创建线程池前先算内存账别把系统堆栈挤爆。线程池的一个额外收益是避免线程频繁创建销毁。pthread_create底层要走clone系统调用涉及内核栈分配高频任务下开销明显复用线程能把这部分成本摊到0。这也是为什么正规的服务端程序很少在请求里临时创建线程。6. 验证多线程程序的三个手段sanitizer、perf与gdb代码能编译能跑只是开始多线程程序的验证重点在数据竞争和锁等待。先跑ThreadSanitizer再谈性能——数据竞争不查干净性能调优都是白做。6.1 先用TSan把数据竞争找一个遍ThreadSanitizer是编译器的数据竞争检测工具编译时加-fsanitizethread即可gcc -fsanitizethread -g prod_cond.c -o prod_cond_tsan运行后如果有数据竞争会在终端直接打印出两个线程的访问栈精确到文件名和行号。我对新写的多线程代码都会用它跑一轮压测发现竞争再修省下的排查时间远超编译开销。TSan会让程序变慢几倍跑得慢是正常的关键是它能把潜伏的竞态暴露出来。6.2 perf和gdb定位锁竞争与死锁死锁现场用gdb attachgdb -p 需要同用户权限然后执行thread apply all bt每个线程的调用栈都会打出来。死锁时能看到两个线程各自卡在pthread_cond_wait或lock上。锁竞争的性能问题用perf top看热点如果热点集中在futex或pthread_mutex_lock上说明锁太激烈考虑减小临界区或换无锁结构。做嵌入式Linux这些年我养成了两个习惯线程函数都用pthread_setname_np设置一个有意义的名称core dump里一眼看出是哪个线程出的问题另一个是编译永远带-g。这两个习惯在很多次半夜排障时救过我比任何技巧都管用。希望帮到你。本文还有配套的精品资源点击获取
Linux多线程编程实战：pthread同步机制与生产者消费者模型详解
简介Linux多线程编程实例解析是一份面向系统开发者和编程学习者的技术参考文档围绕多线程这一并发编程核心主题系统梳理了线程与进程的区别、线程引入的多种优势以及实际开发中的常见问题。内容不仅解析了POSIX线程接口中创建、等待、退出等基础函数还结合可运行示例代码演示了线程并发调度并讨论了互斥锁、读写锁、条件变量等同步机制以及线程局部存储、调度优先级等进阶用法帮助读者避开竞态条件和死锁陷阱。整个资源打包为单个PDF文件体积仅134KB便于下载后随时查阅文档结构清晰覆盖从入门概念到工程实践的诸多要点。目前已有1282人学习浏览说明其内容对Linux多线程技术的学习具有一定参考价值。综合来看内容由浅入深适合作为系统学习Linux多线程编程的补充既能帮助初学者建立知识框架也能为开发者提供排错思路与进阶指引。1. 多线程不是加速器而是并发容器Linux下的线程模型长什么样做Linux服务端和嵌入式Linux的同行应该都有这种体会单线程程序逻辑简单、好调试但一旦遇到高并发IO或批量计算CPU开始空转卡顿和超时接踵而来。多线程编程就是在这种场景下被反复提起的——它不是为了把单核算到更快而是为了把等待占用的CPU时间腾出来干别的活。这篇笔记我会沿着pthread这条主线把线程创建、同步、常见的崩溃现场和一个能直接编译的生产者消费者模型完整拆开讲。写给正在写Linux多线程程序、或者准备Linux面试题想搞透线程模型的开发者。pthread接口不难难的是知道什么时候该用哪个原语以及出了问题去哪查。2. pthread基础线程API创建、退出与回收的次序不能乱先说结论pthread_create、pthread_exit、pthread_join这三个函数顺序错一个程序就可能从“偶尔抽风”变成“必现崩溃”。Linux下的多线程编程主线就是pthread这套POSIX线程接口glibc自带C和C通用嵌入式Linux的交叉编译工具链里也是标配。JVM线程和Go的goroutine底层在Linux上最终也是落到pthread或者类似的内核线程上所以把这一层吃透看其他语言线程模型会轻松很多。2.1 从pthread_create说起第四个参数的坑最多pthread_create的函数签名里第一个参数是pthread_t*用来接收线程标识第三个参数是线程入口函数第四个参数是传给入口函数的指针。很多人第一次写多线程喜欢直接把循环变量i的地址传进去然后发现四个线程打出来的id全是4或者全是同一个数——这就是典型的传参生命周期问题。线程入口函数的执行时机不受pthread_create调用时刻约束等线程真正跑到取参那一步循环变量i可能已经走完了整个循环甚至已经被栈回收了。这里给一个最小的完整例子编译和运行都能走得通是入门最稳妥的骨架。#include stdio.h #include stdlib.h #include pthread.h #define THREAD_NUM 4 void* worker(void* arg) { int id *(int*)arg; printf(thread %d start\n, id); /* 模拟一段耗时的业务处理 */ for (volatile int i 0; i 1000000; i); printf(thread %d done\n, id); return NULL; } int main() { pthread_t tids[THREAD_NUM]; int ids[THREAD_NUM]; for (int i 0; i THREAD_NUM; i) { ids[i] i; int ret pthread_create(tids[i], NULL, worker, ids[i]); if (ret ! 0) { fprintf(stderr, pthread_create failed, errcode%d\n, ret); exit(1); } } for (int i 0; i THREAD_NUM; i) { pthread_join(tids[i], NULL); } return 0; }这段代码的逻辑分两部分看循环里ids[i]和ids[i]的搭配是保证每个线程拿到独立id值的关键。如果把id数组换成循环变量i再取地址编译期可能不报错运行时就是典型的随机崩溃。main末尾的pthread_join是必须的它阻塞等待四个线程结束并回收其资源。attr传NULL表示使用默认线程属性——默认栈大小通常是8MB可以用ulimit -s确认。pthread_create的返回值要强调一下它成功返回0失败返回非0错误码而不是设置errno。常见错误码有EAGAIN资源不足线程数到了上限和EINVALattr参数非法。很多人在服务端代码里不检查这个返回值结果线程没创建成功后面的业务逻辑全乱了。在这里做一次if判断是成本最低的防御。2.2 join还是detach两种回收姿势的代价线程退出后资源不会自动还给系统必须由另一个线程调用pthread_join取回它的退出状态或者在线程创建时通过attr设为detach状态。detach的意思是“分离”线程结束后内核直接回收资源不需要join。这个选择要在设计阶段定下来不能边跑边改。常见的错误是既没join也没detach。主线程不退出、子线程频繁创建销毁每次泄漏一点线程资源几天后就会撞上EAGAIN。避免这种局面的做法是能join就join让线程生命周期有明确的汇合点只有那种“启动后长驻、直到进程退出”的工作线程才适合detach。使用attrd设置分离状态和线程栈大小的写法如下pthread_attr_t attr; pthread_t t; pthread_attr_init(attr); /* 嵌入式Linux上默认8MB栈太大压到2MB省内存 */ pthread_attr_setstacksize(attr, 2 * 1024 * 1024); pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED); int ret pthread_create(t, attr, worker, arg); pthread_attr_destroy(attr); if (ret ! 0) { /* 处理创建失败 */ }注意pthread_attr_destroy要在pthread_create之后调用因为创建线程时需要读取attr里的配置销毁attr只是释放属性对象本身不影响已经创建好的线程。线程自己也可以调用pthread_detach(pthread_self())偶尔能看到这种写法效果一样但不建议把分离状态的控制集中到创建方更清晰。2.3 线程退出与返回值别在栈上返回入口函数的return值就是线程的返回值会被pthread_join的第二个参数收到。业务代码里常见的一个坑线程内部定义了一个局部变量然后return local_varjoin那边拿到指针后访问到的内容已经不可预期。正确做法有两种返回一个堆上的值调用方负责free或者返回整数强转的void*。64位平台上整数直接强转没问题32位平台上用intptr_t更稳。如果线程中途想主动结束调用pthread_exit而不是直接return。在主线程里调用pthread_exit时进程不会立即退出其他线程会继续跑。这个行为适合在服务端程序里做优雅关闭主线程退出管理代码让工作线程处理完手头任务再自然结束。3. 同步机制选型互斥锁、读写锁与条件变量的分工与取舍线程之间的竞争靠锁和条件变量来协调。很多初学者上来就是一把互斥锁锁住所有临界区功能能跑性能一测就露馅。Linux下pthread提供三套主流原语pthread_mutex互斥锁、pthread_rwlock读写锁、pthread_cond条件变量。选型的核心不是“哪个好用”而是“数据访问长什么样”。3.1 互斥锁默认选项但要控制好临界区长度互斥锁保护的是“不满足原子性就必须串行”的代码段。典型场景是计数器累加、链表插入、缓冲区读写。标准用法是先初始化、进入临界区前加锁、退出临界区后解锁。初始化有静态和动态两种静态用PTHREAD_MUTEX_INITIALIZER全局或静态变量可以直接用动态用pthread_mutex_init适合需要配置属性的场景比如递归锁、错误检测锁。static pthread_mutex_t counter_mtx PTHREAD_MUTEX_INITIALIZER; int counter 0; void* inc_task(void* arg) { for (int i 0; i 100000; i) { pthread_mutex_lock(counter_mtx); counter; pthread_mutex_unlock(counter_mtx); } return NULL; }这段代码如果去掉锁counter的最终值会小于200000因为counter在汇编层级拆成读取、加一、写回三步两个线程会互相覆盖中间结果。加锁之后每次累加都串行但代价是性能锁的宽度是这个for循环每次都要走一遍加锁解锁。更高效的做法是把整个循环变成一次加锁、循环内累加、最后解锁把临界区压缩到最小。锁的范围和粒度是互斥锁调优的核心。提示临界区里不要放打印、网络IO、磁盘读写这类慢操作。持锁时间越长其他线程等待越久整个程序的并发能力退化得越快。3.2 读写锁读多写少才划算不是银弹读写锁把访问模式分成读者和写者多个读者可以同时持有读锁写者必须独占。逻辑上很完美但实现代价不低——读锁的获取和释放同样需要原子操作和内存屏障在纯读负载下读写锁通常比互斥锁慢。它真正划算的场景是配置表、路由表、缓存这类数据结构读操作占绝大多数写操作很少但必须立即生效。我一般会在压测里对比一把同样多线程读操作互斥锁和读写锁各跑一遍数据更新频率低于1%时读写锁收益明显一旦写入比例超过10%读写锁整体吞吐可能反而不如互斥锁。判断标准不是“读写锁听起来高级”而是先统计你的实际读写比例。3.3 条件变量让线程睡到该干活的时候再醒条件变量解决的问题是“怎么让线程不空转”。互斥锁只保证互斥不能表达“缓冲区有数据了”这种状态变化。条件变量必须和互斥锁配对使用它本身没有状态职责只有一个阻塞当前线程直到其他线程通知它重新检查条件。pthread_mutex_t mtx PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond PTHREAD_COND_INITIALIZER; int queue_empty 1; void consumer_wait() { pthread_mutex_lock(mtx); while (queue_empty) { pthread_cond_wait(cond, mtx); } /* 走到这说明 queue_empty 为0可以消费 */ pthread_mutex_unlock(mtx); }注意两个关键点。第一pthread_cond_wait被调用后当前线程挂起mtx在挂起过程中处于释放状态其他线程可以进入被唤醒后线程先重新拿回mtx再返回调用方感知不到中间的切换过程。第二循环里的判断必须是while而不是if因为POSIX允许虚假唤醒——没有任何线程signal的情况下cond_wait也可能返回。用if判断只会检查一次条件直接越过检查执行消费逻辑拿到空数据或重复消费。这个while设计是Linux面试题里考察线程安全的高频考点。多线程等待同一个条件时pthread_cond_signal只唤醒一个线程pthread_cond_broadcast唤醒全部。多个消费者被同时唤醒后会重新竞争锁然后逐个检查条件所以while循环兜住了“唤醒多了”的情况。能用signal就不用broadcast减少无谓的锁竞争。三种同步原语的选型参考如下原语适用场景主要开销常见风险互斥锁 pthread_mutex短临界区写操作加锁解锁原子操作临界区过长拖垮并发读写锁 pthread_rwlock读远多于写读锁仍需原子操作写比例超过10%性能反降条件变量 pthread_cond等待状态变化线程挂起唤醒切换虚假唤醒需要while重判4. 实践中的多线程避坑记录五条常见的崩溃现场多线程程序的坑有个特点不在压测环境跑个几小时很难复现一上线就隔三差五出问题。以下这五条都是我在Linux多线程开发里踩过或者帮别人排查过的按现象、原因、解决三步记录。4.1 线程创建失败但业务代码毫无感知现象系统运行几天后某些任务突然消失日志里没有报错资源监控显示进程线程数非常高。原因每次请求都创建新线程线程退出后没有join也没有detach资源泄漏最终触达系统上限pthread_create返回EAGAIN。调用方没检查返回值继续执行后面的逻辑等于任务没提交成功但流程照走。少数情况是attr传入了非法值返回EINVAL。解决创建后立即detach或者改用固定线程池复用线程pthread_create的返回值必须判断EAGAIN出现时记录日志并做降级处理而不是默默吞掉。系统线程数上限用ulimit -u查看进程当前线程数看/proc/ /status里的Threads字段。4.2 加锁顺序不一致导致死锁现象程序跑着跑着完全卡死CPU占用降到0gdb attach上去两个线程各自握着一把锁等待另一把。原因线程A先锁资源X再锁资源Y线程B先锁Y再锁X两个线程在某个时刻互相等锁谁也不让。解决全局规定加锁顺序所有线程统一先X后Y或者第二次加锁时改用pthread_mutex_trylock抢不到就释放已有的锁重试用回退打破环路。死锁检测手段见第6章gdb的thread apply all bt能直接看出两个线程各自的等待位置。4.3 条件变量用if判断等来了虚假唤醒现象生产者消费者程序在低负载时正常高负载时偶尔消费到无效数据或者元素计数错乱。原因pthread_cond_wait被唤醒后不保证条件真正满足。多个消费者同时醒来一个消费完数据另一个醒来发现缓冲区空了但用的是if判断直接越过检查去读。解决等待条件一律用while循环这是POSIX标准明确要求的写法——wakeup之后必须重新检查条件。代码review时可以直接搜索pthread_cond_wait后面紧跟的if凡是这种写法基本都有隐患。4.4 errno不是共享变量小心被覆盖现象线程A里打开文件失败perror打印的错误信息却是“Success”。原因Linux下errno被实现为线程私有存储TLS大多数情况下互不干扰。但如果你把errno传给其他线程去处理或者在线程入口里保存了errno指针跨线程解引用就拿到了另一个线程的errno副本时序一错就全乱了。解决出错后立刻用int e errno保存值。只能保存值不能保存地址更不要把errno的地址塞进任务队列。这类线程私有状态的坑同样出现在strtok、localtime这类非线程安全函数上POSIX为此提供了带_r后缀的线程安全版本多线程代码里优先用strtok_r和localtime_r。4.5 线程栈默认8MB递归踩爆只给一个段错误现象程序随机段错误core dump的地址在栈附近单独跑主流程没有问题加多线程后出现。原因每个线程默认栈大小8MBpthread_create创建时不立即分配物理内存但一旦栈顶访问超界就直接段错误。业务代码里递归深度深、或者入口函数里定义了大数组栈很容易被压爆。解决创建线程前用pthread_attr_setstacksize显式设置栈大小。嵌入式Linux上内存紧张一般设1MB到2MB配合pthread_attr_init设置attr再传给pthread_create。但也不要把栈压到512KB以下除非你精确算过递归深度和局部变量占用。排查时先怀疑栈再看野指针——栈撑爆产生的core往往长得像非法访问。5. 生产者消费者完整实例一个可直接编译的pthread工厂模型前面几章把原语拆开讲了这一章把它们组合成一个完整的多线程实例。生产者和消费者是Linux多线程编程里最经典的模型消息队列、日志采集、任务分发都能套这个架子。5.1 完整代码与编译命令下面这个程序可以照抄保存为prod_cond.c用gcc直接编译就能跑。#include stdio.h #include stdlib.h #include unistd.h #include pthread.h #define BUFFER_SIZE 8 /* 环形缓冲区in是写位置out是读位置count是当前元素个数 */ int buffer[BUFFER_SIZE]; int in 0, out 0, count 0; pthread_mutex_t mtx PTHREAD_MUTEX_INITIALIZER; pthread_cond_t not_full PTHREAD_COND_INITIALIZER; pthread_cond_t not_empty PTHREAD_COND_INITIALIZER; void* producer(void* arg) { int item 0; while (1) { item; pthread_mutex_lock(mtx); while (count BUFFER_SIZE) { pthread_cond_wait(not_full, mtx); /* 缓冲区已满等消费者取走数据 */ } buffer[in] item; in (in 1) % BUFFER_SIZE; count; printf(produce %d, count%d\n, item, count); pthread_cond_signal(not_empty); /* 唤醒正在等待的消费者 */ pthread_mutex_unlock(mtx); usleep(200000); } return NULL; } void* consumer(void* arg) { while (1) { pthread_mutex_lock(mtx); while (count 0) { pthread_cond_wait(not_empty, mtx); /* 缓冲区为空等生产者写入数据 */ } int item buffer[out]; out (out 1) % BUFFER_SIZE; count--; printf(consume %d, count%d\n, item, count); pthread_cond_signal(not_full); pthread_mutex_unlock(mtx); usleep(300000); } return NULL; } int main() { pthread_t pid, cid; pthread_create(pid, NULL, producer, NULL); pthread_create(cid, NULL, consumer, NULL); pthread_join(pid, NULL); pthread_join(cid, NULL); return 0; }编译命令gcc -O2 -g -Wall -pthread prod_cond.c -o prod_cond运行后能看到produce和consume交替打印count值始终在0和8之间波动。逻辑拆解分四层第一层是buffer、in、out、count四个状态变量它们被多个线程共享必须由mtx保护第二层是互斥锁mtx保证同一时间只有一个线程操作缓冲区第三层是not_full和not_empty两个条件变量分别代表“缓冲区有空位”和“缓冲区有数据”第四层是两个while循环负责在条件不满足时挂起线程。producer生产前检查count是否等于BUFFER_SIZE满了就等在not_full上consumer消费前检查count是否为0空了就等在not_empty上。代码里printf放在锁内是为了让初学者直观看到count变化。真实项目中打印本身是慢操作应该先在锁内把数据拷贝到局部变量解锁后再打印避免持锁调用printf拖慢整个队列。参数说明里最值得讲的是BUFFER_SIZE。设成8生产者和消费者的竞争会很频繁程序打印里能看到明显的等待现象适合教学理解。真实场景里这个值决定吞吐和延迟的平衡——缓冲区越大消费者能一次性攒更多数据但消息从生产到消费的延迟也变高。IO型任务我用128到1024计算密集任务建议16以内不要让数据在缓冲区里放太久。usleep的200000和300000是模拟生产消费速度差异的换成真实业务就是读文件、收网络包、处理协议这些动作。5.2 为什么是两个条件变量而不是一个这个模型完全可以只用一个条件变量满和空都往同一个cond上signal。但那样的话缓冲区满时生产者等待consumer消费后signal同一个cond如果此时又有一个consumer也在等它可能被误唤醒醒来发现缓冲区是空的继续等——多一次无谓的锁竞争和线程切换。两个条件变量把“不满”和“不空”两种信号拆开producer只唤醒consumerconsumer只唤醒producer语义清晰效率也更高。代码里not_full和not_empty的命名也是一看就知道用途。多消费者场景下还有一个选择signal还是broadcast。上面代码里consumer消费一个元素后只signal一个生产者这对单生产者足够如果生产者也变成多个应该改成pthread_cond_broadcast(not_full)避免多个等待的生产者里只有一个被唤醒其他生产者在缓冲区还有空位的情况下继续睡。判断标准很简单等待方只有一个就signal有多个就broadcast。5.3 这个模型怎么扩展成线程池生产者消费者模型再往前走一步就是线程池。把buffer从int数组换成任务结构体数组生产者的任务变成“往队列里塞任务”消费者变成固定的工作线程启动时创建好长期驻留。规模上CPU密集任务的工作线程数通常设成CPU核数超线程机器上可以设成核数的1到2倍IO密集任务因为线程经常阻塞在读写上可以适当放多经验比例是核数乘以(1 等待时间/计算时间)。嵌入式Linux开发里特别注意线程池每个线程有自己的栈4个工作线程按1MB栈算就是4MB有的板子内存总共才64MB创建线程池前先算内存账别把系统堆栈挤爆。线程池的一个额外收益是避免线程频繁创建销毁。pthread_create底层要走clone系统调用涉及内核栈分配高频任务下开销明显复用线程能把这部分成本摊到0。这也是为什么正规的服务端程序很少在请求里临时创建线程。6. 验证多线程程序的三个手段sanitizer、perf与gdb代码能编译能跑只是开始多线程程序的验证重点在数据竞争和锁等待。先跑ThreadSanitizer再谈性能——数据竞争不查干净性能调优都是白做。6.1 先用TSan把数据竞争找一个遍ThreadSanitizer是编译器的数据竞争检测工具编译时加-fsanitizethread即可gcc -fsanitizethread -g prod_cond.c -o prod_cond_tsan运行后如果有数据竞争会在终端直接打印出两个线程的访问栈精确到文件名和行号。我对新写的多线程代码都会用它跑一轮压测发现竞争再修省下的排查时间远超编译开销。TSan会让程序变慢几倍跑得慢是正常的关键是它能把潜伏的竞态暴露出来。6.2 perf和gdb定位锁竞争与死锁死锁现场用gdb attachgdb -p 需要同用户权限然后执行thread apply all bt每个线程的调用栈都会打出来。死锁时能看到两个线程各自卡在pthread_cond_wait或lock上。锁竞争的性能问题用perf top看热点如果热点集中在futex或pthread_mutex_lock上说明锁太激烈考虑减小临界区或换无锁结构。做嵌入式Linux这些年我养成了两个习惯线程函数都用pthread_setname_np设置一个有意义的名称core dump里一眼看出是哪个线程出的问题另一个是编译永远带-g。这两个习惯在很多次半夜排障时救过我比任何技巧都管用。希望帮到你。本文还有配套的精品资源点击获取
