Linux线程底层解析：从地址空间共享到clone系统调用与用户态线程库实现-平芜编程栈

第一次在Linux底下被多线程折腾到怀疑人生，是在某次线上模块压测的时候。程序跑着跑着就段错误，core文件抓出来一查，既不是空指针，也不是数组越界，最后定位到的是一个线程函数里声明了个大数组，直接踩穿了线程栈底。当时我就意识到一件事：如果对线程的地址空间模型没有足够清晰的认识，后面调试并发问题的每一步都会被牵着鼻子走。

这篇文章想聊的就是Linux线程从底层到封装的完整链路：地址空间怎么共享，clone系统调用怎么创建线程，用户态线程库怎么设计TCB、怎么做上下文切换、怎么写调度器，最后给出一个可运行的极简线程库源码。适合已经会用pthread写并发程序、想搞清楚"线程到底是怎么跑起来的"的开发者，也适合准备做协程库或嵌入式RTOS移植的人参考。全程用Linux系统编程视角来讲，不会停在API使用层面。

1. 地址空间才是理解线程的钥匙：共享什么比有多少个并行重要得多

1.1 教科书上没讲透的"轻量级进程"

很多入门资料喜欢把线程描述成"轻量级进程"，这个说法不算错，但很容易误导人。如果你把线程理解成"小号的进程"，你可能会下意识觉得线程和进程的区别只是资源开销小一点，从而忽略了一个最本质的差异：进程之间是地址空间隔离的，线程之间是地址空间共享的。

在内核里，进程和线程都对应一个task_struct，也就是内核调度实体。区别在于这个task_struct里挂着什么资源：一个普通的进程有自己独立的mm_struct、独立的文件描述符表、独立的信号处理表；而线程，也就是通过clone系统调用传了一堆共享flag创建的task，会共用这些资源。内核调度器眼里没有"线程"这个概念，它只认识可运行的任务实体。

打个比方：地址空间像一套房子的户型图，mm_struct里描述了这套房子有哪些房间、哪些墙、哪些管道。进程是"每户人家各自买一套房，各有各的户型图"，线程则是"一家人住同一套房，共享同一个户型图，只是每个人有不同的活动轨迹"。多线程程序里，每个线程都在同一张地址空间地图上活动，谁改了全局变量，所有人立刻看得见。

1.2 页表视角：线程间"共享"的真实含义

共享地址空间不是一句空话，在硬件层面落实到页表。一个进程的虚拟地址空间通过页表映射到物理内存，线程共用同一个mm_struct，也就共用同一套页表。这样带来的直接好处是：线程间切换不需要切换页表基地址，TLB不用全部失效，切换开销比进程切换小很多。

但这同时也意味着，线程A通过指针访问线程B栈上的某个局部变量，从内存权限检查的角度看是"合法"的——因为整个地址空间都在同一个页表管辖范围内，没有保护域区分。这一点和进程完全不同。两个进程之间即使物理上映射了同一块共享内存，也要通过mmap显式建立映射才能访问；而两个线程之间天然就是全共享。共享带来的后果是：没有任何硬件机制能阻止一个线程不小心读或写另一个线程的栈数据。

从缺页异常、写时复制这些机制的角度看也是一样。进程用fork创建子进程时会复用父进程页表并标记只读，写入时才触发COW逐页复制；线程根本没有这层保护逻辑，它共享的就是那套物理页面本身。很多并发bug的根源就在这——共享粒度太大，什么都是大家的，谁都能碰，一旦有人越界，隔墙就是"邻居家"的栈。

1.3 从一次段错误反推地址空间的约束

我印象很深的一次排查是这样的：一个线程函数里声明了一段几十KB的临时缓冲区，看上去没什么问题，但那段缓冲区加上函数调用链上的栈帧，超过了为线程栈预留的大小。因为线程栈是malloc或者mmap出来的独立内存区域，栈底之外再往下走就是未分配区域，一旦踩进去就会触发段错误。

