Linux线程完全解析：从概念、进程区别到内核实现-北京尧图网络

还记得第一次把一个网络服务从多进程改成多线程时那种“世界轻了一半”的感觉。原先每个客户端对应一个子进程内存翻着倍涨上下文切换也开始影响延迟后来照着前辈的思路换成了线程模型代码结构变了资源占用下来了并发表现也柔和了许多。但一开始我和很多人一样对线程的概念是模糊的只知道“进程里有线程”“线程共享地址空间”至于Linux内核里到底怎么表示一个线程、线程和进程的分界在哪里完全没概念。这篇文章就是这个“线程”系列的第一篇先把线程的概念、与进程的区别、以及内核里线程的实现基础讲透后面再聊锁、同步、线程池底子会稳得多。1. 线程概念从进程的“重量”说起1.1 进程为什么“重”资源所有权和执行流绑在一起在操作系统的教科书里进程被定义为一个正在运行程序的实例它有独立的地址空间、文件描述符表、信号处理函数、当前目录、umask等等。这些属于“资源所有权”的部分。同时进程还必须有一条“执行流”也就是CPU当前正在执行的指令序列表现为程序计数器PC、栈指针、寄存器状态。传统上我们是用fork()创建子进程的。父进程通过fork()几乎完整复制出一个子进程虽然Linux用写时复制Copy-on-WriteCOW优化了内存页的复制没有在fork()那一刻真的把所有物理内存页拷一份但子进程仍然拥有属于自己的地址空间、文件描述符表、信号处理器等。这种“资源所有权执行流”绑定的模式带来了两个直观的代价第一创建进程的成本高。要复制内核数据结构要分配和初始化新的地址空间要复制文件描述符表还要处理页表。即使有COW单次fork()在大型服务里频繁调用时开销依然可观。第二切换进程的成本高。进程切换意味着CPU要从一个进程的执行流切到另一个进程的执行流这通常要先切换地址空间。切换地址空间就要换页表现代CPU普遍依赖TLB缓存页表项换页表后TLB中大量缓存失效后续访问内存会产生更多缺页和查页表的开销。这些“重量”对于高并发I/O服务来说非常不友好。假设一个HTTP服务器要为上千个连接服务为每个连接创建独立的进程光地址空间的隔离就浪费了大量内存。可问题是这些连接之间本来就需要频繁共享数据比如缓存、会话状态。独立地址空间带来的隔离性反而成了通信的障碍。于是大家开始想能不能把“资源所有权”和“执行流”解耦地址空间、文件描述符这些资源共用一套然后在这套资源上跑多条执行流。这样执行流之间天然共享内存通信方便切换时不用换地址空间速度快创建时只需分配一份执行流相关的上下文成本低得多。这就是线程模型的出发点。1.2 线程的定义与最小执行单元线程thread是CPU调度的最小执行单位是一条独立的执行路径。一个进程可以包含多个线程这些线程共享该进程的几乎所有资源地址空间、堆、全局变量、文件描述符、信号处理器、当前目录等。但每个线程有自己的程序计数器、寄存器上下文、栈空间以及线程局部存储TLS, Thread-Local Storage。打个比方进程是一个车间车间里有厂房、生产线、工具箱和原材料仓库线程是车间里的工人大家在同一片厂房里工作共用一套设备和材料但每个人手里有自己的进度本寄存器、记着自己的活干到哪了PC也有自己放私人物品的小柜子栈。工人们可以自由地传话、递工具共享数据远比隔墙喊话方便但同时也要注意别抢同一个扳手数据竞争。这个“共享资源独立执行流”的定义就是线程的核心语义。它解决了多并发任务需要共享数据时的协作问题也让系统能更轻量地支持大并发。在多核处理器上线程还有额外的好处如果一台机器有8个核把一个计算任务拆成8个线程分别放到8个核上并行跑执行效率可以接近理论上的8倍。用进程也能做到这件事但线程的创建和上下文切换成本更小更适合需要高频并发的场景。所以线程的价值总结起来就三句话共享方便切换轻快并发能力强。1.3 用户视角的线程not一个抽象概念而是实实在在的API在Linux上用户态创建线程最常用的接口是POSIX线程库pthread。一个简单的例子#include stdio.h #include pthread.h void* worker(void* arg) { printf(worker thread running, arg%ld\n, (long)arg); return NULL; } int main(void) { pthread_t tid; pthread_create(tid, NULL, worker, (void*)1L); pthread_join(tid, NULL); return 0; }编译时加-lpthread。这个例子里pthread_create做了两件事一是创建一个新的执行流二是把这个执行流纳入当前进程的“线程组”。pthread_join则是等待该执行流结束类似waitpid回收进程。很多初学者只看到API的简单并不知道pthread_create背后其实是调用了Linux内核的clone()系统调用。理解这一点才能真正理解“进程与线程的区别”在最底层其实并不像教科书里划线那么分明。2. 线程与进程的区别不只是“共享地址空间”2.1 从资源与调度的角度对比教科书里最喜欢列一个对比表格但真正要把区别落地得从“资源所有权”和“调度单位”两个维度去理解。我画了一个简化版对比真正写代码和排查问题时很有用项目进程线程地址空间每个进程独立互不可见同进程内线程共享同一个地址空间页表每个进程一套切换时可能引起TLB失效同进程线程共享页表切换时无需换页表文件描述符表独立或继承复制共享同一张文件描述符表信号处理器独立设置共享所有线程用同一套信号处理函数栈进程主线程栈由系统分配每个线程独立用户栈可自行配置大小寄存器上下文切换时保存/恢复同样要保存/恢复但不需要动页表通信方式需要IPC管道、共享内存、socket等直接读写共享变量、全局数据开销创建/切换成本高创建/切换成本显著降低隔离性强一个进程崩溃不影响其他进程弱一个线程死掉很可能拖垮整个进程拥有者关系一个进程至少携带一个主线程进程被看作线程组从调度器角度看Linux并不关心它调度的是一个一流进程还是一个线程它只关心“可运行实体”。但切换实体时的成本存在差异如果被切换的两个实体属于不同进程需要切换内存管理上下文mm如果属于同一进程的不同线程只需要切换执行上下文和用户栈工作量小得多。2.2 Linux内核的“进程”与“线程”并没有绝对界限这一点是理解Linux线程的关键也是网上很多说法互相矛盾的地方。传统的Unix把进程当成一个整体创建线程需要额外的内核支持。但Linux的设计走了另一条路内核里没有专门的“线程”数据结构进程和线程本质上都是用同一个结构体task_struct描述的“任务”。它们的差别只在于创建时是否共享了一部分资源。fork()创建一个几乎完全独立的task_structpthread_create()内部调用clone()时通过标志位指定“共享地址空间、共享文件描述符、共享信号处理、共享文件系统上下文”。所以Linux线程其实是一种“轻量级进程”英文缩写LWPLightweight Weight Process说的就是这个概念。clone()的系统调用接口长这样简化int clone(int (*fn)(void *), void *stack, int flags, void *arg, ...);关键在flags。下面这些标志位决定了新的执行流要和父任务共享哪些资源CLONE_VM共享地址空间mm_structCLONE_FILES共享文件描述符表files_structCLONE_FS共享文件系统上下文root、current directory、umaskCLONE_SIGHAND共享信号处理函数表CLONE_THREAD加入同一个线程组与父线程有相同tgidfork()本质上是带SIGCHLD标志但不带上述共享标志的clone()所以父子进程互不共享资源。而pthread_create()则带上上述一组标志。中间产物vfork()则是带上CLONE_VM | CLONE_VFORK子进程和父进程共享地址空间但父进程会阻塞到子进程退出或执行exec为止。这个机制早期是为了解决子进程需要立即执行新程序时避免无谓复制页表的开销现在用的场景比较少。理解了这一点很多概念就通了进程和线程不是“两种东西”而是“同一类东西在共享资源上的不同组合”。一个独立的task_struct不共享资源我们叫它进程一个task_struct通过CLONE_*标志和另一个task_struct共享了地址空间我们叫它线程。2.3 用户态线程与内核线程必须分清很多人在看系统监控时会被“内核线程”的概念绕晕。我们先说用户态线程就是我们用pthread_create()创建的线程。它虽然叫“用户态线程”但每个pthread底层都对应一个内核里的task_struct由内核调度器统一调度。所以说它是“内核级线程”也完全没有问题。NPTLNative POSIX Thread Library就是Linux默认的线程实现它直接使用clone()创建内核任务实现了1:1的线程模型用户态一个线程对应内核一个task_struct。内核线程kernel thread则完全是另外一回事。内核通过kthreadd内核线程创建比如kworker、kswapd等。它们运行在内核态没有用户地址空间也不能访问用户态内存只在内核逻辑中执行后台任务。判断一个任务是不是内核线程看它的mm字段是否为NULL即可。内核线程的task_struct-mm为空说明它没有进程地址空间只使用内核地址空间。这个区分非常重要用户态线程可以通过pthread_self()拿到线程ID通过gettid()拿到内核线程ID而内核线程只能通过内核命令如ps -eo pid,cmd看到进程列表里带方括号的名字例如[kworker/0:1]。它们不参与用户空间的并发编程。3. 内核实现细节task_struct、tgid与调度3.1 task_struct里存了什么pid与tgid的设计在Linux内核源码里每个执行流对应一个task_struct这个结构体非常庞大涵盖调度信息、内存信息、文件信息、信号信息、进程关系等。你可以在include/linux/sched.h里看到它。内核里并没有为线程单独定义另一个结构体线程同样是一个task_struct所有线程的task_struct通过线程组链表连接在一起。如果你已经看过进程相关的代码一定会注意到进程描述符里有pid这个字段。但对于线程组Linux引入了一个额外概念叫tgidThread Group ID线程组ID。看一个常见场景一个进程的主线程调用getpid()拿到的是tgid。进程内部的子线程调用getpid()拿到的也是同一个tgid这样符合POSIX语义同一进程内所有线程看到“进程ID”相同。但每个线程的内核PID是不同的通过gettid()可以看到。这个线程ID对应task_struct-pid。所以如果在内核里检查一个任务的task_struct-pid实际上拿到的是它的内核线程ID而task_struct-tgid才是用户态看到的进程ID。线程组内所有线程的tgid相同都等于主线程的pid。信号默认是发给进程tgid的而不是发给某一个具体线程。这种设计的初衷是内核需要一种方式既能表示“多个执行流共享同一套资源”又能保留每个执行流的独立调度信息。于是pid给调度器用tgid给资源管理用。你可以通过ps -eLf看到这种关系输出里的PID列是tgid而LWP列是每个线程的独立pid。ps -T -p pid也能显示线程列表。3.2 clone的实现路径do_fork与标志位组合clone()在内核中最终调用kernel_clone()新版本内核叫kernel_clone再进一步进入copy_process()。这里会按flags决定复制哪些资源。大致流程如下复制任务描述符task_struct。根据CLONE_VM决定是共享mm_struct还是调用copy_mm()复制一份地址空间。根据CLONE_FILES决定是共享文件表还是copy_files()复制。根据CLONE_FS决定共享文件系统上下文还是复制。根据CLONE_SIGHAND决定共享信号处理函数表还是copy_sighand()复制。如果设置了CLONE_THREAD新任务会被加入父任务的线程组链表并设置相同tgid同时real_parent等关系也会做相应调整。最终把新任务插入调度器的运行队列。这里有个值得深入的点CLONE_VM共享的地址空间是同一个mm_struct这意味着两个线程的虚拟地址布局完全一致它们看到的是同一份物理页面。好处是内存节省访问共享变量时不需要进入内核做IPC坏处是一个线程无缘无故改掉别人的代码页其他线程立刻受罪。更严重的是如果一个线程陷入segfault内核会给它所在线程组发送SIGSEGV默认动作是终止整个进程所有线程一起死掉。这也是线程隔离性差的根源。实际应用中pthread_create()使用的标志位大致是CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SETTLS | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID其中CLONE_SETTLS用于设置线程自己的标签即线程局部存储TLS段CLONE_CHILD_CLEARTID用于线程退出时唤醒pthread_join等待者。这套组合非常灵活Linux也因此可以支持其他操作系统风格的线程模型——只要调整flags就能模拟出各种“介乎进程与线程之间”的变体。3.3 线程切换为什么快地址空间与TLB进程切换时内核会调用context_switch()其中一句非常关键if (prev next) return; switch_mm(prev-active_mm, next-active_mm, next);switch_mm()负责切换地址空间。如果是同一进程内的两个线程切换它们的active_mm是同一个mm_struct切换时可以跳过实际页表替换只用更新CPU的mm_cpumask之类的状态。TLB里原本缓存的地址映射仍然有效因为它们本来就在同一个地址空间里。而不同进程之间切换必须加载新进程的页表并刷新TLB。现代CPU虽然通过PCIDProcess Context Identifier能力让不同进程的TLB项共存减少完全刷新的频率但相比同一进程内线程切换仍然要处理地址空间切换的开销。除了地址空间线程切换真正需要保存和恢复的是通用寄存器、浮点寄存器、栈指针、指令指针以及线程相关的状态。这些上下文都保存在各自的thread_struct和内核栈里。这就是“线程切换比进程切换快”的底层来源。如果两个线程恰好运行在不同CPU核上甚至没有传统意义上的“切换”并行度才是更重要的优势。3.4 线程组与退出行为一个线程崩溃整个进程退出线程组通过tgid维系着“多个task_struct共享一个进程身份”的关系。当调用exit()退出一个线程时普通线程执行do_exit()清理自己的任务但最后一个线程退出时或显式调用exit_group()时整个线程组都会退出。最典型的现象是某个线程因为空指针解引用触发了段错误。内核检测到这个异常时会向整个线程组发送SIGSEGV。如果进程没有注册自己的信号处理函数默认动作是终止进程那么其他线程即使正常运行也无法幸免。所以多线程程序里任何一个线程崩溃整个进程必然挂掉。这与多进程模型下“一个子进程崩溃影响面可控”的性质差别巨大。实际开发中这个特性经常被忽略。比如服务用了监控健康检查机制某个线程因为网络库超时崩溃整个服务退出TCP连接全断后续请求全部失败。排查时用core dump看崩溃的是哪个线程经常发现是某个非常边缘的线程非法访问了内存。这种“一颗老鼠屎坏一锅粥”的效应就是多线程程序的典型风险。3.5 TLS和线程栈每个线程的“私有房间”虽然线程共享进程的地址空间但每个线程仍然需要一点专属部分否则栈上局部变量没法各归各。进程的主线程栈叫进程栈后续线程的栈由线程库在用户态分配。在pthread_create()时可以通过pthread_attr_setstacksize()指定用户栈大小不指定则使用系统默认值。Linux上默认线程栈大小通常等于ulimit -s的值很多发行版是8MB。对于大量线程的应用8MB乘几千个虚拟内存地址空间也会被吃得很厉害所以需要按需调小栈大小。线程栈虽由用户态分配但内核依然为每个线程分配独立的内核栈。内核栈通常很小在x86-64上是16KB用于保存系统调用、中断处理、异常处理时内核态的函数调用避免嵌套过深导致栈溢出。内核对内核栈溢出检查很严格这也是内核代码为什么讲究“栈上不放大量数据”。线程局部存储TLS用来存放线程私有的全局变量。声明__thread int tls_var;每个线程都会有一份拷贝。在x86-64上编译器把TLS访问翻译成基于FS或GS段前缀的相对寻址。用户态默认用FS指向TLS基址访问时直接用偏移量mov %fs:0x0, %eax。内核在clone()里通过CLONE_SETTLS传入这个地址初始化线程的TLS段。4. 实践认知从进程到线程迁移的体验与避坑4.1 用线程前的判断什么时候该用线程什么时候不该线程不是万能的。基于我的经验决策可以从三个问题开始并发任务之间需不需要高频共享数据如果每个任务基本独立、很少通信用进程更安全进程间通信用消息队列、共享内存或socket也能做。隔离性是不是刚需一个任务崩溃后系统其他部分能不能继续服务如果不能接受“崩溃带走一切”多进程模型更合适。并发规模有多大如果单机上需要上千个并发执行流进程数上千很可能撑不住线程可以做到但要注意栈大小和内存限制。举个例子我之前维护过一个日志采集代理需要从多个文件描述符读数据聚合后发送到存储端。各连接之间共享一个大的发送缓冲区和配置表如果每个连接一个进程共享缓冲区就必须通过共享内存或消息反而复杂化。改成线程模型后配置表和缓冲区的访问只要加锁即可代码直观很多。但如果是一个有状态的服务要求强隔离比如多租户平台上的单个计算任务任一个租户的任务异常都不该影响其他租户这种场景用多进程隔离更合理或者干脆用容器。4.2 我踩过的几个坑共享变量、栈大小和join第一坑共享变量保护不当。线程共享全局变量只要有一个线程写了而另一个线程在还没锁的情况下读了就会产生数据竞争。数据竞争不一定会立刻崩溃但会表现为偶发的脏数据、死锁或性能劣化。我曾经因为没给布尔状态加锁导致两个线程反复读到旧值服务状态一直错乱。排查时用valgrind --toolhelgrind才抓到那处race。从那以后我有个习惯所有跨线程访问的变量不管多小都配上原子操作或锁非共享尽量用线程局部变量根本不让别人碰到。第二坑忘记pthread_join或者pthread_detach。主线程创建线程后线程结束时如果未被join会保留部分资源exit状态和栈作为僵尸线程类似僵尸进程。时间长了线程资源耗尽pthread_create返回EAGAIN。解决方法是要么在正确时机pthread_join回收要么创建时就pthread_detach让自己退出自动释放。注意pthread_detach和join只能选一个重复使用未定义行为。第三坑默认线程栈过大。默认8MB的栈在大量线程场景下相当恐怖。2万个线程虚拟地址空间就是160GB虽然大部分不会马上耗掉物理页但地址空间会先耗尽。真实案例一个消息处理程序想开2万线程结果还没开满就报内存不足后来把线程栈调到512KB事情一下就解决了。用pthread_attr_setstacksize设定之前先评估你的线程实际需要多少栈空间。递归深一些的逻辑1MB通常够用极深递归可能需要更大这时更应该优化算法而非加栈。4.3 多线程与fork、exec、信号纠缠不清的现场多线程环境下调用fork()是暗藏杀机的。POSIX规定fork()创建出来的子进程只有调用fork()的那个线程会被复制其他线程都消失但它们曾经持有的锁状态不会自动消失。假设线程A持有某个锁后线程B调用了fork()子进程里该锁的持有者线程A不存在了锁永远不会被释放。如果子进程后续又尝试获取这个锁就会死锁。常用对策是不要让多线程进程调fork()最好是fork()后立刻exec()新程序让锁状态有机会被清空。如果不得不在fork前后操作共享资源注册pthread_atfork()处理函数在fork前拿到所有锁fork后释放排除竞态窗口。信号处理在多线程里同样麻烦。信号默认发给进程进程收到时内核会选择任一不屏蔽该信号的线程处理。如果信号是SIGSEGV之类同步异常会发给触发异常的线程如果是SIGTERM这类同步外部信号则可能发给任意线程。所以想用线程单独处理某个信号必须对其他线程做信号屏蔽并让指定线程用sigwait()循环等待。不然信号跑到哪个线程完全是随机的。4.4 排查线程问题可以用的工具清单线程问题排查比进程难因为并发下的bug往往靠运气复现。我常用的工具依次是ps -eLf第一眼确认有多少线程、LWP号、线程状态。top -H -p pid按线程看CPU占用快速定位哪个线程在忙或卡住。gdbthread apply all bt查看所有线程栈info threads切换线程在线程死锁时非常直观。strace -f跟踪所有线程的系统调用配合线程ID过滤。valgrind --toolhelgrind检测数据竞争和锁顺序问题。perf top / perf record采样线程热点定位CPU占用异常。一个很值得讲的案例某服务从多进程改造为多线程后吞吐量非但没涨反而下跌了20%。用perf看热点发现大量时间花在自旋锁等待上。但这个锁保护的变量明明很小不该有这么多竞争。后来在锁里面又用Cache对齐的方式分隔了两个相邻的计数器性能立刻恢复正常。原因是两个线程分别高频写两个“看似无关”的全局变量但它俩被分配在同一个缓存行64字节里两个核轮流写导致缓存一致性协议反复失效类似“伪共享”。这次经验让我深刻体会到多线程性能瓶颈往往不在逻辑本身而在CPU缓存层的细节。在排查时还有一个常用技巧给线程起名字。pthread_setname_np(pthread_self(), worker_io)设置后可以在ps -eLf里看到容易识别的线程名省去很多猜谜时间。从实践看好的命名习惯对协作调试帮助极大。4.5 从“线程一”到后续接下来该补什么这篇文章把线程的底层骨架搭了一遍。围绕概念和区别真正进入多线程编程时你会发现同步才是大头互斥锁、读写锁、条件变量、信号量、原子操作、无锁编程、内存屏障、线程池调度。每一块都有很多坑。我在下一篇里打算从mutex入手讲讲Linux的futex机制以及为什么锁竞争激烈时系统调用会成为瓶颈。在实际项目中我也会刻意保留“进程模型”作为兜底方案。线程适合处理大部分高并发I/O场景但如果某个模块实在不稳定对隔离性有强制要求那该用进程的地方还是要用进程。不要因为线程“好”就把所有地方都改造成线程工具没有绝对的优劣只有适合与否。最后再分享一个小技巧当你调试一个线程栈相关的段错误gdb里thread apply all bt输出看起来一样很多这时先看info threads里哪一个是“running”状态再看崩溃时core dump指定的那个线程往往问题就在它的栈或它访问的内存上。写多线程代码时永远给每个线程明确划分“它管哪些数据”比事后找锁要省心得多。

Linux线程完全解析：从概念、进程区别到内核实现

相关推荐

无线传感器网络化工环境监测：从节点部署到组网实战全解析

基于Django+Selenium+Echarts的京东商品数据可视化平台设计

Godot SocketServer 基类完全指南：构建 TCP 与 Unix Domain Socket 服务端

更多资讯

Node-Red环境搭建避坑指南：从零跑通第一个节点

Context-Mode：一种解决代码导航迷航的上下文模式

Aurelio 上手：一个本地优先的个人财富管理应用，AI 只提建议不直改数据

Litellm实战：统一多LLM API网关的部署与排坑指南

基于Spark与Django的胆结石数据分析与可视化系统设计

lsp-mode 故障排查完全指南：从日志、服务器路径到最小环境复现

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？