进程和线程这两个词写代码的人天天挂在嘴边可真要一句话讲清楚进程是什么、线程是什么、它们到底差在哪不少人还是会卡壳。我见过太多这样的情况面试背得滚瓜烂熟一上手写并发就出问题——线程池参数靠拍脑袋、CPU 被某个进程吃满却找不到是谁干的、程序退出时提示另一个进程正在占用文件却不知道怎么查。这些坑的根子基本都能追溯到对进程和线程的理解只停在名词层面。这篇就来把地基打牢从概念边界、内存布局、状态模型到创建销毁、通信同步、开销对比再到命令行实操观察和线程池参数怎么算出来全部摊开讲一遍。无论你是刚接触操作系统的新手还是写了几年业务代码、想回头把并发基础补扎实的开发者都能从这里拿到能直接用的东西。1. 先把概念的边界划清楚1.1 程序、进程、线程不是同一层的东西很多人一上来就把这三个词混着用其实它们处在三个不同的层次。程序是存在磁盘上的一堆指令和数据的静态集合你可以把它理解成一张菜谱菜谱写在那儿不代表菜已经做出来了。进程是程序的一次执行过程它有自己的身份证号PID、有自己独占的一块内存空间、有打开的文件句柄、有当前执行到哪一行代码的记录。同一份菜谱可以被厨房做很多次每一次都是独立的进程——互不干扰各自有自己的锅碗瓢盆。那线程呢线程是进程内部的一条执行流它是 CPU 调度的基本单位而进程是资源分配的基本单位。这个区分非常关键几乎所有后续的疑惑都从这句话展开资源按进程分时间片按线程分。一个进程里至少有一条线程就是主线程。主线程跑完main函数进程就结束了其他线程也会被一起带走。我习惯用一个类比解释给新人听进程像一家公司工商注册给了它独立的营业执照、独立账户、独立办公场地线程像公司里的员工大家共用同一间办公室、同一套财务账户、同一份营业执照但每个人手上有自己的笔记本和当前正在处理的活儿。公司倒闭员工自然全部解散一个员工把办公室炸了线程把内存写坏整家公司也跟着完蛋。反过来公司之间要合作得走正式流程进程间通信麻烦但安全员工之间合作抬头喊一声就行共享内存方便但容易撞车。1.2 为什么这个区分对写代码的人有实际意义搞清楚这层边界最直接的好处是能解释一批看起来莫名其妙的现象。比如你在 Python 里开了十个线程做计算结果 CPU 只跑满一个核你会怀疑机器坏了——其实是 CPython 的全局解释器锁在起作用同一时刻只有一个线程能执行字节码。再比如你的 Java 服务里两个线程同时往一个HashMap里塞数据程序偶尔卡死或者数据对不上——根子在于这两个线程共享了同一块堆内存却没有做互斥。还有一类现象是资源层面的你的程序被系统杀掉OOM Killer日志里啥也没留下这时候要看的不是线程栈而是进程整体的内存占用曲线。反过来如果只是某个请求卡住、其他请求都正常那问题往往落在某一条线程身上去 dump 线程栈比看进程信息管用得多。能分清这是进程级问题还是线程级问题排查效率能差出好几倍——这是我做了几年线上排查之后最实在的体会。2. 进程到底是什么从程序文件到运行中的实体2.1 进程控制块里究竟装了什么操作系统管理进程靠的是一个叫**进程控制块PCB**的数据结构。在 Linux 内核里它对应task_struct。这个结构体里装的字段相当多但按功能归类就清晰了标识信息PID、父进程 PIDPPID、用户 ID、组 ID。状态信息当前是就绪、运行还是阻塞退出码是什么。调度信息优先级、调度策略、已用 CPU 时间、剩余时间片。内存信息页表基址、代码段/数据段/堆/栈的边界。上下文信息CPU 寄存器的快照、程序计数器PC、栈指针SP。资源信息打开的文件描述符表、信号处理表、工作目录。其中上下文信息是最值得单独拎出来说的。CPU 上的寄存器是物理资源只有一套进程有几百个怎么让它们轮流用答案就是在切换的时候把当前进程的寄存器值存进 PCB再把下一个进程的寄存器值从 PCB 恢复回去。这个动作叫上下文切换。注意上下文切换不是免费的。除了寄存器存取还会带来 TLB 失效和 CPU 缓存污染这部分隐形成本往往比寄存器搬运本身大得多。这也是为什么线程数开得越多越快是错觉——切太频繁光切换就把时间吃光了。2.2 进程状态与 Linux 里的对应关系教科书上一般讲三态或五态模型新建、就绪、运行、阻塞、终止。这套模型的价值在于理解进程为什么没在跑。很多时候你的程序看起来卡住了其实它处在阻塞态等 I/OCPU 一点没浪费而另一种情况是它明明在跑可 CPU 就是不给你时间片那说明系统里有更高优先级的东西在抢。Linux 用单个字母表示状态ps命令的 STAT 列就是这个状态码含义典型场景R运行或可运行正在算或在就绪队列排队S可中断睡眠等网络、等用户输入收到信号能醒来D不可中断睡眠等磁盘 I/O 完成连 kill 都杀不掉T停止被 SIGSTOP 暂停或被调试器挂起Z僵尸已退出但父进程还没回收退出码D状态特别值得记住。你有时候会碰到一个进程kill -9都杀不死网上一堆人说是卡死了其实它多半在D状态等硬件 I/O 返回内核不允许在这种状态下被打断只能等 I/O 超时或者把底层设备问题解决掉。这种情况下反复执行 kill 除了浪费你的时间没有任何用正确的做法是去看dmesg里有没有磁盘报错。2.3 创建与销毁fork、exec 和那两个让人头疼的孤儿Linux 下创建进程的经典方式是fork()。它有个很讨巧的设计调用一次返回两次——父进程里拿到子进程的 PID子进程里拿到 0。刚 fork 出来的子进程几乎是父进程的完整副本但 Linux 用了**写时复制COW**来省内存父子进程先共用同一份物理页谁写谁才复制。fork之后通常会紧跟exec系列函数把新程序加载进当前进程的地址空间。所以启动一个新程序在内核看来是两步先复制一个壳再把内容换掉。这个设计看着绕但它带来了一个巨大的好处——可以在 exec 之前自由地修改子进程的环境比如重定向文件描述符、切换用户、调整资源限制。Shell 里的管道ls | grep txt就是这么实现的。销毁这块有两个经典概念孤儿进程父进程先退出了子进程被 initPID 1收养。这本身没危害。僵尸进程子进程退出了但父进程迟迟不调用wait()回收退出码就一直挂在那儿占着 PCB。数量少没关系数量一多就会耗尽 PID 资源。实操心得写服务端程序时凡是自己fork或者创建子进程的地方一定要配上wait或waitpid。我更推荐直接用语言层面的封装Python 的subprocess、Java 的Process.waitFor()它们默认会帮你回收省得自己漏掉。排查僵尸进程用ps aux | grep Z就能一眼看到。3. 线程到底是什么进程内部的执行流3.1 线程私有和共享的资源清单理解线程最有效的办法是把它私有和共享的东西列清楚。这个清单我建议直接背下来因为在排查并发问题时你会反复用到它。线程私有的部分栈每个线程有自己的调用栈所以局部变量天然是线程安全的除非你把地址传出去。寄存器和程序计数器这是线程能被独立调度的前提。线程本地存储TLS像 Java 的ThreadLocal、C 的__thread变量都挂在这里。errno这是很多人忽略的一点errno是每线程独立的否则多线程下错误码会互相覆盖。进程内所有线程共享的部分代码段、全局变量、堆内存。打开的文件描述符、socket 连接。当前工作目录、用户 ID 等进程级属性。信号处理函数但信号屏蔽字是每线程的。这张清单解释了一个高频疑问为什么两个线程改了同一个全局变量会出问题而两个局部变量不会因为全局变量在堆或数据段全进程共享局部变量在各自的栈上物理上就不是同一块内存。3.2 线程模型用户级、内核级和多对多线程的实现方式不是一个定论历史上有过好几条路线。用户级线程完全在用户态实现内核根本不知道线程的存在只看到一个进程。好处是切换极快不需要陷入内核坏处是致命伤——如果一条线程发起了阻塞系统调用整个进程都会被挂起因为内核只看到一个执行体。内核级线程由内核直接管理每个线程都是内核眼里的一个调度实体。好处是能真正并行跑在多核上一条线程阻塞不影响别的线程代价是切换需要陷入内核开销更大。多对多模型是折中方案把若干个用户线程映射到若干个内核线程上。Go 的 goroutine 调度器就是典型代表M 个内核线程、N 个 goroutine、P 个逻辑处理器靠GOMAXPROCS控制并行度。这也是为什么 Go 能轻松开出几十万 goroutine 而线程数只有个位数——调度在用户态做了一大部分。3.3 从 Linux 内核角度看线程其实就是个普通的任务这一点很有意思也很容易让人迷糊。Linux 内核在很长一段时间里并不单独提供线程这个概念它只有一个统一的调度单位叫 task。你调用fork()创建的是一个资源完全独立的 task调用clone()并传入特定标志位就能创建出与父进程共享地址空间、共享文件描述符的 task——这就是线程。在ps -eLf的输出里你会看到 PID 和 LWP轻量级进程两列同一个进程下的多个线程 PID 相同、LWP 不同。内核调度的是 LWP用户看到的是 PID中间隔了一层抽象。现在主流的 NPTL 实现是 1:1 模型一个用户线程对应一个内核 task。提示正因为线程和进程在内核里是同一类东西你才会看到一些奇怪的数字。比如 Java 程序启动后ps -eLf里线程数远大于你手动创建的线程数因为 JVM 自己会起 GC 线程、编译线程、信号处理线程等一大堆后台线程。4. 进程与线程的核心差异对照4.1 一张表把差异摊开讲光靠文字描述容易飘直接上对照表更实在。这张表里的数字是量级参考具体值受硬件、内核版本、负载影响很大别当成绝对值用。对比维度进程线程资源分配单位是独占地址空间否共享进程地址空间调度单位是历史上现在 Linux 统一按 task 调度是CPU 分配时间片的直接对象创建开销较大需要复制页表、文件表较小只需建栈和上下文上下文切换开销较大涉及地址空间与 TLB较小同进程内不换地址空间通信方式管道、消息队列、共享内存、Socket 等直接读写共享变量需同步隔离性与健壮性强一个进程崩了不影响别的弱一个线程崩了整进程陪葬典型数量级几十到几百几百到几千视栈大小和内存关于创建开销的量级我在常见 x86 服务器上观察到的经验值是创建一个线程大概在几微秒到十几微秒区间创建一个进程因为要处理页表和地址空间通常在几十微秒往上上下文切换方面线程切换往往比进程切换快一个数量级左右。这个差距的主要来源不是寄存器保存而是地址空间切换导致的 TLB 刷新和缓存失效。同一进程内的线程切换不需要换页表基址TLB 里缓存的地址映射还能继续用所以便宜得多。4.2 开销差异到底体现在哪几个环节很多人只知道线程比进程轻但说不清轻在哪。我自己梳理下来是四个环节第一是创建。进程创建要分配新的页表、复制或共享父进程的内存映射、初始化一堆内核结构线程创建只需要在已有地址空间里划一块栈出来其他全都能复用。第二是切换。进程切换要换页表基址寄存器x86-64 上是 CR3换完之后 TLB 里的映射基本全作废后面几条内存访问全得走慢路径重新查页表。线程切换不换 CR3TLB 命中率保持得比较好。第三是通信。进程之间要传数据得靠内核中转管道、消息队列或者专门映射一块共享内存前者有拷贝开销后者要自己处理同步。线程之间直接读同一个变量就行但代价是你得自己加锁。第四是退出与回收。进程退出要把整个地址空间归还给系统关闭所有文件描述符通知父进程线程退出只需释放自己的栈进程范围内的资源一个都不用动。我踩过的一个坑值得说一下早期我写过一个数据处理程序为每一批数据起一个新进程跑逻辑上完全没问题但跑起来慢得离谱。后来用time一量发现光进程创建和销毁就占了总耗时的三成多。改成进程池复用之后整体时间直接降下来了。结论就是需要频繁启动执行的短任务永远优先考虑池化复用别裸起。4.3 什么场景选哪种别再凭感觉选型的核心判断标准其实就两条任务之间需不需要共享大量数据以及单个任务崩了能不能拖垮整体。需要共享大量状态、且任务之间协作紧密的用多线程。比如一个 HTTP 服务器所有请求处理线程都要访问同一份缓存和连接池用多进程就得处理跨进程共享问题麻烦度陡增。任务之间相对独立、单个任务崩溃不能影响其他的用多进程。比如一个数据管道里某个环节处理畸形输入时可能崩溃或者内存暴涨隔离成独立进程之后主进程只要重启它就行。还有一个现实约束绕不过去语言运行时的限制。CPython 因为有 GILCPU 密集型任务用多线程基本没有收益必须用多进程或者换成能释放 GIL 的 C 扩展。而 I/O 密集型任务用多线程就够了因为线程在等 I/O 的时候会释放 GIL。Java 的情况不同Java 线程和内核线程是一对一的多线程能真并行所以 Java 里 CPU 密集任务用线程池是常规操作。同样是多线程三个字在不同语言里的含金量完全不同这点一定要先确认清楚再动手。5. 通信与同步绕不过去的两块硬骨头5.1 进程间通信的六种常见方式进程之间是隔离的要交换数据必须借道内核或者共享内存。常见手段有这么几种各自适用场景差别挺大方式适用场景主要特点匿名管道父子进程简单传数据单向、字节流、有缓冲区命名管道FIFO无亲缘关系进程通信以文件形式存在可多进程读写消息队列有格式的消息传递保留消息边界可按类型取共享内存高频、大数据量交换性能最好但必须自己做同步信号量控制对共享资源的访问计数常与共享内存配合使用Socket跨机器、跨语言通信通用性最强可以走本机回环共享内存是性能天花板最高的方式因为数据不进内核、不做拷贝直接映射到两个进程的地址空间里。但它也是坑最多的读写位置、数据完整性、并发访问顺序全都要自己管稍不注意就是脏数据。Socket 是通用性最好的方式本机通信走 Unix Domain Socket 的话性能也不差而且天然支持跨机器扩展。我在做跨语言模块拼接的时候基本都选 Socket 而不是共享内存原因就是调试成本低太多——出了事可以用tcpdump或者日志直接看共享内存出了问题基本只能靠猜。5.2 线程同步手段与死锁的四个必要条件线程共享内存所以必须加同步。常用手段有互斥锁、读写锁、条件变量、信号量、原子操作。选用的基本原则临界区短且频繁访问的用原子操作或自旋锁临界区长或者可能阻塞的用互斥锁读多写少的用读写锁。我见过不少人一上来就无脑加互斥锁结果读多写少的场景下性能极差换成读写锁之后吞吐量翻好几倍。然后就是死锁。它的形成需要四个条件同时满足缺一不可互斥资源同一时刻只能被一个线程占用。持有并等待拿着一个锁的同时去等另一个锁。不可剥夺锁不能被强行抢走只能主动释放。循环等待A 等 B 持有的锁B 等 A 持有的锁。打破死锁的思路就是破坏其中任意一条。工程上最实用的做法是破坏第四条给所有锁定一个全局顺序所有线程一律按这个顺序加锁。比如规定必须先拿用户锁再拿订单锁任何代码都不允许反过来写。这条规则简单粗暴但极其有效。注意还有一个容易忽视的问题是锁顺序不一致导致的隐式死锁。你以为两个模块各自加锁没问题但 A 模块持有锁 1 时调用了 B 模块的接口B 模块内部又要拿锁 2而另一条路径正好相反——死锁就这么产生了。涉及跨模块调用时务必把锁的持有范围画出来看一眼。6. 动手实操亲手看到进程和线程6.1 命令行观察实践概念讲再多不如自己动手看一眼。Linux 和 macOS 下这几个命令建议都跑一遍# 看所有进程的资源占用按 CPU 倒序 ps aux --sort-%cpu | head -20 # 看某个进程里的所有线程PID 相同LWP 不同 ps -eLf | grep 12345 # 实时看某个进程的各线程 CPU 占用 top -H -p 12345 # 直接读内核暴露的进程信息 cat /proc/12345/status ls /proc/12345/tasktop -H -p PID这个组合是我用得最多的。加-H之后每个线程单独一行显示你能立刻看出是哪个线程在吃 CPU。有一次线上服务 CPU 告警进程级看只显示 300%用-H一展开发现是一个日志压缩线程占了其中 280%——问题定位时间从半小时缩到了两分钟。再配一个pidstat -t -p 12345 1可以按秒粒度输出每个线程的 CPU 和上下文切换次数。上下文切换次数这个指标特别有价值如果每秒切换次数在几万甚至几十万说明锁竞争或者线程数配置有问题这时候加 CPU 是没用的。macOS 用户可以用sample命令抓线程栈功能和 Linux 的perf类似。Windows 那边任务管理器默认只到进程级想看线程得切到详细信息标签右键列标题勾上线程数。更推荐用 Sysinternals 出的 Process Explorer双击进程就能看到线程列表和每个线程的栈排查起来直观得多。6.2 最小代码实验验证私有栈和共享堆光看命令还不够得写几行代码验证一下。下面这个 Python 例子演示了局部变量和全局变量的差异import threading counter 0 # 全局变量在堆/数据段被所有线程共享 ITER 200000 def add_global(): global counter for _ in range(ITER): counter 1 def add_local(): local 0 # 局部变量在每个线程自己的栈上 for _ in range(ITER): local 1 return local if __name__ __main__: ts [threading.Thread(targetadd_global) for _ in range(5)] for t in ts: t.start() for t in ts: t.join() print(期望:, 5 * ITER, 实际:, counter)跑下来你会发现counter的值小于期望的 1000000。原因就是counter 1不是原子操作它包含了读、加、写三步两个线程交错执行时会互相覆盖。而add_local里的local无论跑多少次结果都准确因为它落在各自的线程栈上物理上不共享。把这个例子记住它解释了多线程编程里至少一半的 bug。修法也很直接加锁或者用语言提供的原子类型比如 Java 的AtomicInteger、Python 的threading.Lock。6.3 线程池和进程池的参数到底怎么算池化是工程上的标配但参数怎么定很多人是拍脑袋的。这里给一个能落地的算法。对于 CPU 密集型任务理想线程数是核心数 1。为什么加 1因为偶尔会有缺页中断之类的原因导致线程短暂停顿多出的那一个能把 CPU 空档填上。加更多没用因为 CPU 本来就跑满了。对于 I/O 密集型任务用这个公式线程数 核心数 × (1 等待时间 / 计算时间)举个具体例子假设机器 8 核任务平均要等 90 毫秒的网络响应真正计算只用 10 毫秒。那么线程数 8 × (1 90 / 10) 8 × 10 80这个数字的意思是要维持 8 个核都在干活需要大约 80 条线程同时在跑因为每条线程有九成时间在等。实操心得公式算出来的是理论上限实际配置时要留出余量而且别把队列设成无界的。无界队列在流量突增时会把任务堆到内存里最后 OOM 而不是优雅拒绝。我一般把队列容量设成线程数的 2 到 4 倍超过就触发拒绝策略并打点告警这样压力能被及时看到。另外池的大小必须通过压测校准。公式给的是起点不是终点。我通常的做法是先用公式设定初始值然后用压测工具从初始值的一半开始逐步加压观察吞吐量和响应时间的拐点拐点之前的最大值就是比较合适的配置。这个流程虽然笨但比任何公式都可靠。7. 高频问题与排查实录7.1 问题速查表下面这些是我在实际工作中反复遇到的问题整理成表方便对照现象常见原因排查方向CPU 占满但找不到大进程多线程任务分散占用top -H按线程展开查看进程杀不掉kill -9无效处于不可中断睡眠D 状态dmesg查磁盘/硬件报错服务卡住无日志输出死锁或线程池耗尽dump 线程栈查锁持有关系文件/设备无法卸载或弹出仍有进程持有文件句柄lsof f -- /挂载点查占用者包管理工具报另一个进程已加锁前一次操作未正常结束确认无残留进程后清理锁文件程序退出后仍有子进程存活未回收或未随父进程退出检查wait调用与守护线程设置多线程计算结果偏小共享变量竞争未加锁加锁或改用原子类型关于包管理锁这个问题多解释一句报错信息里通常会给出锁文件路径。正确处理顺序是先确认确实没有正在运行的包管理进程再清理锁文件最后重新执行命令。直接删锁文件而不确认有可能破坏正在进行的安装流程把系统搞成半损坏状态。判断依据很简单用ps搜一下对应的进程名没有结果就说明是上次异常中断留下的残留。7.2 几个容易踩的坑和对应技巧第一个坑线程数越多越好。这是我见过最普遍的错误认知。线程多了之后上下文切换开销飙升锁竞争加剧缓存局部性变差性能是往下走的。判断标准很简单如果pidstat显示的每秒上下文切换次数远超每秒处理的任务数说明线程开多了。第二个坑把守护线程当普通线程用。守护线程daemon thread的特点是主线程一退出它就被强制结束不会等它跑完。如果你在守护线程里做数据落盘程序正常退出时很可能丢数据。凡是涉及写文件、发请求这类必须完成的事情一律用非守护线程并显式join等它结束。Java 里的做法是把setDaemon(true)从代码里拿掉用ExecutorService.shutdown()加超时等待来控制退出。第三个坑线程池里执行的任务悄悄抛异常。用execute提交的任务如果抛了未捕获异常异常会被吞掉你只看到任务没执行完却找不到任何日志。我现在的习惯是提交给线程池的任务一律用submit拿Future或者在最外层包一层 try-catch 把异常打到日志里。这个习惯帮我省了不止一次线上排查时间。第四个坑以为进程隔离就绝对安全。进程之间内存是隔离的但如果它们访问同一份文件、同一个数据库、同一个共享内存段该出的并发问题一样会出。我见过有人把多线程改多进程之后随机数据错乱的问题依然存在最后发现是多个进程同时往一个文件追加写入且没有加文件锁。隔离的是内存不是外部资源。第五个坑忘了异步上下文传递。用ThreadLocal存用户身份、链路追踪 ID 的时候一旦跨线程池执行这个值就丢了。解决办法是用语言或框架提供的可继承版本或者提交任务时手动把上下文快照传进去。这个坑在微服务项目里几乎人人都会踩一次早做封装能省很多事。最后再分享一个小技巧。想快速判断一个服务是 CPU 瓶颈还是 I/O 瓶颈不用装一堆工具两条命令就够top看 CPU 使用率和waI/O 等待占比pidstat -d看磁盘读写量。如果 CPU 高而wa低就是计算密集往优化算法和减少锁竞争方向走如果 CPU 不高但响应慢、wa很高那就是 I/O 密集考虑加缓存、批量读写或者调整线程池的并发度。这个判断我几乎每周都用一次比看监控大屏更快尤其在紧急排查的时候。进程和线程这块基础说到底就是一句话资源按进程分配时间片按线程分配共享带来效率也带来风险。后面的线程池调优、锁优化、并发模型选型全是从这句话长出来的分支。这篇把地基铺完下一篇可以接着聊上下文切换的量化测量、锁的粒度设计以及几种并发模型在生产环境里的真实表现。