如果是主线程，栈是exec加载时由内核分配的，通常有几MB到几十MB，出现类似情况时往往只是栈溢出信号，很难直接定位。更隐蔽的是线程之间互相踩栈的情况：线程A有一个指向外部传入栈变量的指针滞留了，线程B复用了那段栈区域之后，A再去读，拿到的是B写的值。这种bug不会立刻崩溃，只会表现为数据莫名被改，排查起来比段错误痛苦得多。

所以理解地址空间共享的这套约束，是后面理解线程封装的前提：线程库的设计里所有和栈、上下文、局部存储相关的决定，本质上都是在这张共享地图上划出各自的"活动区域"，并在切换时小心翼翼地保存和恢复现场。

2. 封装起点是clone系统调用：pthread的底层真相

2.1 fork根本不适合做线程

如果只看进程创建，最常用的系统调用是fork。fork的语义是"复制一份几乎一样的进程"，子进程拿到的是父进程地址空间的副本，而不是共享的地址空间。即便现代内核用写时复制优化了性能，fork出来之后两个地址空间也彻底分开了，改自己的数据互不影响。这显然不是线程的语义。

Linux为此提供了clone系统调用。clone的签名里最关键的部分是传入一组flag和子进程/线程的栈指针。clone能干的事情很宽泛：从完全独立的进程到完全共享的线程，它都可以通过调整flag组合实现。换句话说，fork只是clone的一个特例，而pthread_create底层就是用clone创建了一个共享地址空间的任务实体。

2.2 一组flag决定"共享边界"

这组flag值得逐个说清楚，因为理解它们才能理解"线程到底共享了什么"：

CLONE_VM：共享地址空间。新任务和调用者使用同一个mm_struct，页表同一套。这是"线程"的基石flag，没有它，clone出来的充其量是个独立进程。
CLONE_FS：共享文件系统信息，包括当前工作目录和umask。
CLONE_FILES：共享文件描述符表。这样两个线程里open同一个文件描述符，关闭、dup、偏移量都是同一个实体。
CLONE_SIGHAND：共享信号处理函数表。配合CLONE_THREAD的语义，进程内的信号投递规则才会符合线程模型。
CLONE_THREAD：把新任务放进同一个线程组。getpid返回同一个进程ID，而gettid返回各自独立的线程ID。

如果想自己封装一个线程库，早晚要面对这些flag。比如我曾经尝试用一个不传CLONE_SIGHAND的clone创建任务，结果发现线程里设置信号处理函数会影响整个进程还是在某内核版本上行为不一致，追了半天，最后还是老老实实按pthread的flag组合来。

2.3 对clone封装时要重点处理的参数

除了flags，clone调用还需要两个关键参数：child_stack和fn。child_stack是子任务使用的栈指针，因为新任务会复用调用者的地址空间，所以不能继续用调用者当前栈，必须给它单独准备一段栈区域。用户态库里通常用mmap分配一段私有匿名映射作为线程栈，而不是malloc——malloc在堆上分配，堆本身是共享的，直接在堆上做栈会导致两个线程的栈可能重叠，而mmap可以指定固定大小且能增加MAP_STACK语义，也更接近glibc的做法。

还有一点容易忽略：传给clone的fn和arg会在新上下文里被调用，但这个调用不经过正常的函数调用约定进入，而是内核在返回用户态时直接切到child_stack顶端执行。所以封装时一般要写一个薄薄的wrapper，把start_routine(arg)包一层，在线程函数返回时负责调用exit清理资源并触发调度器切换到下一个任务。

3. 设计线程控制块TCB：字段清单与内存布局

3.1 用户态线程库也得有一份"档案"

内核里每个任务都有自己的task_struct来保存线程ID、状态、寄存器现场、调度信息等。如果一个用户态线程库想接管线程的创建、切换和销毁，它同样需要一份对应的数据结构，这就是TCB（Thread Control Block）。pthread的线程结构在glibc里叫pthread，自己写极简线程库时习惯叫task_t或thread_t。

TCB最少要包含这些字段：线程ID、状态、入口函数指针与参数、线程栈指针、上下文保存区、返回值指针、以及用于串成队列的链表节点。复杂一点还会加优先级、时间片计数、线程私有数据指针等。设计TCB时的一个原则是：一切切换时需要恢复的信息都应该在这个结构体里找得到，而不是依赖某个全局变量。

