做Linux服务端开发这些年我身边不少朋友至今还在用多进程架构扛并发。进程当然有进程的好处隔离性漂亮一个子进程崩了不至于拖垮全家。可你一旦把并发量顶上去进程切换的开销、内存隔离带来的数据拷贝、还有进程间通信的那一套管道和共享内存都会变成实打实的负担。这也是我把这个系列的第二章留给线程的原因——在Linux下搞并发线程是你绕不开的工具。这篇文章不是一个简单的“pthread_create怎么用”手册我会把线程的创建、生命周期、同步、条件变量、锁选型、线程安全以及线上调试的思路串成一条线按实际开发中最常见的坑来讲希望对正在从进程模型转向线程模型的读者有直接帮助。1. 线程存在的理由不是图“快”而是避免“白等”1.1 进程模型的三个隐性成本很多人觉得多进程并发跑得好好的为什么非得用线程答案要从进程模型的三笔开销说起。第一笔是上下文切换开销。进程切换时内核需要保存和恢复大量状态包括寄存器、栈指针、程序计数器更要命的是处理TLB和CPU缓存的失效。CPU频率再高也经不起频繁切换带来的缓存冷启动。也许一个线程切换只要几百纳秒的开销看起来不显眼但把时间拉长到高并发场景几万个线程或者进程在几个CPU核心之间抢时间片这个开销就是决定吞吐量的关键因素。第二笔是数据共享成本。两个进程想共享一块内存你得用共享内存、信号量、消息队列这些IPC机制或是通过socket、管道把数据序列化传过去。这些机制都有自己的代价共享内存要做同步socket要拷贝数据序列化还要额外消耗CPU。你本来只想让两个执行单元访问同一个计数器结果为了传递这个计数器代码复杂度翻了好几倍。第三笔是资源占用。每个进程都有独立的地址空间页表、文件描述符表、信号处理表一应俱全。进程一多光维护这些内核数据结构就吃掉不少内存。很多做后台服务的团队进程数量稍微上去内存RSS立刻涨得很凶就是这个原因。1.2 线程的本质共享地址空间的调度单元线程之所以能解决上面这些问题关键在于它和进程的资源分配方式不同。在Linux里线程实际上是“轻量级进程”但同一进程内的多个线程共享地址空间、全局变量、文件描述符和信号处理函数。它们私有的只有栈、寄存器上下文和线程局部存储。这意味着线程之间天然共享数据不需要额外的IPC机制通信成本直接降为“一次内存读写”。不过共享地址空间是把双刃剑。共享带来方便也带来竞争。两个线程同时往同一个变量写数据如果不加同步轻则结果错乱重则直接崩溃。所以线程编程的核心不取决于你会不会创建线程而取决于你是否能驯服共享数据。这也是后面几章要重点展开的内容。对比总结一下维度多进程多线程数据共享需要IPC或共享内存成本高直接共享地址空间成本低上下文切换开销大TLB/缓存易失效开销小同进程线程切换更轻隔离性强一个进程崩溃不影响其他弱一个线程越界可能拖垮进程编程模型并发思路更直接但数据通信绕同步复杂锁和条件变量是必修课所以线程的出现本质上不是为了替代进程而是为了在同一个进程内提供低成本、高共享的并发执行模型。当你的业务需要高并发访问共享状态并且对内存开销敏感时线程是优先选择当系统模块之间需要强隔离、单点崩溃不能牵连全局时进程仍然有不可替代的价值。2. 线程生命周期从pthread_create到销毁每一步都有讲究2.1 创建线程前必须确认的细节Linux下线程接口遵循POSIX标准日常开发用到的是pthread库。最简单的一段创建代码是这样#include pthread.h #include stdio.h void *worker(void *arg) { long id (long)arg; printf(worker %ld running\n, id); return NULL; } int main(void) { pthread_t t; int rc pthread_create(t, NULL, worker, (void *)1L); if (rc ! 0) { // 注意pthread系列接口返回错误码而不是设置errno fprintf(stderr, create failed: %d\n, rc); return 1; } pthread_join(t, NULL); return 0; }编译时别忘了加-pthread否则会链接失败或者出现诡异的行为。我见过不少人在编译脚本里漏掉这个选项然后某天在特定发行版上突然报“undefined reference to pthread_create”。创建时的四个参数分开讲pthread_t *thread线程标识符类似进程的PID但它是进程内唯一的只在创建它的进程内有意义。pthread_attr_t *attr线程属性一般传NULL用默认值。需要自定义栈大小、调度策略、继承属性等时才显式设置。void *(*start_routine)(void *)线程入口函数返回值是一个void *可以给到其他线程比如通过pthread_join拿回线程的退出结果。void *arg传给入口函数的参数。这里有个非常隐蔽的坑入口函数的参数类型是void *你如果直接把一个栈变量地址传进去然后立刻退出作用域线程还没开始跑变量已经失效了。更常见的错误是传整型变量时直接转成指针for (int i 0; i 5; i) { pthread_create(tid[i], NULL, worker, (void *)i); // 错误示例 }这段代码的问题是五个线程拿到的可能全是同一个地址当线程真正解引用的时候i已经跑到4或者5了。正确做法是给每个线程单独分配一块内存保存参数或者直接传整数类型的值前提是类型能放进void *里for (int i 0; i 5; i) { ids[i] i; pthread_create(tid[i], NULL, worker, ids[i]); }如果你传参比较频繁建议用数组预分配而不是在线程里malloc再free这样可以少一层内存管理的开销。2.2 join、detach以及线程资源回收的纪律线程创建之后它的生命周期有三种常见走向可汇合joinable默认状态。线程结束后内核会保留它的退出状态和回收信息。创建者必须调用pthread_join去回收否则线程就成了“僵尸线程”持续占用资源。分离detached线程结束后由系统自动回收资源不需要也不允许再pthread_join。通过pthread_detach(tid)或者在线程内部调用pthread_detach(pthread_self())实现。取消cancelled另一个线程调用pthread_cancel(tid)请求取消目标线程。目标线程是否立刻响应取决于取消点和取消状态设置。一句话纪律创建的线程要么尽快join要么尽早detach不要让它悬在中间状态。这个和文件句柄要关闭是一个道理资源不回收时间长了必出问题。pthread_join还有另一个常见用途等待多个线程完成任务后做汇总。类似进程里的waitpid它也能拿到线程的返回值。比如void *result_buf; pthread_join(tid[i], result_buf);这时result_buf就是线程入口函数的返回值指针。注意别把它指向线程栈上的局部变量线程退出后栈就被回收了拿到的是悬垂指针。2.3 设置线程栈大小默认值并不总是够用线程属性设置里栈大小是容易被忽略的一项。默认栈大小一般是8MB受ulimit -s影响对大多数场景足够但如果你的业务会在线程里做深递归或者分配大量栈上结构体8MB可能不够需要手动调大。另一种相反的情况如果你的并发线程数量非常多成千上万每线程8MB会直接吃光内存这时候要刻意调小栈大小配合线程池使用。设置栈大小的代码模式#include pthread.h pthread_attr_t attr; pthread_attr_init(attr); size_t stack_size; pthread_attr_getstacksize(attr, stack_size); // 先看默认值 pthread_attr_setstacksize(attr, 16L * 1024 * 1024); // 16MB pthread_t t; pthread_create(t, attr, worker, NULL); pthread_attr_destroy(attr);我见过一个案例某后台服务把线程栈调得特别大结果并发高峰期内存直接翻倍。后面用pthread_attr_setstacksize精确设置了64KB到256KB内存占用瞬间降下来但前提是你要非常确定每个线程不需要更大的栈。不要盲目调小否则段错误出现在递归深处时连栈回溯都是灾难。3. 线程同步第一课互斥锁的正确用法3.1 锁初始化静态和动态区别不止在语法互斥锁是所有线程同步的基础。Linux下的pthread_mutex_t有两种初始化方式pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; // 静态初始化或pthread_mutex_t lock; pthread_mutex_init(lock, NULL); // 动态初始化静态初始化不需要销毁动态初始化则需要配对pthread_mutex_destroy。两者在实际功能上几乎没有差别但动态初始化可以传属性典型案例是递归锁pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_settype(attr, PTHREAD_MUTEX_RECURSIVE); pthread_mutex_init(lock, attr); pthread_mutexattr_destroy(attr);递归锁允许同一个线程多次加锁不会自锁。听起来很方便但我建议不要依赖它。递归锁往往掩盖了“设计上不应该重入”的坏味道后面想改成读写锁或者无锁方案的时候处处受制。3.2 lock、trylock、timedlock什么时候用哪个加锁最常见的就是pthread_mutex_lock这是阻塞式。当锁被其他线程持有时调用线程会阻塞在等待队列里CPU让出去不做无用功。对大部分同步场景用它就对了。pthread_mutex_trylock是非阻塞的拿不到锁就立刻返回EBUSY。它的典型用途是实现“有锁就干没锁就走”的跳过式逻辑比如缓存更新场景一个线程尝试更新缓存如果另一个线程正在更新这个线程就放弃本次更新等下一轮再试。但是请谨慎使用“trylock 循环重试”的组合那相当于拿着CPU去死磕锁浪费严重。如果预期等待时间不确定应改用阻塞式加锁。pthread_mutex_timedlock可以设置最长等待时间超过时间返回ETIMEDOUT。它适合那些“拿不到锁就放弃做别的事”的业务逻辑。不过现实使用中超时时间设置很敏感太短会导致活锁太慢又起不到限制作用。线上业务如果没有特殊需求我一般偏向用阻塞锁。3.3 临界区要尽量短这是锁设计的第一原则锁本身不产生性能问题产生问题的是临界区的长度。拿一个典型场景举例线程要读取共享配置再加锁后去访问数据库再把结果写回共享变量。如果你把数据库查询放在锁里其他线程全部被堵住锁竞争立刻放大。正确做法是先不加锁查数据库拿到结果后加锁只做“结果写入共享变量”这一小段操作。我总结一个习惯加锁之后只做内存读写和极短逻辑凡是可能阻塞的IO、网络读写、大段计算统统移出临界区。之所以这么强调是因为线上出现的性能尖刺十有八九不是锁竞争本身而是临界区里塞了不该有的操作。3.4 防止数据竞争千万不要低估一条简单赋值语句很多人觉得“赋值嘛我就count一下能出什么问题”。在单线程里没问题多线程下就是典型的读-改-写竞争。count在底层是至少三条指令读内存到寄存器、寄存器加一、写回内存。两个线程同时执行可能都读到了同一个旧值再分别写回最终结果比预期少一次。这种问题不崩溃但结果不对而且和调度时序强相关最难排查。解决方式有两种一是加互斥锁二是使用原子操作。原子操作在下一章展开这里先说锁。程序员必须建立“任何非原子操作在多线程下都可能被切碎”的底线意识变量、指针、结构体字段全都在此范围。4. 条件变量生产者和消费者之间的“敲门机制”4.1 为什么不能只靠锁来等待互斥锁能保护共享数据但解决不了“等待某个条件成立”的问题。经典的场景是生产者-消费者消费者要等队列里出现数据才能消费如果用锁消费者只能不断加锁-查看队列-解锁-再循环这个循环很浪费CPU而且队列为空时的轮询延迟非常不稳定。条件变量就是为这个设计线程可以进入阻塞状态直到另一个线程发出“条件已经满足”的通知。条件变量必须和互斥锁配套使用原因在于判断条件和修改条件之间必然存在竞态。如果没有锁保护线程A判断队列为空后准备sleep这时线程B往里放了数据并发出信号等A真正sleep时信号已经过去了A会一直睡下去。这道“丢失唤醒”问题只能靠先把锁拿住再判断条件来解决。4.2 一个标准的等待/通知模式条件变量的核心接口是pthread_cond_wait和pthread_cond_signal一个典型的消费者等待逻辑是这样pthread_mutex_lock(lock); while (queue_is_empty(q)) { pthread_cond_wait(cond, lock); } // 此时条件成立队列有数据 consume_one(q); pthread_mutex_unlock(lock);pthread_cond_wait做的事情需要仔细理解它先把调用线程挂到条件变量的等待队列上然后原子地释放互斥锁进入睡眠等被唤醒时它会重新获取互斥锁然后返回。所以调用时你必须已经把锁握在手里。这里有一个需要特别注意的点判断条件要用while而不是if。因为Linux下的条件变量存在虚假唤醒的可能也就是没有signal也可能被系统唤醒。即使你使用的是严谨的signal多个消费者被同时唤醒后其中一个抢先把数据消费掉另一个醒来看条件也可能不成立。如果用if醒来的线程会直接消费空数据用while则能重新回到等待状态。生产者一侧对应的逻辑是pthread_mutex_lock(lock); push_to_queue(q); pthread_mutex_unlock(lock); pthread_cond_signal(cond);4.3 先解锁再signal还是先signal再解锁顺序上有两种写法效果存在微妙差异。先解锁再通知pthread_mutex_unlock(lock); pthread_cond_signal(cond);这种写法消费者在pthread_cond_wait返回后会重新竞争锁虽然signal之后立即解锁会让唤醒的线程少等一个锁的获取但实际上因为等待队列唤醒和锁调度的顺序两者差异不大。比较推荐的是“解锁后再signal”因为持有锁去signal会造成当前线程和消费者产生锁竞争个别场景下性能会有几个百分点的损失。4.4 生产者-消费者完整示例我直接给一个基于数组环形队列的示例这段代码可以拿来跑通流程#include pthread.h #include stdio.h #define CAPACITY 16 int buf[CAPACITY]; int head 0, tail 0, count 0; pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; pthread_cond_t not_full PTHREAD_COND_INITIALIZER; pthread_cond_t not_empty PTHREAD_COND_INITIALIZER; void produce(int val) { pthread_mutex_lock(lock); while (count CAPACITY) { pthread_cond_wait(not_full, lock); } buf[tail] val; tail (tail 1) % CAPACITY; count; pthread_cond_signal(not_empty); pthread_mutex_unlock(lock); } int consume(void) { pthread_mutex_lock(lock); while (count 0) { pthread_cond_wait(not_empty, lock); } int val buf[head]; head (head 1) % CAPACITY; count--; pthread_cond_signal(not_full); pthread_mutex_unlock(lock); return val; } void *producer(void *arg) { for (int i 0; i 1000; i) { produce(i); } return NULL; } void *consumer(void *arg) { for (int i 0; i 1000; i) { consume(); } return NULL; } int main(void) { pthread_t p1, p2, c1, c2; pthread_create(p1, NULL, producer, NULL); pthread_create(p2, NULL, producer, NULL); pthread_create(c1, NULL, consumer, NULL); pthread_create(c2, NULL, consumer, NULL); pthread_join(p1, NULL); pthread_join(p2, NULL); pthread_join(c1, NULL); pthread_join(c2, NULL); return 0; }这个模型里一个not_full条件变量用来等待“缓冲区有空位”一个not_empty等待“缓冲区有数据”。用两个条件变量而不是一个能减少无效唤醒也避免生产者和消费者互相踩踏。这种“双条件变量”的设计在生产场景中很实用我做消息队列模块时基本都是这个骨架。5. 不同锁的取舍读写锁、自旋锁和原子操作5.1 三种同步方案到底什么时候用谁互斥锁适合绝大多数场景但不是说所有场景都要用它。业务代码里还存在两类特殊分布读多写少、或者临界区极短。这时直接上互斥锁会把并发优势抹掉。读写锁pthread_rwlock_t允许多个读者同时进入临界区只在写者持锁时排斥所有人。它适合配置表、路由表、新闻缓存这类“查多改少”的数据结构。一个容易踩的坑是写者饥饿如果读者来得特别密写者可能一直等不到机会。部分实现支持写者优先属性比如用pthread_rwlockattr_setkind_np设置PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP但不同系统的行为不完全一致跨平台要仔细评估。自旋锁pthread_spinlock_t拿不到锁时不会睡眠而是原地旋转等待那部分CPU对外表现为“空转”。它只适合临界区极其短、且不会发生阻塞的场景比如“重置一个标志位”“交换两个指针”。只要在临界区里出现系统调用或者复杂计算自旋锁就会造成大量CPU浪费。多核场景用自旋锁可以单核场景基本没意义旋转时其他线程也得不到时间片。做个对比表方便决策锁类型等待方式适合场景不适用场景互斥锁阻塞睡眠让出CPU大多数共享资源保护读多写少、临界区太长也无优势读写锁读者并发写者独占读多写少写太频繁公众号热点反而更差自旋锁CPU空转等待临界区极短临界区内有IO、系统调用、长循环原子操作无锁硬件指令保证计数器、标志位复杂数据结构更新5.2 原子操作比自旋锁更轻量的护身符当目标只是一个计数器或者一个状态标志用互斥锁都有些小题大做C11提供的原子接口或者GCC内置原子函数是更好的选择。性能上原子操作在x86上往往就是一条带lock前缀的指令没有系统调用也没有锁唤醒。例子#include stdatomic.h atomic_int count 0; atomic_fetch_add(count, 1);或者用GCC风格__sync_add_and_fetch(count, 1);原子操作最大的坑在于它只能保护单个内存位置的读写一旦要“先读多个变量再决定更新某一变量”这种复杂不变量原子操作就无能为力了必须回到锁或者使用无锁数据结构。无锁数据结构门槛很高日常业务优先用锁只有那些热路径的性能敏感点才值得引入原子操作。6. 线程安全的隐形地雷可重入函数、errno和线程局部存储6.1 “线程安全”和“可重入”不是一回事不少文档会混用这两者实际含义有区别。线程安全是指多个线程并发调用这个函数依然正确可重入是指即使同一个线程在函数执行到一半时因为信号处理函数再次进入该函数仍然正确。前者是锁能解决的后者要求函数内部不能使用静态数据和全局数据。C标准库里的老牌函数许多都不是线程安全的典型代表非线程安全版本线程安全替代strtokstrtok_rlocaltimelocaltime_rrandrand_rgetenv不能替代需自行加锁以strtok为例它内部用一个静态变量记住剩余字符串的位置。两个线程同时调用这个静态变量互相覆盖解析结果必然错乱。换用strtok_r把状态保存在调用方提供的缓冲区里就线程安全了。写多线程程序时编译阶段如果开-Wpthread相关警告部分编译器能帮你找出来但更多时候还是得靠代码审查。6.2 你以为安全的errno其实也是全局状态很多人写多线程代码时不注意errno这个变量看似全局其实在现代Linux的glibc里被实现为线程局部存储。也就是说每个线程都有自己的errno线程A调用系统调用失败设置了errno不会影响线程B的errno。这是好事但如果你自己封装函数并返回errno记得要先保存原值更不要在自己定义的错误码里直接用errno作为长期标记。我的建议是每条线程的入口函数开头就做一次errno归属确认然后在线程函数里尽量少依赖errno而是直接检查系统调用的返回值并立刻处理。这样跨平台移植时也不容易踩坑。6.3 线程局部存储当你需要线程私有的全局变量线程安全问题的根源就是共享但有时候你确实需要一个“看起来是全局但实际上每个线程各存一份”的变量。比如日志模块希望每个线程单独缓存一段日志缓冲区避免大锁竞争。__thread关键字可以做到__thread char thread_log_buf[1024];或者C11里的_Thread_local。需要注意的是__thread变量不能用于所有类型构造和析构规则比较复杂比如含有非平凡构造函数的C对象就不能直接用。C里建议用thread_local标准语法底层同样是TLS机制但语义更规范。线程局部存储的另一个典型用途是线程专用的随机数种子__thread unsigned int rand_seed; // 每个线程独立设置rand_seed的值这样比全局用一个锁去保护随机数状态要高效得多。我常跟新人说一句话能用TLS解决的问题不要设计成锁保护全局变量。锁竞争是并发编程最大的隐性性能杀手而TLS从根上避免了竞争。7. 排查线程问题的实操经验死锁、竞态和压测7.1 死锁的四条铁律和加锁顺序原则死锁要同时满足四个条件互斥、持有并等待、不可抢占、循环等待。工程上最容易出现的是“循环等待”也就是锁的顺序不一致。比如线程1先拿锁A再拿锁B线程2先拿锁B再拿锁A双方就可能互相卡死。解决循环等待的通用做法是全局统一锁顺序所有线程都按同样的顺序加锁比如约定“先锁数据表再锁缓存”。这个规则写进代码评审清单比事后排查高效得多。如果锁多到难以维护顺序优先考虑用一把大锁保护局部共享再逐步拆细。7.2 gdb定位死锁的完整链路死锁问题常见表现是程序卡住线上排查大概按这个顺序来先找到卡住的进程PID然后用gdb附加gdb -p pid (gdb) info threads看看有多少线程、各自的状态。随后把每个线程的栈全部打出来(gdb) thread apply all bt重点看处于pthread_cond_wait、pthread_mutex_lock或futex系统调用上的线程。如果两个线程都阻塞在互斥锁上并且一个握着的锁是另一个想要的基本就锁死。再看栈帧里函数名基本能定位到加锁的代码行。还有一招是用strace看系统调用卡在哪里strace -p pid -f -e tracefutex卡在futex等待上反复打印同一个地址大概率就是锁竞争的现场。7.3 竞态问题为什么最难复现竞态不卡程序但结果不对。这类问题线上很难复现常见手段有三个层次第一层压测时放大线程并发数把竞态窗口拉大。比如原本32线程出问题改成128线程或256线程更容易触发。第二层用线程消毒器检测。GCC和Clang都支持-fsanitizethread编译时加上跑一遍测试它会输出发生数据竞争的具体行号。缺点是这个模式会大幅降低性能不适合线上。第三层用valgrind --toolhelgrind做更细致的锁和条件变量分析。Helgrind能检测到“加锁顺序不一致”这类潜在死锁风险但同样很慢只在测试环境用。实战中我比较依赖第一层——高并发压测加日志。先在可疑共享变量的读写处加一行带时间戳的日志触发问题后通过日志排序找出交错时序。等精确到代码行以后再用线程消毒器去验证。7.4 线上突发卡顿一个可复用的诊断思路服务线上突然表现为请求处理变慢但进程还活着这种时候先别急着加锁或者改线程数。我先用top -H -p pid查看每个线程的CPU占用如果某些线程长期占用100%而业务日志没有相应输出多半是死循环如果所有线程都处于很低CPU但请求堆住了多半是锁等待或者条件变量丢失唤醒。随后用gdb附加到进程thread apply all bt全量打栈。假如看到大量线程阻塞在同一个pthread_mutex_lock上而持有锁的线程栈里卡在read、write或sleep问题就清楚了临界区里做了阻塞操作。这时把阻塞操作移出临界区或者在设计上改为“先拷贝需要的数据再释放锁再做IO”基本能解决。这套诊断顺序我在好几个项目里验证过普适性很强。先看CPU分布再看线程栈最后根据阻塞点锁定临界区问题。8. 最后再分享几个写线程代码的习惯在线程设计上我想单独说三个容易被低估的点。第一个习惯是优先考虑线程池而不是每来一个任务就创建线程。线程创建和销毁的开销虽然比进程小但高并发下频繁创建销毁依然不划算。线程池的核心参数就是最小线程数、最大线程数、任务队列容量。最小线程数决定低峰时的响应度最大线程数决定能扛的峰值队列容量决定背压表现。总原则是线程数不要超过“机器的CPU核数 × 线程等待占比系数”具体系数要根据业务实测调。第二个习惯是正确对待锁的边界。不要因为害怕锁竞争就到处用读写锁和原子操作也不要什么都加到同一个锁上。最稳的做法是优先保证正确用互斥锁保护明确的不变量然后再通过压测观察锁竞争锁竞争高到影响性能时再做优化。过早优化锁往往引入难以察觉的竞态。第三个习惯是永远在退出路径上做资源释放。线程加锁之后不管函数是在中间return还是在收尾goto都要保证解锁。简洁做法是用pthread_cleanup_push和pthread_cleanup_pop注册清理函数在线程被取消时自动执行pthread_cleanup_push((void (*)(void *))pthread_mutex_unlock, (void *)lock); // 临界区代码 pthread_cleanup_pop(1); // 需要把POP带上参数1表示立即执行清理函数不止锁线程退出时的堆内存、文件描述符、临时文件都要成为“清理清单”的一员。线程不像进程崩了会把整个进程拖下水资源泄漏也不会被系统回收。这个系列写到这里线程的框架基本齐了。每篇文章讲的内容都不浮于语法而是我踩过、看过、测试过之后的真实心得。下一篇文章我会聊聊Linux下的异步IO和事件驱动模型把线程和事件循环搭配起来那才是高并发架构真正的主场。如果这篇文章能帮你少加几夜班、少烧几颗CPU我就觉得值了。