1. 线程控制到底控制什么——先理清核心概念很多朋友对线程的印象就是程序里能并发的代码段但真到了写多线程程序的时候往往一脸懵为什么我的线程消失了为什么的资源没释放为什么一跑就崩这些问题的根源基本都出在线程控制这个环节。线程控制简单来说就是对线程生命周期和运行行为的管理。包括创建线程、让线程退出、等待线程结束、分离线程、取消线程、控制线程的同步与互斥以及对线程运行时的栈大小、调度策略、局部存储这些底层属性做设置。你把这些控制点搞明白了多线程的坑基本能填掉一大半。这块内容在不同的系统上实现有差异但思路是通用的。下面我以C语言加POSIX线程库pthread为主线来讲因为它是事实上的标准而且在Linux服务器开发里用得最多。Windows上有类似的一套API思路完全可以平移。写这类东西如果不实操很容易变成背概念。所以我后文会穿插完整的可运行代码和调试手法尽量让刚接触线程的朋友也能边读边跟着做一遍。2. 线程创建与退出影响性能与稳定性的第一道关卡2.1 创建线程前必须回答的三个问题创建线程看起来就是调一个pthread_create但实际工程里你动手敲代码之前得先想清楚三件事线程要干什么、干完怎么退出、谁来回收它的资源。先说第一件事。线程的入口函数就是它运行的灵魂它通常长这样void *worker(void *arg) { // 业务逻辑 return NULL; }注意这个函数签名返回void *且只接收一个void *参数。很多新人会在这里栽跟头——你想传多个参数进去结果发现函数只能收一个指针。解决办法也很粗暴但很实用定义一个结构体把要传的参数打包进去再把这个结构体指针传进去。这是业界最常见的传参方式别嫌麻烦它比传一堆全局变量要安全得多。第二个问题线程干完活怎么退出。正确姿势有三条路让入口函数正常return调用pthread_exit或者被其他线程pthread_cancel掉。这里最容易被忽略的是不要用exit退出线程。exit是终止整个进程的你线程一调exit兄弟线程全都玩完。第三个问题很关键谁来回收它。线程的资源不会因为你那个函数返回了就自动清理干净它需要有人去收尸。收尸的动作就是pthread_join。谁创建的线程通常就应该由谁来负责 join 回收这是保证资源不泄漏的基础纪律。2.2 创建、等待线程的代码模板我直接给出一段最小可用的模板顺序和细节都是验证过的#include pthread.h #include stdio.h #include stdlib.h #include string.h typedef struct { int id; char name[64]; } task_t; void *worker(void *arg) { task_t *t (task_t *)arg; printf(worker [%d] name%s running\n, t-id, t-name); // 模拟业务处理 for (int i 0; i 3; i) { printf(worker [%d] step %d\n, t-id, i); } return (void *)0; } int main(void) { pthread_t tid; task_t t {.id 1, .name demo}; int rc pthread_create(tid, NULL, worker, t); if (rc ! 0) { fprintf(stderr, create failed: %d\n, rc); exit(EXIT_FAILURE); } // 等待线程结束并回收 void *retval NULL; pthread_join(tid, retval); printf(main: join done\n); return 0; }编译时一定记得链接 pthread 库gcc -Wall -O2 -o demo demo.c -pthread跑一下你就能看到主线程阻塞在pthread_join那里直到 worker 执行完才继续往下走。这就是等待线程结束的标准语义。2.3 返回值传递的两种姿势pthread_join的第二个参数能拿到线程的返回值。线程返回值主要有两种传递方式第一种直接返回数字比如返回错误码void *worker(void *arg) { // 干点活 return (void *)42; // 被 join 后打印为 42 }第二种返回堆上分配的结构指针。因为主线程侧pthread_join只是收一个地址线程函数返回的地址必须保证线程退出之后依然有效通常就得上堆void *worker(void *arg) { task_t *result malloc(sizeof(task_t)); ... return result; // 主线程拿到后用完 free }如果你是新手我不推荐一上来就用第二种方式除非你明确知道这块内存谁来释放。工程里我见过太多因为线程返回堆指针导致的内存泄漏和 double free这比简单返回一个数值要容易出错得多。3. 线程分离与取消两种容易看似正确的危险操作3.1 pthreat_detach 到底干什么pthread_detach是另一个让人误用的接口。它做的事情是把当前线程标记为分离状态。分离之后线程结束时系统会自动回收它的资源不需要你再调用pthread_join。这么看分离状态是不是很省事省事是省事但代价是你永远不知道它什么时候结束也拿不到它的返回值。pthread_join还能阻塞等待结果pthread_detach一分离线程就跟脱缰的野马一样与你再无关联。我推荐的实际策略是工作线程如果是一次性任务跑完就走而且你不需要它的执行结果那就用分离模式避免主线程频繁 join 等待拖慢整体节奏。但如果是需要收集结果的并行计算任务就必须用 join 模式别偷懒。有个细节大家要记住默认创建出来的线程是可结合的也就是说你如果不调 detach那就必须有一个对应的 join否则这个线程的资源会一直挂着。这是线程资源泄漏的最常见场景。3.2 pthread_cancel 真的能把线程停下来吗很多需求是希望某个线程马上停止工作。C 里对应的接口是pthread_cancel。但我要很严肃地告诉你pthread_cancel默认情况下不是立即终止线程的。POSIX 线程的取消机制分为两个控制点一个叫取消状态一个叫取消类型。默认情况下线程的取消类型是延时取消意思是你调用pthread_cancel后目标线程并不会马上死掉只有当它执行到某个取消点时才响应取消。取消点基本都发生在系统调用上比如read、write、sleep这类函数。这就导致一个经典问题如果线程在做一个很重的纯计算循环中间没有任何系统调用你pthread_cancel它根本没用。它在那个循环里跑得飞起对你的取消请求视而不见。想要更暴力一点的取消需要打开异步取消类型pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);但我不推荐这么用因为异步取消可能在任何指令处中断线程资源清理、锁释放根本没机会执行结果就是死锁或者数据不一致。3.3 取消清理函数的正确写法既然取消会中断线程线程函数里持有的锁、分配的内存怎么释放POSIX 提供了清理函数void cleanup(void *arg) { // 释放锁、释放内存 printf(cleanup: %s\n, (char *)arg); } void *worker(void *arg) { pthread_cleanup_push(cleanup, cleaning up); // 业务逻辑 pthread_cleanup_pop(1); // 1 表示执行清理函数 return NULL; }pthread_cleanup_push和pthread_cleanup_pop必须配对出现否则编译不过。如果线程因为pthread_cancel被终止系统会先执行 cleanup 里的代码再结束线程。如果正常返回pthread_cleanup_pop也能手动触发清理。这个机制的核心思想是无论线程是怎么死的都要给它一个临终清理的机会。就像一个人不管怎么离开岗位交接工作得做完。4. 线程同步控制互斥锁与条件变量的工程用法4.1 互斥锁不是加锁那么简单多线程一共享数据互斥锁就躲不掉了。但我在代码评审里见过太多人把它用成程序不会崩就行的程度。比如这个典型的加锁代码pthread_mutex_lock(lock); if (shared_value 0) { shared_value--; } pthread_mutex_unlock(lock);逻辑没错但隐藏问题在于如果shared_value的访问姿势不统一——有的地方加了锁有的地方忘了加——那锁就等于白加。数据竞争是隐形的不一定会立刻崩但跑在极端情况下它就会给你表演不可能发生的事。我在实际项目中的原则是凡是跨线程访问的变量访问路径必须在同一把锁的保护下。所谓同一把锁指的是同一个pthread_mutex_t对象。并且要养成习惯加锁代码块的粒度尽量小锁内只做该做的事别把耗时的 IO 操作都包进去。来看一个相对完整的账户操作例子pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; int balance 100; void *atm_withdraw(void *arg) { int amount *(int *)arg; pthread_mutex_lock(lock); if (balance amount) { // 模拟一些检查校验 balance - amount; printf(withdraw %d, balance %d\n, amount, balance); } else { printf(insufficient balance\n); } pthread_mutex_unlock(lock); return NULL; }这里面锁内没有sleep这类慢操作逻辑干净利落。把需要保护的共享数据访问全部放进去其余东西一律隔离在外。4.2 条件变量等待与通知的正确信令只靠互斥锁做线程同步往往不够因为你可能希望某个条件满足时再继续干活这时候轮询加锁太费劲条件变量就是标准解法。条件变量的经典场景是生产者-消费者模型。生产者往队列里放数据消费者阻塞等待队列非空。消费者这边的代码长这样pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond PTHREAD_COND_INITIALIZER; // 消费者 pthread_mutex_lock(lock); while (queue_empty()) { pthread_cond_wait(cond, lock); } item pop_queue(); pthread_mutex_unlock(lock);注意这里用的是while而不是if。为什么因为条件变量的等待存在虚假唤醒的可能——线程可能在没有收到通知的情况下醒过来。用while重新检查条件能彻底规避这个坑。生产者的唤醒代码pthread_mutex_lock(lock); push_queue(item); pthread_cond_signal(cond); pthread_mutex_unlock(lock);signal唤醒一个等待线程broadcast唤醒全部等待线程。只有一个消费者时用signal就够了但多个消费者争抢同一批任务时用broadcast通常更稳妥因为你难得判断哪一个消费者应该被唤醒。4.3 死锁四个必要条件与一个实用避坑指南死锁这东西做并发开发的一定听过线程 A 持有锁1等待锁2线程 B 持有锁2等待锁1两个线程互相等待谁都不让程序就僵住了。产生死锁的四个必要条件网上讲烂了互斥、持有并等待、不可剥夺、循环等待。我要说点实际的。对付死锁我在工程里最常用也最好使的策略就一条全局约定加锁顺序。比如所有线程必须先拿锁 A再拿锁 B禁止反着来。只要顺序一致循环等待就不会出现。再加两条兜底尽量减小锁的持有时间能用一把锁就别用两把。如果确实需要多把锁可以考虑用pthread_mutex_trylock做试探拿不到第二把锁就放弃第一把回头重试避免陷入互相等待。写代码时容易犯的另一个毛病是忘记解锁。函数里多个分支提前 return锁还握在手里。所以很多开源代码会写成 goto cleanup 的样式统一在出口处解锁。你也可以用这种方式可读性和安全性都好很多。5. 线程局部存储与底层控制细节5.1 线程局部存储为什么比全局变量靠得住全局变量在多线程里是典型的共享数据来源一个线程修改其他线程全受影响。但有些变量天生就该是每个线程各自一份比如线程自己的业务上下文、日志序号、缓存句柄。这种需求用线程局部存储TLS来做最合适。在 C11 或者 POSIX 环境下_Thread_local关键字可以直接声明_Thread_local int thread_error_code 0;每个线程访问的都是自己的一份副本互不干扰。如果要在纯 pthread 环境里动态做 TLS可以用pthread_key_t那套麻烦一点但功能更全。我之所以强调 TLS是因为很多实际问题的根源就是用全局变量偷懒。比如一个线程池里的任务处理函数有人拿全局结构当参数中转站结果多个线程同时覆盖同一个数据程序行为完全随机。用 TLS 替代这类全局数据很多诡异的竞态问题自动就消失了。5.2 栈大小与线程属性设置线程默认栈大小在 Linux 上一般是 8MB 左右。但系统只是给你预留虚拟内存实际占用是按需分配的。可某些场景比如嵌入式环境、高并发线程池8MB 还是太大了。这时候就需要显式设置线程属性中的栈大小。pthread_attr_t attr; pthread_attr_init(attr); pthread_attr_setstacksize(attr, 1024 * 1024); // 1MB pthread_create(tid, attr, worker, arg); pthread_attr_destroy(attr);设置栈大小要考虑栈溢出的风险。递归算法、大数组放栈上尤其危险。我见过的极端案例是某程序把线程栈压到 512KB结果业务里一个 1MB 的局部数组直接把栈怼穿了程序崩得莫名其妙。排查了半天才定位到是栈溢出。这类崩溃往往表现为段错误而且返回地址已经乱掉。所以要给线程栈尺寸留足余量一般建议不低于 1MB除非你能明确算清楚调用深度和局部变量的空间需求。5.3 线程调度优先级尽量不要随便动Linux 的默认线程调度策略是公平调度普通线程之间按照优先级和 CPU 时间去分配。如果你用pthread_setschedparam去改线程的调度策略和优先级小心踩坑。改了优先级未必能跑得更快。调度策略涉及系统负载、CPU 亲和性、实时优先级等多种因素。一个不留神你把某个线程设为SCHED_FIFO实时优先级它不交 CPU其他普通线程就全卡住了。这画面在服务器上出现一次就够你加班排查一周的。我的建议是默认调度策略能满足绝大多数业务需求。只有当你非常清楚实时线程的必要性并且对系统的整体调度模型有完整评估时再去碰它。6. 实战排查线程相关经典问题与调试技巧6.1 线程资源泄漏进程内存一步步涨上去这是高并发服务最典型的夜间监控告警。进程内存持续上涨重启后回落过一段时间又涨。最常见的元凶就是线程创建了却没有 join也没有 detach。系统为每个线程保留栈、线程相关的内核数据结构。线程退出了如果没有 join这部分资源就残留着。排查方法很简单用/proc文件系统看现场cat /proc/pid/status | grep Threads线程数量异常高基本坐实了泄漏嫌疑。再结合代码审计看所有pthread_create的返回路径是不是每个分支都保证最终 join 或 detach。建议尽早给每个线程起名字用pthread_setname_np设置线程名之后用ps -eLf或者top -H能看到是哪个线程排查效率直接提升一个档次。6.2 死锁的排查gdb 直接看现场如果程序卡住不动CPU 占用不高大概率就是死锁。用 gdb 附加到进程上可以看现场gdb -p pid (gdb) thread apply all bt这个命令会打出所有线程的调用栈。如果多个线程都卡在pthread_mutex_lock那基本就锁死在互斥锁上了。配合pthread_mutex_t的地址对照源码看每个线程在哪把锁上排队就能还原出循环等待的关系。我有时候还会用一个小技巧在每个加锁点位写日志。比如锁之前打印尝试锁 A拿到锁打印拿到锁 A这样死锁后翻日志就知道大家各自卡在哪把锁上。这个方法虽然俗但很多诡异问题靠它就是比 gdb 更快定位。6.3 数据竞争检查用专门工具做静态排查光靠肉眼找数据竞争就像大海捞针。正因如此我才反复强调同一把锁保护同一个变量的纪律。如果你已经怀疑有数据竞争可以用 ThreadSanitizer 或者 helgrind 这类工具扫描。ThreadSanitizer 用起来非常省事编译时加个参数就行gcc -fsanitizethread -g -O1 -o demo demo.c -pthread跑一遍程序如果存在数据竞争它会直接报告访问冲突的代码位置和两个线程的调用栈。我把它当成多线程程序的语法检查器来用——虽然不知道具体哪一行有错但跑一遍就能告诉我哪里可疑。这类工具虽然会占用一些运行时开销但为了抓出潜在的竞态bug这点代价非常值。尤其是代码经过重构后更应该跑一次。6.4 段错误与栈溢出先看栈再查空指针多线程程序出现段错误很多人第一反应是有空指针。但如果是栈溢出你也能看到段错误而且栈信息往往不完整函数调用链被破坏。处理这种问题我的排查顺序是先用 gdb 看是不是在函数入口或局部数组附近崩的再看调用的栈深度最后检查局部对象的尺寸。必要的时候还可以临时调大线程栈看问题是不是就消失了。另外一个经常被忽视的点是线程入口函数的局部变量别太大。我在重构旧系统时见过有人在线程函数里直接定义了char buf[1024 * 1024]这种写法在默认栈上勉强能活但线程池场景下栈一旦被调小立马崩。6.5 常用线程排查问题速查表现象可能原因快速处理进程线程数持续上涨线程未 join 也未 detach检查创建路径确保每个线程都被回收程序卡死CPU 不高死锁或条件变量等待gdb 附加查看所有线程调用栈偶发段错误栈溢出或数据竞争调大栈/用 sanitizer 检查同一份数据结果时对时错共享数据未统一加锁检查所有访问路径是否都有锁保护取消线程后锁没释放缺少清理函数用pthread_cleanup_push收尾线程创建失败返回 EAGAIN线程数超限或资源不足ulimit -u查看限制检查系统线程数7. 最后再聊聊我对线程控制的一些体会在实际写代码这几年我对线程控制的感受就是它不属于那种学一次就会的知识而是需要你不断在真实的并发环境里摔打才能真正建立起肌肉记忆。很多东西比如条件变量用while而不是if、线程资源必须有人回收、加锁顺序必须全局统一这些规则我一开始也觉得繁琐。直到线上出过几次事故压了一晚上定位才明白每一条背后都是前辈用血泪换来的。如果你现在正准备写自己的第一个多线程程序我的建议是从最小模型开始先写一个创建加 join 的程序确认基础流程没问题再逐步引入 detach、cancel、同步原语。一次只引入一个新的控制特性并且每加一个特性都跑一遍验证。多线程不像单线程那样可以边写边猜它需要你对每个控制原语的行为边界有清晰的预期不然排错的时候会让你怀疑人生。线程控制相关的 API 就那些真正值钱的不是接口本身而是你理解每个接口在什么场景下该用、什么场景下绝对不能用的那层判断力。把这层判断力练出来你写的多线程代码会从能跑进化到敢删注释也敢上线的水平。
C语言多线程控制实战：从创建到销毁的完整指南
1. 线程控制到底控制什么——先理清核心概念很多朋友对线程的印象就是程序里能并发的代码段但真到了写多线程程序的时候往往一脸懵为什么我的线程消失了为什么的资源没释放为什么一跑就崩这些问题的根源基本都出在线程控制这个环节。线程控制简单来说就是对线程生命周期和运行行为的管理。包括创建线程、让线程退出、等待线程结束、分离线程、取消线程、控制线程的同步与互斥以及对线程运行时的栈大小、调度策略、局部存储这些底层属性做设置。你把这些控制点搞明白了多线程的坑基本能填掉一大半。这块内容在不同的系统上实现有差异但思路是通用的。下面我以C语言加POSIX线程库pthread为主线来讲因为它是事实上的标准而且在Linux服务器开发里用得最多。Windows上有类似的一套API思路完全可以平移。写这类东西如果不实操很容易变成背概念。所以我后文会穿插完整的可运行代码和调试手法尽量让刚接触线程的朋友也能边读边跟着做一遍。2. 线程创建与退出影响性能与稳定性的第一道关卡2.1 创建线程前必须回答的三个问题创建线程看起来就是调一个pthread_create但实际工程里你动手敲代码之前得先想清楚三件事线程要干什么、干完怎么退出、谁来回收它的资源。先说第一件事。线程的入口函数就是它运行的灵魂它通常长这样void *worker(void *arg) { // 业务逻辑 return NULL; }注意这个函数签名返回void *且只接收一个void *参数。很多新人会在这里栽跟头——你想传多个参数进去结果发现函数只能收一个指针。解决办法也很粗暴但很实用定义一个结构体把要传的参数打包进去再把这个结构体指针传进去。这是业界最常见的传参方式别嫌麻烦它比传一堆全局变量要安全得多。第二个问题线程干完活怎么退出。正确姿势有三条路让入口函数正常return调用pthread_exit或者被其他线程pthread_cancel掉。这里最容易被忽略的是不要用exit退出线程。exit是终止整个进程的你线程一调exit兄弟线程全都玩完。第三个问题很关键谁来回收它。线程的资源不会因为你那个函数返回了就自动清理干净它需要有人去收尸。收尸的动作就是pthread_join。谁创建的线程通常就应该由谁来负责 join 回收这是保证资源不泄漏的基础纪律。2.2 创建、等待线程的代码模板我直接给出一段最小可用的模板顺序和细节都是验证过的#include pthread.h #include stdio.h #include stdlib.h #include string.h typedef struct { int id; char name[64]; } task_t; void *worker(void *arg) { task_t *t (task_t *)arg; printf(worker [%d] name%s running\n, t-id, t-name); // 模拟业务处理 for (int i 0; i 3; i) { printf(worker [%d] step %d\n, t-id, i); } return (void *)0; } int main(void) { pthread_t tid; task_t t {.id 1, .name demo}; int rc pthread_create(tid, NULL, worker, t); if (rc ! 0) { fprintf(stderr, create failed: %d\n, rc); exit(EXIT_FAILURE); } // 等待线程结束并回收 void *retval NULL; pthread_join(tid, retval); printf(main: join done\n); return 0; }编译时一定记得链接 pthread 库gcc -Wall -O2 -o demo demo.c -pthread跑一下你就能看到主线程阻塞在pthread_join那里直到 worker 执行完才继续往下走。这就是等待线程结束的标准语义。2.3 返回值传递的两种姿势pthread_join的第二个参数能拿到线程的返回值。线程返回值主要有两种传递方式第一种直接返回数字比如返回错误码void *worker(void *arg) { // 干点活 return (void *)42; // 被 join 后打印为 42 }第二种返回堆上分配的结构指针。因为主线程侧pthread_join只是收一个地址线程函数返回的地址必须保证线程退出之后依然有效通常就得上堆void *worker(void *arg) { task_t *result malloc(sizeof(task_t)); ... return result; // 主线程拿到后用完 free }如果你是新手我不推荐一上来就用第二种方式除非你明确知道这块内存谁来释放。工程里我见过太多因为线程返回堆指针导致的内存泄漏和 double free这比简单返回一个数值要容易出错得多。3. 线程分离与取消两种容易看似正确的危险操作3.1 pthreat_detach 到底干什么pthread_detach是另一个让人误用的接口。它做的事情是把当前线程标记为分离状态。分离之后线程结束时系统会自动回收它的资源不需要你再调用pthread_join。这么看分离状态是不是很省事省事是省事但代价是你永远不知道它什么时候结束也拿不到它的返回值。pthread_join还能阻塞等待结果pthread_detach一分离线程就跟脱缰的野马一样与你再无关联。我推荐的实际策略是工作线程如果是一次性任务跑完就走而且你不需要它的执行结果那就用分离模式避免主线程频繁 join 等待拖慢整体节奏。但如果是需要收集结果的并行计算任务就必须用 join 模式别偷懒。有个细节大家要记住默认创建出来的线程是可结合的也就是说你如果不调 detach那就必须有一个对应的 join否则这个线程的资源会一直挂着。这是线程资源泄漏的最常见场景。3.2 pthread_cancel 真的能把线程停下来吗很多需求是希望某个线程马上停止工作。C 里对应的接口是pthread_cancel。但我要很严肃地告诉你pthread_cancel默认情况下不是立即终止线程的。POSIX 线程的取消机制分为两个控制点一个叫取消状态一个叫取消类型。默认情况下线程的取消类型是延时取消意思是你调用pthread_cancel后目标线程并不会马上死掉只有当它执行到某个取消点时才响应取消。取消点基本都发生在系统调用上比如read、write、sleep这类函数。这就导致一个经典问题如果线程在做一个很重的纯计算循环中间没有任何系统调用你pthread_cancel它根本没用。它在那个循环里跑得飞起对你的取消请求视而不见。想要更暴力一点的取消需要打开异步取消类型pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);但我不推荐这么用因为异步取消可能在任何指令处中断线程资源清理、锁释放根本没机会执行结果就是死锁或者数据不一致。3.3 取消清理函数的正确写法既然取消会中断线程线程函数里持有的锁、分配的内存怎么释放POSIX 提供了清理函数void cleanup(void *arg) { // 释放锁、释放内存 printf(cleanup: %s\n, (char *)arg); } void *worker(void *arg) { pthread_cleanup_push(cleanup, cleaning up); // 业务逻辑 pthread_cleanup_pop(1); // 1 表示执行清理函数 return NULL; }pthread_cleanup_push和pthread_cleanup_pop必须配对出现否则编译不过。如果线程因为pthread_cancel被终止系统会先执行 cleanup 里的代码再结束线程。如果正常返回pthread_cleanup_pop也能手动触发清理。这个机制的核心思想是无论线程是怎么死的都要给它一个临终清理的机会。就像一个人不管怎么离开岗位交接工作得做完。4. 线程同步控制互斥锁与条件变量的工程用法4.1 互斥锁不是加锁那么简单多线程一共享数据互斥锁就躲不掉了。但我在代码评审里见过太多人把它用成程序不会崩就行的程度。比如这个典型的加锁代码pthread_mutex_lock(lock); if (shared_value 0) { shared_value--; } pthread_mutex_unlock(lock);逻辑没错但隐藏问题在于如果shared_value的访问姿势不统一——有的地方加了锁有的地方忘了加——那锁就等于白加。数据竞争是隐形的不一定会立刻崩但跑在极端情况下它就会给你表演不可能发生的事。我在实际项目中的原则是凡是跨线程访问的变量访问路径必须在同一把锁的保护下。所谓同一把锁指的是同一个pthread_mutex_t对象。并且要养成习惯加锁代码块的粒度尽量小锁内只做该做的事别把耗时的 IO 操作都包进去。来看一个相对完整的账户操作例子pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; int balance 100; void *atm_withdraw(void *arg) { int amount *(int *)arg; pthread_mutex_lock(lock); if (balance amount) { // 模拟一些检查校验 balance - amount; printf(withdraw %d, balance %d\n, amount, balance); } else { printf(insufficient balance\n); } pthread_mutex_unlock(lock); return NULL; }这里面锁内没有sleep这类慢操作逻辑干净利落。把需要保护的共享数据访问全部放进去其余东西一律隔离在外。4.2 条件变量等待与通知的正确信令只靠互斥锁做线程同步往往不够因为你可能希望某个条件满足时再继续干活这时候轮询加锁太费劲条件变量就是标准解法。条件变量的经典场景是生产者-消费者模型。生产者往队列里放数据消费者阻塞等待队列非空。消费者这边的代码长这样pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond PTHREAD_COND_INITIALIZER; // 消费者 pthread_mutex_lock(lock); while (queue_empty()) { pthread_cond_wait(cond, lock); } item pop_queue(); pthread_mutex_unlock(lock);注意这里用的是while而不是if。为什么因为条件变量的等待存在虚假唤醒的可能——线程可能在没有收到通知的情况下醒过来。用while重新检查条件能彻底规避这个坑。生产者的唤醒代码pthread_mutex_lock(lock); push_queue(item); pthread_cond_signal(cond); pthread_mutex_unlock(lock);signal唤醒一个等待线程broadcast唤醒全部等待线程。只有一个消费者时用signal就够了但多个消费者争抢同一批任务时用broadcast通常更稳妥因为你难得判断哪一个消费者应该被唤醒。4.3 死锁四个必要条件与一个实用避坑指南死锁这东西做并发开发的一定听过线程 A 持有锁1等待锁2线程 B 持有锁2等待锁1两个线程互相等待谁都不让程序就僵住了。产生死锁的四个必要条件网上讲烂了互斥、持有并等待、不可剥夺、循环等待。我要说点实际的。对付死锁我在工程里最常用也最好使的策略就一条全局约定加锁顺序。比如所有线程必须先拿锁 A再拿锁 B禁止反着来。只要顺序一致循环等待就不会出现。再加两条兜底尽量减小锁的持有时间能用一把锁就别用两把。如果确实需要多把锁可以考虑用pthread_mutex_trylock做试探拿不到第二把锁就放弃第一把回头重试避免陷入互相等待。写代码时容易犯的另一个毛病是忘记解锁。函数里多个分支提前 return锁还握在手里。所以很多开源代码会写成 goto cleanup 的样式统一在出口处解锁。你也可以用这种方式可读性和安全性都好很多。5. 线程局部存储与底层控制细节5.1 线程局部存储为什么比全局变量靠得住全局变量在多线程里是典型的共享数据来源一个线程修改其他线程全受影响。但有些变量天生就该是每个线程各自一份比如线程自己的业务上下文、日志序号、缓存句柄。这种需求用线程局部存储TLS来做最合适。在 C11 或者 POSIX 环境下_Thread_local关键字可以直接声明_Thread_local int thread_error_code 0;每个线程访问的都是自己的一份副本互不干扰。如果要在纯 pthread 环境里动态做 TLS可以用pthread_key_t那套麻烦一点但功能更全。我之所以强调 TLS是因为很多实际问题的根源就是用全局变量偷懒。比如一个线程池里的任务处理函数有人拿全局结构当参数中转站结果多个线程同时覆盖同一个数据程序行为完全随机。用 TLS 替代这类全局数据很多诡异的竞态问题自动就消失了。5.2 栈大小与线程属性设置线程默认栈大小在 Linux 上一般是 8MB 左右。但系统只是给你预留虚拟内存实际占用是按需分配的。可某些场景比如嵌入式环境、高并发线程池8MB 还是太大了。这时候就需要显式设置线程属性中的栈大小。pthread_attr_t attr; pthread_attr_init(attr); pthread_attr_setstacksize(attr, 1024 * 1024); // 1MB pthread_create(tid, attr, worker, arg); pthread_attr_destroy(attr);设置栈大小要考虑栈溢出的风险。递归算法、大数组放栈上尤其危险。我见过的极端案例是某程序把线程栈压到 512KB结果业务里一个 1MB 的局部数组直接把栈怼穿了程序崩得莫名其妙。排查了半天才定位到是栈溢出。这类崩溃往往表现为段错误而且返回地址已经乱掉。所以要给线程栈尺寸留足余量一般建议不低于 1MB除非你能明确算清楚调用深度和局部变量的空间需求。5.3 线程调度优先级尽量不要随便动Linux 的默认线程调度策略是公平调度普通线程之间按照优先级和 CPU 时间去分配。如果你用pthread_setschedparam去改线程的调度策略和优先级小心踩坑。改了优先级未必能跑得更快。调度策略涉及系统负载、CPU 亲和性、实时优先级等多种因素。一个不留神你把某个线程设为SCHED_FIFO实时优先级它不交 CPU其他普通线程就全卡住了。这画面在服务器上出现一次就够你加班排查一周的。我的建议是默认调度策略能满足绝大多数业务需求。只有当你非常清楚实时线程的必要性并且对系统的整体调度模型有完整评估时再去碰它。6. 实战排查线程相关经典问题与调试技巧6.1 线程资源泄漏进程内存一步步涨上去这是高并发服务最典型的夜间监控告警。进程内存持续上涨重启后回落过一段时间又涨。最常见的元凶就是线程创建了却没有 join也没有 detach。系统为每个线程保留栈、线程相关的内核数据结构。线程退出了如果没有 join这部分资源就残留着。排查方法很简单用/proc文件系统看现场cat /proc/pid/status | grep Threads线程数量异常高基本坐实了泄漏嫌疑。再结合代码审计看所有pthread_create的返回路径是不是每个分支都保证最终 join 或 detach。建议尽早给每个线程起名字用pthread_setname_np设置线程名之后用ps -eLf或者top -H能看到是哪个线程排查效率直接提升一个档次。6.2 死锁的排查gdb 直接看现场如果程序卡住不动CPU 占用不高大概率就是死锁。用 gdb 附加到进程上可以看现场gdb -p pid (gdb) thread apply all bt这个命令会打出所有线程的调用栈。如果多个线程都卡在pthread_mutex_lock那基本就锁死在互斥锁上了。配合pthread_mutex_t的地址对照源码看每个线程在哪把锁上排队就能还原出循环等待的关系。我有时候还会用一个小技巧在每个加锁点位写日志。比如锁之前打印尝试锁 A拿到锁打印拿到锁 A这样死锁后翻日志就知道大家各自卡在哪把锁上。这个方法虽然俗但很多诡异问题靠它就是比 gdb 更快定位。6.3 数据竞争检查用专门工具做静态排查光靠肉眼找数据竞争就像大海捞针。正因如此我才反复强调同一把锁保护同一个变量的纪律。如果你已经怀疑有数据竞争可以用 ThreadSanitizer 或者 helgrind 这类工具扫描。ThreadSanitizer 用起来非常省事编译时加个参数就行gcc -fsanitizethread -g -O1 -o demo demo.c -pthread跑一遍程序如果存在数据竞争它会直接报告访问冲突的代码位置和两个线程的调用栈。我把它当成多线程程序的语法检查器来用——虽然不知道具体哪一行有错但跑一遍就能告诉我哪里可疑。这类工具虽然会占用一些运行时开销但为了抓出潜在的竞态bug这点代价非常值。尤其是代码经过重构后更应该跑一次。6.4 段错误与栈溢出先看栈再查空指针多线程程序出现段错误很多人第一反应是有空指针。但如果是栈溢出你也能看到段错误而且栈信息往往不完整函数调用链被破坏。处理这种问题我的排查顺序是先用 gdb 看是不是在函数入口或局部数组附近崩的再看调用的栈深度最后检查局部对象的尺寸。必要的时候还可以临时调大线程栈看问题是不是就消失了。另外一个经常被忽视的点是线程入口函数的局部变量别太大。我在重构旧系统时见过有人在线程函数里直接定义了char buf[1024 * 1024]这种写法在默认栈上勉强能活但线程池场景下栈一旦被调小立马崩。6.5 常用线程排查问题速查表现象可能原因快速处理进程线程数持续上涨线程未 join 也未 detach检查创建路径确保每个线程都被回收程序卡死CPU 不高死锁或条件变量等待gdb 附加查看所有线程调用栈偶发段错误栈溢出或数据竞争调大栈/用 sanitizer 检查同一份数据结果时对时错共享数据未统一加锁检查所有访问路径是否都有锁保护取消线程后锁没释放缺少清理函数用pthread_cleanup_push收尾线程创建失败返回 EAGAIN线程数超限或资源不足ulimit -u查看限制检查系统线程数7. 最后再聊聊我对线程控制的一些体会在实际写代码这几年我对线程控制的感受就是它不属于那种学一次就会的知识而是需要你不断在真实的并发环境里摔打才能真正建立起肌肉记忆。很多东西比如条件变量用while而不是if、线程资源必须有人回收、加锁顺序必须全局统一这些规则我一开始也觉得繁琐。直到线上出过几次事故压了一晚上定位才明白每一条背后都是前辈用血泪换来的。如果你现在正准备写自己的第一个多线程程序我的建议是从最小模型开始先写一个创建加 join 的程序确认基础流程没问题再逐步引入 detach、cancel、同步原语。一次只引入一个新的控制特性并且每加一个特性都跑一遍验证。多线程不像单线程那样可以边写边猜它需要你对每个控制原语的行为边界有清晰的预期不然排错的时候会让你怀疑人生。线程控制相关的 API 就那些真正值钱的不是接口本身而是你理解每个接口在什么场景下该用、什么场景下绝对不能用的那层判断力。把这层判断力练出来你写的多线程代码会从能跑进化到敢删注释也敢上线的水平。