3.2 线程栈的分配与十六字节对齐

线程栈分配这块，我第一次写踩过坑。用malloc分配线程栈会导致一个问题：malloc返回的地址在堆里，而栈是按"高地址向低地址生长"使用的，如果只拿到一个指针当栈顶，还得自己把栈基址算出来，并且要考虑对齐。

x86-64的System V ABI要求栈指针在函数调用边界上16字节对齐。如果栈指针没有对齐，调用某些使用SSE指令的函数时会直接段错误。所以分配线程栈时，通常的做法是分配stack_size字节后，让栈指针从stack_top = stack_base + stack_size开始，并且做一次向下对齐，保证stack_top % 16 == 0。这块细节不处理好，线程库跑起来就会玄学崩溃，而且极难复现。

保护页也是一个考虑项。glibc的pthread实现会在线程栈底部放一页"guard page"，访问到这一页会触发SIGSEGV而不是直接踩到别的内存。自己实现极简线程库时，如果想省事可以不加，但意味着栈溢出会变成一个更难定位的问题——这一点后面讲避坑时再展开。

3.3 对外接口：一句话说清楚封装目标

封装线程库的目标本质上是：把clone系统调用的细节、TCB的管理、上下文切换、调度器的实现全部藏起来，向外提供一个类似pthread的接口。最核心的三个操作是创建线程、让出CPU、等待线程结束：

int thread_create(thread_t *t, void *(*start_routine)(void *), void *arg); void thread_yield(void); int thread_join(thread_t t, void **retval);

有了这三个接口，用户写多线程程序时就不需要关心底层clone和ucontext的细节。接口设计上我倾向于尽量贴近pthread形态，这样后续如果想换成真正的pthread实现，上层代码几乎不用改。这也算一种务实的封装策略：先定义好稳定的对外契约，内部实现随时可以替换。

4. 上下文切换是调度的心脏：ucontext方案的取舍

4.1 切换到底换了什么

所谓上下文切换，通俗说就是把当前线程"跑到哪了、寄存器什么状态、栈用到了哪个位置"完整保存下来，再恢复另一个线程之前保存好的这些现场。对一个用户态线程库而言，它不需要像内核那样操作特权寄存器、页表基地址、内核栈；它只需要保存用户态的通用寄存器、程序计数器、栈指针，以及信号掩码等信息。

Linux为用户态提供了ucontext_t这一族接口：getcontext用于保存当前上下文，setcontext用于切换到某个已保存的上下文，makecontext可以修改一个上下文使其指向自定义函数和栈，swapcontext则把"保存当前context"和"切换到目标context"两步合并成一个原子操作。这族接口最初是POSIX为协程和用户态调度器设计的，用来实现线程库正合适。

4.2 setjmp/longjmp为什么不能直接做切换

很多人会问：setjmp和longjmp也能保存寄存器并跳转，能不能用它做线程切换？答案是能跑，但不适合。setjmp只保证保存足够让longjmp恢复到调用现场的环境，实现上未必保存整个浮点寄存器状态或完整的信号掩码，而且它跳转时是"栈展开式"的——跳回到setjmp调用点之后，那个函数栈帧可能已经失效，局部变量的值按C标准可能是未定义的。这用在错误恢复、异常处理场景没问题，用在调度切换上就是定时炸弹。

更关键的是setjmp/longjmp是一个"单向恢复"机制，它只能从当前点跳回某个更早的保存点，不能像swapcontext那样做到对称切换：A保存自己再跳到B，之后B保存自己再跳回A。线程调度需要的就是这种对称配合，所以线程库实现几乎都选ucontext，或者直接用内联汇编保存寄存器，省去函数库的开销。

4.3 UC的保存与恢复细节

