带新人做并发下载器的时候我第一次认真思考线程和进程的关系。当时负责的是一个内网文件分发工具早期版本用多进程并行下载每个文件起一个子进程内网千兆环境实测效果还行但进程一多内存占用立刻变得难看。后来换成多线程方案同一批任务的耗时几乎不变内存却降了将近一半。也就是从那次之后我对Linux下线程的理解不再停留在理论层面而是真正从踩坑中补完了整套认知。这篇笔记更像是我自己系统编程经验的沉淀聚焦一件事线程到底是什么、线程之间怎么协同、哪些坑是新手很容易踩的。无论你是刚从多进程转过来的还是刚开始接触pthread系列接口这篇的内容应该都能帮你理顺思路。我会尽量少写那种“教科书式定义”多用实际场景和代码来说明。1. 线程的本质为什么说它是调度的最小单位1.1 一个进程内部藏着一组独立执行的“线”Linux下所谓“进程”有个很直观的比喻它是资源的集合体拥有独立的地址空间、文件描述符表、信号处理方式、当前工作目录等。而线程则是这个集合体里的执行流。进程给了线程生存所需的全部资源线程则负责真正去跑代码。教科书里常用的定义是线程是CPU调度的最小单位。这句话展开说就是——从内核视角看参与排队等CPU的实体其实是线程而不是进程。进程本身更像是“装线程的容器”容器里的每个线程可以独立被调度到某个CPU核心上运行。所以你会看到在多核机器上一个进程内的两个线程可以同时跑在两个核上这并不奇怪。这里有个隐藏的知识点常被忽略线程控制块TCB。进程有进程控制块PCB线程同样有内核里登记自己信息的结构。TCB里至少包含线程ID、调度优先级、寄存器上下文、内核栈等。寄存器上下文就是线程被换下CPU时要保存的现场比如PC指针、栈指针、通用寄存器的值。内核靠TCB恢复这些值才能让线程接着上次的位置继续执行。对比一下进程和线程的组成能更直观看到私有的和共享的部分线程私有进程内线程共享线程ID地址空间代码段、数据段、堆程序计数器PC全局变量寄存器集合打开的文件描述符线程栈信号处理方式errno当前工作目录线程局部存储TLS用户ID、组ID1.2 私有存储区每个线程手里都攥着自己的记账本热搜词里出现了一个高频问题“线程控制块和私有存储区的关系”。好多人学线程时被这个卡住。我这样类比过进程就像一家公司线程就是公司里的员工。员工共享公司的办公室、会议室、资料库但每个人自己手里有一本私人的记事本——这就是私有存储区。具体到实现层面一个线程的私有存储区至少包括三块东西第一是线程栈。每个线程有自己的栈空间用来存放函数调用时的局部变量、返回地址、函数参数。多个线程的栈都在进程地址空间中但它们彼此隔离。这也是为什么一个线程栈溢出会直接拖垮整个进程——地址空间已经破了。第二是errno。这是个特别容易踩的隐蔽点。很多标准库函数出错时会设置errno如果所有线程共用同一个errnoA线程调read失败了刚设置完errno还没处理B线程调write又成功了把errno清零A线程再去查就得了个错误结论。所以glibc里有意把errno做成线程私有的宏实际上是通过线程局部存储实现的。第三是线程局部存储TLS。这是程序员能主动控制的私有区间。比如你想在某个线程里暂存一个用户态变量而不被其他线程干扰就可以用__thread修饰全局变量或者更高级地配合pthread_key系列接口来管理。这部分我在第三节再细说。1.3 多线程比多进程“轻”到底轻在哪里这是面试几乎必问的问题也是写代码选型时的关键依据。多线程的“轻”体现在三个层面创建快。fork一个进程要做的事情很多复制页表、复制文件描述符表、处理写时复制的各种标记。而pthread_create创建一个线程主要工作是分配线程栈、初始化TCB和寄存器上下文不需要复制整套地址空间。切换快。进程切换要切换地址空间这意味着页表切换和缓存失效线程切换只切换寄存器上下文和栈指针同一进程内的地址空间保持不变缓存命中率更高。通信成本低。进程间通信要借助管道、消息队列、共享内存等机制每次都要陷入内核或者做显式的同步线程之间本来就在同一地址空间共享全局变量就能传数据配合锁或原子操作即可。但必须说清楚轻不是免费的。共享同一份地址空间也意味着一个线程越界写坏堆区整个进程都可能崩溃。多进程至少还能用退出码告诉你哪个子进程出了问题多线程出了问题通常就是段错误加上一份包含所有线程栈的core文件排查起来更考验功夫。2. 线程的创建与退出规范写法和必须避开的传参坑2.1 pthread_create比想象中多一倍参数的入口在线程这块我们用的最多的就是POSIX线程接口一般写法是#include pthread.h #include stdio.h void* worker(void* arg) { int id *(int*)arg; printf(thread %d start\n, id); return NULL; } int main(void) { pthread_t tid[4]; for (int i 0; i 4; i) { pthread_create(tid[i], NULL, worker, i); } for (int i 0; i 4; i) { pthread_join(tid[i], NULL); } return 0; }这个代码是个经典反例因为它把i直接作为参数传给了线程。i是main函数栈上的局部变量循环每次迭代i都在变。线程启动有延迟很可能四个线程真正运行起来的时候i已经变成了3或者4。结果就是打印出两份“thread 3”、重复的数据或者别的诡异现象。正确的传法是给每个线程准备独立的内存单元int ids[4]; for (int i 0; i 4; i) { ids[i] i; pthread_create(tid[i], NULL, worker, ids[i]); }这样每个线程拿到的是不同地址值互不干扰。如果你传的是一个整数值本身而不是指针比如直接把i强转成void*传出去在小整数范围内通常也能用但这种写法依赖“指针宽度足以容纳整数”的假设在交叉编译到嵌入式平台时容易出问题。我个人的习惯是但凡需要传整数就给它分配一块内存在线程函数内部自己拷贝在线程结束后再统一释放。2.2 线程的四种收场方式join、detach、exit和取消线程函数return返回后线程就结束了。但线程结束后它的资源并不会自动完全清理必须有个地方回收它的返回值、释放它的栈空间。这就要用到两个操作pthread_join是阻塞式的主线程会一直等目标线程退出同时取回退出状态。这一点和waitpid很像但有一个显著差异waitpid等待的是子进程而pthread_join等的是“同一进程内的兄弟执行流”。主线程和子线程之间没有父子层级关系任何线程都可以join另一个线程。pthread_detach是把线程设为分离状态分离后的线程结束时会自己释放资源不再需要join。这里有个比较容易犯迷糊的点detach之后不能再对该线程调用join否则可能产生未定义行为甚至直接崩溃。线程还可以主动呼叫pthread_exit终止自己这相当于线程版本的exit。和return有细微差别在线程函数里调用return整个启动线程的函数栈会正常展开但如果你想在主线程里只结束一个线程、其他线程继续跑就可以调用pthread_exit退出main线程本身。这个过程不会影响其他线程进程会等其他线程都结束后才完全退出。还有一类用法是pthread_cancel它请求取消一个线程。默认情况下目标线程会在到达某个取消点比如read、write、sleep等时被终止。这里面坑很多比如取消点到不了线程就永远不会响应比如线程正在持锁时被取消会导致其他线程永久卡死。如果没有充分理由我建议不要用cancel尽量用标志变量让线程自己决定何时退出配合join等待它平安落地。2.3 忽略返回值的人总会在夜深人静时上线排查很多人写pthread_create时不检查返回值觉得只要语法对就不会有事。实际上pthread_create最常见的失败原因是资源不足比如栈空间或线程数量超限。默认情况下进程能创建的线程数受ulimit -u和内存大小约束线程栈默认8MB虚拟内存足够多时数量上限主要是进程数限制。另一个不显眼但实际存在的是EINVAL——如果你手工设置了线程属性比如指定了调度策略或栈地址但参数不合规pthread_create会直接失败。如果代码里不检查主程序会以为线程已经创建成功后续join一个不存在的线程ID行为完全不可控。所以我的习惯是给创建线程的调用包一层工具函数void check_pthread(int rc, const char* msg) { if (rc ! 0) { fprintf(stderr, %s: %s\n, msg, strerror(rc)); exit(EXIT_FAILURE); } }多写这几行不费什么时间却能避免无数现场问题。曾经有个同事把线程创建失败当成业务bug排查了两天最后发现是服务器上运行的服务设置了太低的线程数限制连报错都没看就假设一定创建成功了。工具函数在这种时候能帮你直接给出结论。3. 线程间的消息传递信号、共享变量和私有数据的边界3.1 为什么不能指望kill线程很多从多进程转过来的朋友第一反应是想用“信号”去控制线程。进程之间的信号机制大家都熟kill 信号处理函数。但线程不是进程不能把signal那套直接套过来。线程收到信号后究竟哪个线程来处理取决于信号的发送方式和进程内的线程调度。用pthread_kill可以给指定的线程发信号但这个信号的处理仍然是进程级别的——如果一个线程设置了某个信号的处理函数其他线程也会遵循同样的处理函数如果一个线程修改了信号屏蔽字也只影响自己不影响其他线程。这导致一个很现实的问题你很难用信号精确地指挥某个线程做某件事尤其是多个线程都在跑的时候。信号更像广播而不是点对点通信。想清楚这点就别在业务代码里用信号做线程间的消息传递了。用共享变量加锁或者用条件变量才是线程间通信的正道。表现形式上就是生产者消费者模型、工作队列这些。3.2 条件变量最常用的线程“门铃”下面这个场景每个写线程程序的人都会遇到一个线程要等某个条件满足再继续干活另一个线程负责改变条件。如果只用轮询加sleep要么响应慢要么白白烧CPU。条件变量就是为这种等待而生的。条件变量操作的核心套路非常规律先加锁判断条件不满足就调用pthread_cond_wait这个调用会原子地释放锁并挂起线程被唤醒后重新获取锁再次判断条件。为什么要再次判断因为唤醒可能由多次signal触发也可能因为伪唤醒spurious wakeup被莫名其妙带起来。所以判断条件必须放在循环里pthread_mutex_lock(mtx); while (work_empty()) { pthread_cond_wait(cond, mtx); } // 条件满足处理任务 pthread_mutex_unlock(mtx);这个while而不是if的判断我愿称之为条件变量最核心的纪律。谁要是图省事写成if在多核并发环境下几乎必然会遇到“唤醒后条件又变了”的竞态。3.3 TLS私有存储区数据隔离的最后一道墙回到热搜词里另一个点“线程控制块和私有存储区的关系”。控制块是内核用来管理线程调度的那部分数据私有存储区则是为线程运行提供独立空间的那部分。它们各自解决不同问题但共同支撑了“线程是独立执行流”这个事实。举一个工作中实际遇到的例子我们有个采集程序每个线程负责连接一台设备设备返回的协议错误码都放在统一的错误变量里。因为项目初始设计是单线程后来改成多线程后发现错误码总被其他线程覆盖。这就是典型的errno问题放大版。解决方式有两种一种是把错误码放到TLS里用__thread int last_err声明各线程各存一份。简单粗暴但够用。另一种是使用pthread_key_create注册线程私有的键配合pthread_getspecific和pthread_setspecific存取数据支持更复杂的构造和析构逻辑比如需要在线程退出时释放私有数据的场景static pthread_key_t key; static void destructor(void* v) { free(v); } void init_once(void) { pthread_key_create(key, destructor); } void store(void) { char* p malloc(64); snprintf(p, 64, thread-aware data); pthread_setspecific(key, p); } void load(void) { char* p pthread_getspecific(key); if (p) printf(%s\n, p); }pthread_key配合每次线程退出时自动调用析构函数适合我们不能手动管理线程私有资源的情况。比如线程池里的工作线程反复被复用如果每个任务都往TLS里塞新指针退出时不释放泄漏就会堆积。用key的析构函数能兜底。4. 线程互斥与死锁共享世界的通行规则4.1 临界区的保护不是“加个锁”那么简单先理解竞态。两个线程同时对全局变量做count从C语言看是一行语句编译器实际生成的可能不止一条指令读count到寄存器、寄存器加1、写回count。两个线程交错执行时可能出现读到的都是旧值最后只有一个加1生效。解决思路就是用互斥锁让这段“读-改-写”操作变成原子段。pthread_mutex_lock和pthread_mutex_unlock之间的区域叫临界区。我发现有经验的人写临界区时会注意三点一是临界区尽量短。锁持有时间越短其他线程等待的概率越低。如果临界区里还做了慢速文件读写性能立刻滑坡。二是拆锁及时。用pthread_mutex_unlock结束临界区后马上考虑是否需要再持锁。线程函数里最忌讳写一个巨大的加锁区间把不相关操作全包进去。三是避免锁嵌套。锁里再锁一旦锁顺序不一致死锁概率直线上升。4.2 死锁的产生四个人在圆桌前各等一把叉子死锁的经典模型是哲学家就餐问题N个人坐成一圈每人左手边一把叉子必须拿到两把叉子才能吃饭如果每个人都先抢自己左手边的叉子就会发生所有人都攥着一把叉子等另一把的僵局。多线程死锁的本质也一样必须具备四个条件才会出现互斥资源一次只能给一个线程用、持有并等待线程拿着一个锁不放还去等另一个锁、不可剥夺锁不能强行从别人手里抢过来、循环等待线程们形成闭环A等B的锁B等A的锁。解决策略中最常用的就是打破循环等待给所有锁排一个全局顺序所有线程都按同一顺序加锁。比如规则约定必须先锁A再锁B那么任何线程都不会出现“先锁B再锁A”的状态循环等待就不成立。实际排查死锁时我会用gdb现场抓gdb -p pid (gdb) thread apply all bt这条命令会把当前进程所有线程的调用栈打出来。如果发现两个线程各自卡在pthread_mutex_lock而且栈里能看到等待的是同一把锁或者互相等待彼此的锁死锁现场就清楚了。常规业务日志里往往看不到死锁因为线程是挂起状态CPU不涨日志不输出只有线程栈能暴露真相。另一个实用技巧是给锁起名字比如用结构体包装pthread_mutex_t并带一个name字段。死锁时看栈里等待的锁对象一眼就能定位是哪把锁typedef struct { pthread_mutex_t mutex; const char* name; } named_mutex; #define INIT_NAMED_MUTEX(mtx, n) { .mutex PTHREAD_MUTEX_INITIALIZER, .name (n) }这把操作成本极低但在多线程复杂度高起来以后省下的排查时间非常可观。4.3 互斥锁、自旋锁和原子操作哪把钥匙开哪把锁锁的选型有时候比锁本身的质量影响更大。互斥锁mutex在竞争激烈时没有拿到锁的线程会被挂起睡眠等锁释放后再被唤醒这个过程涉及内核调度性能有损耗。自旋锁则是拿不到锁时就原地反复读锁状态不睡眠适合临界区极短且锁竞争不严重的场景。一个常见误区是“自旋锁比互斥锁快”。实际上自旋锁在单核机器上尤其糟糕——锁持有者压根没机会被调度走因为等待者一直在占着CPU检查锁状态谁也别想往前推进。更轻量的是原子操作比如C11的atomic_compare_exchange_weak、C的std::atomic。用原子变量做计数器、状态位完全不需要锁。但原子操作不适合实现复杂数据结构的一致性它解决的是“一个数”的读写同步不是“一堆数据”的复合操作。场景推荐方案临界区短竞争少原子操作临界区极短竞争较激烈多核自旋锁临界区可能较长竞争普遍互斥锁读写比例悬殊读写锁pthread_rwlock_t5. 线程同步的信号量从信号到手语5.1 信号量不只是计数器它是通用的同步工具信号量很有意思它既可以被当作互斥机制也可以承担“发信号”的任务。二值信号量值只取0和1等价于一把互斥锁。计数信号量就可以管理一批资源比如限制最多允许5个线程同时访问某个资源池。pthread系列没有直接封装信号量信号量在POSIX里是另一套接口sem_init、sem_wait、sem_post使用sem_t类型。sem_t sem; sem_init(sem, 0, 3); void* worker(void* arg) { sem_wait(sem); // 拿一个名额不够则阻塞 // 访问受限资源 sem_post(sem); // 归还名额唤醒等待者 }这里第二个参数pshared填0表示线程间共享如果填非0信号量可以在进程间共享但要配合共享内存使用这个场景较少用。5.2 条件变量和信号量怎么选这是我被问最多的问题之一。二者表面相似都能让线程等待再唤醒但侧重点完全不同。条件变量本身不带计数器它只是一个“等待队列”唤醒时不会记住历史上发过多少次signal。所以它天然适合“某个状态是否满足”的长期等待比如队列是否非空、任务是否完成。信号量自带计数器唤醒是有状态的。sem_post一次计数加1sem_wait一次计数减1。这种特性让它适合做事件计数和资源池管理。生产环境里用得最多的还是条件变量配合互斥锁做任务队列。信号量一般出现在有限流量控制、连接数限制等场景。如果让我给新项目提建议默认就是条件变量加互斥锁除非明确要管理一个资源池再考虑信号量。6. 线程池从直接new线程到复用线程的工程化实践6.1 线程池要解决的是什么问题线程本身不是免费的。创建线程要陷入内核分配TCB和栈销毁线程还要释放资源。频繁创建销毁开销在大量短小任务面前会变得刺眼。线程池的思路就是预先创建一组线程任务来了往队列里丢线程们自己取活干干完继续待命不销毁。任务处理延迟被控制在极低水平同时线程数量被限制住不会因为任务爆炸而无限扩张。一个最简线程池的核心就是一个任务队列、一个条件变量、一把锁、一组工作线程循环消费。typedef struct task { void (*fn)(void*); void* arg; struct task* next; } task_t; typedef struct threadpool { pthread_t* threads; int thread_count; task_t* queue_head; task_t* queue_tail; pthread_mutex_t lock; pthread_cond_t cond; int shutdown; } threadpool_t;任务入队时加锁插入链表尾部然后pthread_cond_signal唤醒一个等待的工作线程工作线程从队头取出任务在锁外执行任务函数。这能保证同一时刻多个线程不取到同一个任务也避免长时间持锁影响入队性能。6.2 线程数设为多少合适判线程池配置合理与否有个粗公式CPU密集型任务线程数接近CPU核心数再多只会增加切换开销IO密集型任务线程数可以放宽到核心数的两倍甚至更多因为线程大部分时间在等IOCPU调度器不会一直让它们占着核心。准确一点的经验法则是最优线程数 核心数 * (1 平均等待时间 / 平均计算时间)如果你的任务IO等待时间很长比如每个任务要等5毫秒的网络响应而CPU计算只要1毫秒那即使是8核机器线程数也可以轻轻松松设成40甚至更多。线程池上限的作用不是让任务执行更快而是保护系统不被打满。6.3 队列和拒绝策略线程池真正体现工程水平的细节任务队列可以是无界的也可以是带容量的。无界队列实现简单任务汄到内存耗尽都不会拒绝任务。有界队列配合拒绝策略才能在真正过载时保护系统。一个有界阻塞队列的经典流程是入队时先加锁检查队列是否已满。已满就阻塞或者走拒绝策略返回错误码。出队时检查队列是否为空为空就等条件变量。拒绝策略各有取舍直接拒绝当前任务最安全但可能丢失请求阻塞调用方让生产者放慢速度适合上下游速率不匹配的场景丢弃最旧的任务适合实时性要求高的数据流处理丢弃当前任务最简单但通常不可取。我实际用过最顺手的是“阻塞入队超时拒收”的组合阻塞太久说明系统状态异常超时后返回一个明确的忙错误让上游业务自行重试或降级。6.4 监控线程池必须盯住的三个指标线程池不是配完参数就万事大吉。运行期要持续关注三个指标活动线程数、队列积压量、任务的拒绝率。活动线程数长期等于最大线程数说明线程数设置也许偏保守或者IO等待时间过长队列积压量不断上涨说明任务生产速度大于消费速度拒绝率上升则说明系统已经进入过载状态需要扩容或者限流。平时可以定期打印线程池的状态active_threads8 queue_depth120 rejected3 avg_task_wait_ms42就算不写监控系统代码里留一个线程安全的状态查询接口排障时能把“线程池烂没烂”这个问题快速回答出来价值极大。7. 最后聊聊虚拟线程、协程和未来模型热搜词里有“akka线程模型”“虚拟线程”“自由线程”等这些概念看起来热闹底层其实都能在Linux线程的骨架上找到对应关系。Java 21引入的虚拟线程本质上是把大量轻量级调度任务映射到少数平台线程上平台线程最终又映射到操作系统线程。这相当于在用户态实现了一个自己的线程池每个“虚拟线程”只占很薄的栈和上下文可以随便创建百万个由调度器自动在这些“虚拟线程”之间切换屏蔽了系统线程切换的昂贵成本。从这个角度看理解Linux原生线程依然是理解一切并发模型的基础。你明白了TCB和私有存储区就明白了为什么虚拟线程的切换成本可以远低于系统线程——它们根本不需要切内核栈和全套寄存器只需要在用户态保存少量上下文。而协程更像在单线程里用协作式调度做任务切换压根没有并发只有交替执行。我自己的建议依然是先把pthread这套吃透再用语言级的高级抽象去简化实现。底层机制出问题时比如死锁、栈溢出、竞态你会发现这些抽象再怎么花哨最终都会回到线程的本质问题上来。8. 我的线程编程核心经验清单写到这里把真正的干货收个尾这是我用了很多年总结出来的几条原则每条都是踩坑换来的第一线程创建后立即检查返回值。这是成本最低的一行防御偏偏最多人省略。第二传给线程函数的参数默认复制一份或者用堆内存别图省事传循环变量的地址。第三判断条件用while循环包裹pthread_cond_wait不要用if。这句话我重复了很多遍因为它值得重复。第四尽量让临界区短到一眼能看完。临界区里出现的系统调用越多排查竞态的难度越大。第五锁的获取顺序保持一致打破死锁的循环等待条件。第六线程退出必须有明确的路径。用标志变量加join的方式关闭工作线程而不是pthread_cancel强行终止。第七线程池不是银弹但要大量处理短任务时线程池几乎是唯一正经的选择。配置线程数要基于任务的实际等待时间和计算时间别拍脑袋。第八私有存储区不只是理论概念。TLS、errno、线程栈每一项都可能在性能与准确的边界上决定成败。曾经有个前辈跟我说过一句话我一直记着多线程编程的风险不在于你用了多少锁而在于你对并发模型的理解有多接近实际执行。Linux线程系统编程这门功课学的时候觉得复杂写多了才发现一切都是围绕“并发执行”和“共享资源”这两个主题展开的。把这两个主题理解透彻剩下的无非是接口细节和不断练习。