使用ucontext做切换有几个容易翻车的点。第一，ucontext_t里的uc_stack要指定线程栈的栈顶和大小，makecontext依赖这个来设置新上下文入口。第二，swapcontext执行时，内核会把当前寄存器现场保存到第一个参数指向的context里，然后恢复第二个参数指向的context。所以两个线程之间的切换表现为：从swapcontext这一行进去，未来某刻又从另一个线程保存好的swapcontext现场"重新冒出来"。

第三点是信号掩码。ucontext_t里保存uc_sigmask字段，swapcontext会保存并恢复信号掩码。这意味着如果线程A先调用sigprocmask阻塞了一些信号，切到线程B后这些掩码也会被带过去，除非B自己重新设置。在多线程库设计里，这个行为可能不符合预期，切换点前后到底要不要隔离信号掩码，一定想清楚再决定。

5. 调度器：从就绪队列到时间片轮转

5.1 队列选型与状态迁移

有了TCB和切换原语，还差一个"大脑"来决定下一个该跑谁，这就是调度器。最简单的调度器是FIFO配合协作式让出：一个就绪队列，先进先出，线程调用yield或者因为等待条件主动阻塞时，调度器取出队头任务继续跑。

线程状态可以精简为：就绪（READY）、运行（RUNNING）、等待（WAITING）、结束（EXITED）。创建完成后进入就绪队列，调度器选中后变为运行，yield或时间片用完回到就绪，join或等待锁时进入等待队列，线程函数返回后变成结束状态。把这些状态之间的转换画成图，整个调度器的骨架就出来了——我自己调试线程库时，几乎每次遇到诡异问题都是先画状态迁移，发现问题出在某个边界状态没处理。

就绪队列的数据结构用链表就够了。如果以后要支持优先级，可以改成按优先级排序的链表或二叉堆；要支持时间片轮转，就维持一个队尾指针把让出的线程放到队尾。一开始不用设计得过于复杂，能正确跑通再谈优化。

5.2 主动让出与被动触发

协作式调度里，切换点只有两类：线程主动调用thread_yield，或线程在等待某个条件时放弃CPU。实现thread_yield时，先把当前线程状态置为就绪并加入队尾，再从队头取出下一个线程，然后执行swapcontext完成切换。这里有个关键细节：如果就绪队列里没有其他线程，yield应该直接返回，不能把当前线程从"运行中"置成就绪又立刻选回自己，否则白白做一次无意义的上下文切换。

如果想要实现抢占式调度，就需要引入定时器信号，比如setitimer定期发送SIGALRM，在信号处理函数里保存当前上下文并切换到下一任务。这虽然能实现时间片轮转，但引出一个麻烦：信号处理函数里调用swapcontext这类操作必须确保是异步信号安全的。这不是一件容易做对的事。极简线程库从协作式做起，先把逻辑跑通，再考虑抢占，是我比较推荐的学习路径。

5.3 线程等待与join怎么落地

thread_join的实现依赖等待状态。当一个线程调用join去等另一个线程结束时，它不能占着CPU死等——那和轮询没区别。简单做法是：把调用join的线程状态置为WAITING，挂在被等待线程的等待列表上，然后主动让出CPU。被等待线程退出时，遍历自己的等待列表，把所有WAITING状态的线程置回就绪并重新入队。

在极简实现里，可以偷个懒：join内部循环检查目标线程状态，直到它变成EXITED，期间不断yield。这个方案在协作式调度里能工作，因为目标线程总有机会获得CPU并退出。缺点是如果目标线程因为某种bug永远不退出，join的线程就跟着空转。生产级线程库当然不会这么干，但作为学习原型的起步实现，代码量少、逻辑直观，反而适合理解调度器的基本原理。

6. 一个极简线程库的源码实现与运行效果

6.1 核心代码逐段说明

这里给出一份我自己维护的最小线程库代码，整体思路是用ucontext做切换，链表就绪队列做协作式调度。代码故意去掉了锁和条件变量，专注展示线程封装最核心的骨架。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <ucontext.h> #include <unistd.h> #define MAX_THREADS 16 #define STACK_SIZE (64 * 1024) typedef enum { THREAD_NEW, THREAD_READY, THREAD_RUNNING, THREAD_WAITING, THREAD_EXITED } thread_state_t; typedef struct task { int tid; thread_state_t state; void *(*func)(void *); void *arg; void *retval; ucontext_t ctx; char *stack; struct task *next; } task_t; static task_t threads[MAX_THREADS]; static int used[MAX_THREADS]; static task_t *current; static task_t *ready_head = NULL; static task_t *ready_tail = NULL; static int next_tid = 1; static task_t *find_free_task(void) { int i; for (i = 0; i < MAX_THREADS; i++) { if (!used[i]) { used[i] = 1; return &threads[i]; } } return NULL; } static void enqueue_ready(task_t *t) { t->state = THREAD_READY; t->next = NULL; if (ready_tail) { ready_tail->next = t; } else { ready_head = t; } ready_tail = t; } static task_t *dequeue_ready(void) { task_t *t = ready_head; if (t) { ready_head = t->next; if (!ready_head) { ready_tail = NULL; } t->next = NULL; } return t; } static void thread_exit(void *retval) { task_t *me = current; me->retval = retval; me->state = THREAD_EXITED; task_t *next = dequeue_ready(); if (next) { current = next; next->state = THREAD_RUNNING; setcontext(&next->ctx); } else { /* 没有其他线程时，直接回到主流程 */ setcontext(&threads[0].ctx); } } static void thread_entry(void) { task_t *me = current; void *ret = me->func(me->arg); thread_exit(ret); } int thread_create(void *(*fn)(void *), void *arg) { task_t *t = find_free_task(); if (!t) { return -1; } t->tid = next_tid++; t->state = THREAD_NEW; t->func = fn; t->arg = arg; t->retval = NULL; t->stack = malloc(STACK_SIZE); if (!t->stack) { used[t - threads] = 0; return -1; } memset(&t->ctx, 0, sizeof(t->ctx)); char *stack_top = t->stack + STACK_SIZE; stack_top = (char *)(((unsigned long)stack_top) & ~0xFUL); stack_top -= 16; getcontext(&t->ctx); t->ctx.uc_stack.ss_sp = t->stack; t->ctx.uc_stack.ss_size = STACK_SIZE; t->ctx.uc_link = NULL; makecontext(&t->ctx, thread_entry, 0); enqueue_ready(t); return t->tid; } void thread_yield(void) { task_t *prev = current; task_t *next = dequeue_ready(); if (!next || next == prev) { return; } enqueue_ready(prev); prev->state = THREAD_READY; current = next; next->state = THREAD_RUNNING; swapcontext(&prev->ctx, &next->ctx); } void thread_join(int tid, void **retval) { task_t *t = &threads[tid - 1]; /* 极简版直接用tid索引 */ while (t->state != THREAD_EXITED) { thread_yield(); } if (retval) { *retval = t->retval; } } /* 简单测试 */ void *worker(void *arg) { char *name = (char *)arg; int i; for (i = 0; i < 3; i++) { printf("%s: %d\n", name, i); thread_yield(); } return (void *)strlen(name); } int main(void) { memset(threads, 0, sizeof(threads)); memset(used, 0, sizeof(used)); /* 用0号槽位表示主线程 */ used[0] = 1; threads[0].tid = 0; threads[0].state = THREAD_RUNNING; getcontext(&threads[0].ctx); current = &threads[0]; int tid1 = thread_create(worker, "thread-a"); int tid2 = thread_create(worker, "thread-b"); printf("created: %d, %d\n", tid1, tid2); thread_yield(); /* 给子线程一次运行机会 */ void *ret1 = NULL; void *ret2 = NULL; thread_join(tid1, &ret1); thread_join(tid2, &ret2); printf("ret: %ld, %ld\n", (long)ret1, (long)ret2); return 0; }

这份代码刻意把thread_join简化成轮询yield，为了让逻辑尽量可读。真正要用在生产环境，还需要处理多核并行、互斥锁、条件变量、线程栈复用等问题，但理解这段代码，比直接去读glibc的pthread实现轻松得多。

6.2 编译运行的效果

用如下命令编译运行：

gcc -o tiny_thread tiny_thread.c -O0 -g ./tiny_thread

运行结果大致是：

created: 1, 2 thread-a: 0 thread-b: 0 thread-a: 1 thread-b: 1 thread-a: 2 thread-b: 2 ret: 9, 9

这里的输出顺序会因系统而略有差异，但整体能体现出两个线程在协作式调度下交替推进。如果把thread_yield()从worker里去掉，则第一个线程一口气跑完，第二个线程才开始——这正好说明了协作式调度对"主动让出"的依赖。

6.3 它和pthread的差距清单

自己写完这个微型线程库之后，你会更加理解pthread那些接口为什么要设计成那样。差距主要体现在几个方面：pthread线程由内核调度，可以真正并行在多核CPU上；而我这个库所有线程跑在同一个进程的一个内核线程上，同一时刻只能有一个"用户线程"在跑，本质上是协程。pthread有互斥锁、条件变量、信号量、读写锁，底层通过futex系统调用让内核在锁冲突时挂起线程；我这份极简代码完全没有这些同步原语。pthread还专门处理了线程局部存储（TLS）、线程私有errno、栈清除回调函数等一堆细节。

不过，看清楚差距本身就是收获：当你用pthread却对线程行为感到困惑时，想一想如果换成一个用户态协作式线程库，哪些问题不存在、哪些问题更严重，很多概念就通了。

7. 深入使用中的坑与排查技巧

7.1 段错误：先查线程栈的对齐与栈界限

用自己写的线程库或者在一个嵌入式环境下手写线程时，第一个段错误往往和业务代码没关系。优先怀疑三件事：栈指针是否按目标平台ABI对齐，线程栈分配得够不够大，栈底是否越界访问了相邻内存。x86-64下建议在栈顶预留16字节再开始用，ARM平台还要额外看调用约定。排查办法很土但有效：在线程入口处打印栈指针，再在业务函数里打印栈指针，看看距离栈底还剩多少余量；如果差得离谱，不要犹豫，先加大栈。

而glibc的pthread出现类似段错误时，先用pthread_attr_getstacksize确认线程栈大小，再用ulimit -s看看系统默认限制。很多压测场景下崩溃不是业务bug，是某个线程函数里一个合理的局部数组加上深层递归调用，把默认8MB栈吃完了。

7.2 信号、errno与异步安全函数

多线程环境下信号处理是一个常年大坑。各线程的信号掩码是独立的，信号投递到哪个线程由内核决定，但线程库里做上下文切换时如果简单复制uc_sigmask，可能导致本来应该被某个线程阻塞的信号被带到另一个线程里。此外，信号处理函数里只能调用异步信号安全的函数，如果你在handler里用printf或者malloc，行为未定义。这一点和协程切换很像：能安全做的事极少，所以生产级线程库一般都会把信号处理做得尽量保守。

errno这块稍微好一点。现代glibc的errno是一个宏，展开后访问线程局部存储变量，所以每个线程有自己的errno副本，不会互相污染。但如果自己实现线程库时用了一个全局int来存errno，那在线程切换的那一刻，errno就被"共享"了，这会让很多库函数出错。这也是封装线程库时必须保留"线程私有数据"机制的原因。

7.3 从实际项目中养成的线程调试习惯

最后分享几个我自己排查线程问题时的习惯。第一，优先看状态机而不是直接看数据。打印每个线程从创建到退出的状态变化，往往一眼就能发现谁卡在等待、谁被错误地重复加入队列。第二，用strace -f跟踪系统调用，看线程到底是不是由clone创建、clone的flag是否符合预期。第三，如果用pthread，就直接打开线程消毒器TSan来编一遍再压测，它抓数据竞争要比人眼强太多。

写线程库本身不算复杂，真正复杂的是把它写对。多线程程序的世界里，细节即魔鬼，而魔鬼往往藏在地址空间、上下文保存、状态迁移这些看起来"很简单"的地方。希望这篇从地址空间讲到源码实现的拆解，能帮你把线程从"会用"变成"懂它为什么是这样"。

Linux线程底层解析：从地址空间共享到clone系统调用与用户态线程库实现