面试过几轮技术岗的人，十有八九被问过一个问题：进程和线程的区别。我当年第一反应是背教科书，把“进程是资源分配的最小单位，线程是CPU调度的最小单位”这种标准答案甩出去。直到有阵子我半夜处理线上故障，盯着Dump文件里上百个线程不知所措，才发现这句教科书式总结其实解决不了多少实际问题。
这篇文章我不打算写成操作系统讲义，而是想从“一个写业务代码的人真的用得上”的角度，把进程和线程的区别彻底拆开：两者的本质分工、创建和切换的成本差距、通信和同步的差异、以及什么样的系统该选哪种模型。如果你正准备面试、在写并发代码、或者只是被“多线程怎么又崩了”折磨过，这篇应该能给你一些可以直接拿去用的判断依据。
1. 本质差别：进程是“车间”，线程是“工人”
把进程和线程区别讲得最透彻的一个比喻，我见过的是“车间和工人”。车间有自己的厂房、设备、物料、电路系统，车间之间物理隔离。工人是车间里的实际操作者，共享车间里的设备和物料，配合干活效率很高，但一个工人捅了娄子，整个车间可能跟着遭殃。这个比喻把两个关键差异都点到位了：谁持有资源，谁在执行代码，以及隔离和协作之间天然存在矛盾。
1.1 为啥要拆成进程和线程两个概念
早期操作系统其实只有进程，没有线程。那时候程序是串行执行模型，一个进程就是完整独立的执行单元，包含地址空间、打开的文件表、信号处理器、环境变量、工作目录等一大堆资源。但进程有个很麻烦的毛病：创建和销毁的成本太高，进程间通信也太费劲。
想象一下你用多个进程做一个实时数据处理系统，每个数据流一个进程，它们随时要把结果共享给下游。进程之间地址空间互相隔离，你想传个数据得走管道或者消息队列，在内核态和用户态之间来回拷贝，慢得让人抓狂。于是操作系统设计者想了个办法：把“资源”和“执行”这两件事拆开。进程这个角色只负责持有资源、提供隔离，而真正要在CPU上跑的执行流，交给一个新的概念——线程。
一个进程可以拥有多个线程，这些线程共享进程手里的内存、文件描述符、信号处理函数。每个线程只保留执行代码真正需要的那点私有数据：程序计数器、寄存器集合、栈空间和线程局部存储。
这是理解所有后续差异的地基：进程是资源的所有者，线程是资源的借用者。线程自己几乎没有“财产”，全是向进程借来的。所以线程能共享全局变量、堆内存和文件句柄，代价是线程之间没有天然隔离。
1.2 创建与销毁成本差了一个数量级
我实际测过创建1000个线程和1000个进程的耗时差距，线程通常是毫秒级，进程则是秒级。这个数量级差异背后是操作系统的具体实现逻辑。
在Linux里，线程创建本质上是给clone系统调用传入一组标志位，比如CLONE_VM | CLONE_FILES | CLONE_SIGHAND，意思是“我要和父进程共享地址空间、共享打开的文件表、共享信号处理方式”。进程创建走的是fork + exec，fork要复制调用者的页表，exec再装载新的可执行文件。虽然是写时复制技术让fork不用真的复制整个内存，但是页表这种元数据还是得实打实复制一份。进程地址空间越大，页表项越多，复制成本就越高。
这里有个特别反直觉的点：写时复制让fork只拷贝页表不拷贝物理内存，看起来像是“空头支票”，问题是即便只是页表，一个占用2GB内存的进程也可能有几十万个页表项，CPU没办法这么轻描淡写。所以生产环境极少在请求路径上直接频繁fork，都是提前开进程池。
线程的销毁也比进程便宜得多。进程退出时要回收页表、关闭文件描述符、清理信号处理器、释放所有用户态内存；线程退出只需要回收内核栈、用户栈和线程控制块，剩下的共享资源继续由进程持有，谁也不用动。套用刚才的比喻：关掉一个车间，要处理的设备材料一大堆；让一个工人下班，把桌子收拾干净就行。
2. 调度与切换：开销差距在哪，源码级别拆开看
很多人把“线程切换比进程切换快”挂在嘴边，但具体快在哪、为什么快，说清楚的人不多。你得理解上下文切换到底做了什么，才能真正知道它在你的系统里占多大比重。
2.1 上下文切换实际做了什么
CPU执行线程时，相关的执行状态都躺在寄存器里：程序计数器、栈指针、通用寄存器、浮点寄存器、状态寄存器。一旦调度器决定切换到别的任务，它必须把当前这一整套状态保存到内存里，再把新任务之前保存的状态恢复。
进程切换比线程切换多一步非常要命的操作：切换地址空间。地址空间切换意味着页表寄存器要指向新的页表，而页表一换，TLB缓存基本全废，后面每次内存访问都要重新翻译虚拟地址到物理地址，这会导致大量的缓存缺失。缓存缺失对性能的影响远比大多数人想象得大——访问寄存器是纳秒级，访问L1缓存是1到2纳秒，而访问一次主内存要几十纳秒。一次进程切换造成的TLB击穿，后续几百次内存访问都在给这个冷启动买单。
所以同样是切换，线程切换可能在微秒级别，进程切换可能到几十微秒甚至更高。你说“线程切换比进程快”没问题，但要补一句：快就快在不用换地址空间、不用把TLB全部掀翻重来。
2.2 并发、并行与时间片的关系
还有一个高频混淆点：并发和并行。并发是多个任务交替执行，宏观上看起来同时，微观上每个瞬间只有一个任务在跑；并行是多个任务真正同时跑在不同CPU核心上。单核CPU上，多线程只能并发，多核才能并行。
这跟进程线程的差异有什么关系？有大关系。一个进程内多个线程共享地址空间，如果这堆线程被调度到不同核心上并行执行，它们之间读写共享数据时不需要走IPC，直接读写同一块内存就行——快，但需要锁。反过来多进程并行时，各算各的，天然井水不犯河水，但结果要汇总时麻烦来了：得序列化、打管道、发消息队列，一整套绕远路。
有人在高并发项目里坚持用多进程，理由是隔离性好；有人坚持用多线程，理由是共享数据方便。这两种选择都没错，但他们都得接受各自的隐含成本。多进程的隐含成本是协作开销，多线程的隐含成本是锁竞争和同步复杂度。谁也跑不掉。
3. 通信与同步：进程靠“快递”，线程靠“黑板”
为什么进程之间要搞那么复杂的IPC，而线程之间好像随便访问变量就行？答案还是回到地址空间。进程之间物理隔离，想交换数据必须通过内核转一手；线程共享同一块黑板，谁都可以往上写，问题是写的人多了，黑板就被写得乱七八糟。
3.1 线程为什么需要加锁，死锁又是怎么闹出来的
举个最经典的电商库存例子。库存只有300件，两个线程同时读到300，各自减1，然后同时写回299。好了，两次卖出只消耗了一件库存，超卖事故就这么来的。解决办法是加锁：同一时刻只放一个线程进临界区操作库存。
互斥锁的底层实现听起来简单，但每条路都有坑。现代CPU上，锁的基本操作是原子指令，比如x86上的lock cmpxchg，它保证从读内存到修改到写回是一个不可分割的整体。再加上内存屏障，防止CPU乱序执行把内存操作顺序搞乱。再高级一点，Linux还有futex机制，线程先乐观地在用户态自旋或者用原子操作尝试，万一抢不到锁才进入内核态挂起。这套设计让大多数场景下获取锁不需要进入内核，性能才过得去。
但是加锁可不是免费午餐。每次加锁解锁都有原子操作开销，锁竞争激烈时线程会被挂起，陷入内核态，这个代价是微秒级的，远超普通执行一条指令。所以有人一谈多线程就说“性能不好”，很多时候不是线程慢，是锁竞争和上下文切换吃掉了收益。
死锁更要命。死锁的四个必要条件：互斥条件、持有并等待、不可剥夺、循环等待。生活化例子就是：A拿了面包，B拿了果酱，A等着B给他果酱，B等着A给他面包，两个人谁都不肯先放手，谁都吃不上早饭。写代码时避免死锁最实用的两个办法是：全局统一加锁顺序、尽量用超时锁try_lock。前者从设计上保证不会出现循环等待，后者即使出现循环等待也能通过超时解锁，把活结解开。
3.2 进程间通信的几种姿势，谁最快谁最稳
进程间通信的方法，按使用频率排个序：
| 通信方式 | 特点 | 典型应用场景 |
|---|---|---|
| 管道/命名管道 | 半双工、按字节流传递，简单但单向 | 父子进程传命令、日志传递 |
| 消息队列 | 内核维护的消息链表，有界、持久化 | 解耦生产者和消费者 |
| 共享内存 | 两块进程内存映射到同一块物理内存，零拷贝 | 大数据量高频交换，性能要求极高的中间件 |
| 信号量 | 本质是计数器，用来同步而不是传数据 | 多进程访问共享资源时控制临界区 |
| 信号 | 系统异步通知，只能发信号类型，不能带复杂数据 | 通知进程退出、定时、异常处理 |
| 套接字 | 走网络协议栈，跨机器也跨进程 | 分布式系统、跨主机服务间通信 |
我用过最坑的是消息队列。它好用归好用，但每条消息从发送进程的内核缓冲拷贝到接收进程，如果消息量大，拷来拷去的开销大到你想哭。这就是为什么高性能系统迷恋共享内存：共享内存直接把同一块物理内存映射到多个进程的虚拟地址空间，写进去读出来不需要经内核再拷贝一次，相当于快递直接送到你抽屉里，不进快递柜。但共享内存最大的坑是要自己维护同步，抢不到正确顺序，数据就乱了套。你把它想成一个所有进程共享的黑板，谁都能写，写之前得约定信号量协议。没有这层约定，黑板上最后留下的一定是一团乱码。
我自己的经验是：能用共享内存解决的高频数据交换，一般不会选消息队列；但数据量不大、频率不高、对开发效率要求更高的场景，消息队列写起来省心得多。选之前想清楚你的瓶颈到底是不是“拷贝开销”。
4. 实战选型：这些经典软件为什么这样选
教科书讲完原理，真正的考验来了：我手头这个系统，到底用多进程还是多线程？与其拍脑袋，不如看看那些在设计上反复被验证过的经典系统是怎么选的，以及为什么这么选。
4.1 浏览器、Redis、Nginx、Python 各自的答案
现代浏览器是“多进程”最坚定的支持者。每个标签页开一个渲染进程，是为了做到两件事：一是崩溃隔离，一个页面崩了不能带着整个浏览器一起下葬；二是安全沙箱，不同站点的数据访问要互相隔离，不能共享地址空间。这是稳定性和安全性优先于性能和内存开销的典型案例。浏览器多跑几个进程，内存多占一些无所谓，只要不把用户体验毁了就行。
Redis是“单线程+事件循环”的经典代表。你可能会奇怪：一个性能这么强的数据库，为什么不用多线程/多进程榨干多核？因为Redis的瓶颈根本不在CPU，它在网络IO和内存访问上。单线程模型避开了锁竞争、避免了上下文切换，用IO多路复用（epoll）把网络事件串起来跑，简单的内存KV操作本身快得飞起。Redis 6之后虽然引入了多线程，但多线程只负责网络包收发，核心命令执行依然是单线程。这说明一个特别重要的道理：你优化的应该是真正的瓶颈，而不是表面上的并发度。
Nginx走的是master进程管理+多个worker进程的路线。worker进程之间通过共享内存做缓存，master统一管理配置加载和worker生命周期。为什么不用多线程？Nginx的描述是：线程不如多进程稳定、不好做特权分离、也难利用多核。多进程天然支持平滑升级和热加载——master创建新配置的worker，老worker慢慢退场，整个过程中无需停机。
Python这边是另一个极端。CPython解释器有个全局解释器锁，下称GIL，这把大锁保证了整个解释器进程同一时刻只能执行一个线程的字节码。于是纯计算型任务你开四个线程，四个线程在抢同一把锁，实际加速比几乎为零。所以Python社区对付CPU密集任务，人手一个多进程+进程池方案，通过队列把结果收集回来。注意，IO密集场景就不一样了，线程在等待网络响应或者磁盘IO时会让出GIL，所以用Python写爬虫、API网关时多线程依然有显著的收益。
这四个案例放到一起，你会发现选型逻辑惊人的一致：先明确你的瓶颈，再考虑隔离需求和安全约束，最后才落到进程和线程哪个顺手上。
4.2 一张决策表终结选型纠结
我整理了一个可以直接拿来参考的决策表，你在实际项目里对接自己的情况做判断即可。
| 系统特征 | 推荐模型 | 决策理由 |
|---|---|---|
| 高并发IO、请求量大（网关、爬虫、聊天服务） | 多线程或协程 | 切换成本低、内存占用小，IO阻塞时自动让出CPU |
| CPU密集型计算、追求多核扩展 | 多进程（或选本就没有GIL且锁竞争可控的语言/运行时） | 突破线程锁竞争，充分用满多核 |
| 强隔离、安全沙箱、故障不扩散 | 多进程 | 地址空间隔离，崩溃不牵连 |
| 大量共享状态、协作频繁、状态一致性要求极高 | 单线程+事件循环，或加精细锁的多线程 | 减少锁竞争，降低编程模型复杂度 |
| 单机内存数据量极大、要求尽量低拷贝 | 多进程+共享内存 | 绕开IPC拷贝，用物理内存直连 |
我知道有人会把这张表当成“结论”去背，但我建议你把它理解成“权衡起点”。语言生态和团队维护能力经常是比技术模型更重的变量。你在Java里拼命多进程，结果发现JDK的线程池本来就特别成熟；你在Go里纠结多线程还是多进程，结果goroutine已经帮你把调度的复杂性吃掉大半。选择模型之前，先确认你的瓶颈在哪，再确认你的运行环境给了什么现成的轮子。
5. 稳定性与崩溃隔离：进程架构的隐藏优势
教科书讲进程线程区别时往往把“稳定性”放在注脚的位置，可真到了生产环境，这反而是多进程模型最值钱的地方。
5.1 一个线程的野指针怎么搞挂整个服务
进程内所有线程共享同一个地址空间，这意味着任何一个线程把内存写坏了，操作系统检测到非法访问后，直接把这个进程整个干掉，而不是只处理那个肇事线程。同一时间这个进程里的所有线程都会跟着一起陪葬。
我处理过一次挺典型的线上事故。某个清算服务给每个订单开一个线程去做后续处理，线程处理中调用了一个旧SDK，某个数据格式返回异常，一个线程越界写了内存，进程立刻段错误退出。队列里积压的上万个任务全部失败，整个业务链路中断了十来分钟。看Dump时你会发现崩溃的那一行代码几乎没有什么业务意义，就是正常的取值逻辑撞上了脏数据，但地址空间已经全乱了，任何线程都可能踩雷。
有人会想：为什么操作系统不能把这个线程终止掉，保留其他线程？做不到。地址空间是共享的，一旦内存内容被篡改，操作系统根本没法判断其他线程的数据哪些还是可信的。与其冒着继续执行输出错误结果的风险，不如整个进程重启。
5.2 多进程架构如何把故障圈在笼子里
多进程模型的优势在于把故障圈在单个进程内部。还是那个清算服务的重构版本：按业务模块拆成多个worker进程，用master进程管生命周期。一个worker崩了，master立刻拉起一个新worker，最多只有这个worker当时正在处理的那批请求受影响，其他worker毫发无伤。实测下来，系统可用性从“全挂”变成“单模块短暂降级”，对业务的影响范围小了一个数量级。
不过别把多进程想成万能保险。共享内存里的数据如果被写坏了，损坏会传染到所有依附于这块内存的进程。还有僵尸进程和孤儿进程的问题：worker退出后master得负责waitpid回收，不然僵尸进程堆积起来，内核进程表迟早被塞满。多进程模式的运维复杂度，一点不比多线程的加锁复杂度低。
我个人的体会是：如果这个服务跑在线上，价值无法量化，优先选多进程；如果只是内部工具或者重开发速度的脚本，多线程往往更务实。
6. 高频面试题与易错概念辨析
这块直接面向正在准备面试的朋友。很多关于进程线程区别的“送分题”，其实藏着不少答错的坑。
6.1 五个最容易答错的“送分题”
第一题：线程切换一定比进程切换快吗？正确答案是有前提的。同一进程内的线程切换确实快，因为不用切换地址空间。但如果比较的是不同进程里的两个线程切换，那就要切换地址空间了，开销跟进程切换差不了太多。
第二题：创建线程一定比创建进程开销小吗？在Linux上，线程本质是带CLONE_VM标志的clone调用，不需要复制页表，所以通常确实小一个数量级。但在Windows上，进程创建和线程创建的机制和成本差距就没那么悬殊了，所以千万别把“线程创建一定快”当成颠扑不破的真理。
第三题：一个进程最多能创建多少个线程？受虚拟内存限制，线程栈默认8MB，32位系统里3GB用户态空间分下来很快顶到上限；64位系统主要受pthread默认栈大小和实际内容限制。如果你代码里每个线程栈都用到很大，数量上限会显著下降。
第四题：线程之间真的能随便共享一切吗？理论上同一个进程的线程共享地址空间，任何线程只要知道某个变量的地址，就能读写它。你觉得“线程私有”的数据，往往只是逻辑上用线程局部存储包了一层，并不是硬隔离。所以写多线程代码时，别指望操作系统的保护来救你。
第五题：为什么“加线程”经常不能让程序变快？要么是锁竞争太激烈，要么是共享缓存颠簸，要么是Python这类解释器有GIL。多数情况下是线程在抢同一个锁、同一个队列，而不是CPU不够用。加线程解决不了锁竞争，反而会更慢。
6.2 进程、线程、协程到底是什么关系
近几年面试也爱问协程。它们的关系可以看成成本递减的三层结构：进程是内核管理的“重资源+调度单位”，线程是内核管理的“轻资源+调度单位”，协程是用户态自己管理的“极轻调度单位”。
协程厉害在切换完全不需要陷入内核，用户态就能保存和恢复执行栈。一个线程里可以让成千上万个协程轮流跑，哪个协程碰到IO就主动让出来，另一个协程接着跑，整体来看这个线程的利用率被拉满。
Go语言的调度模型就是把协程和线程绑在一起：运行时会把M个goroutine分派到N个系统线程上执行，这叫M:N调度模型。Java 21引入的虚拟线程也差不多，代码看起来是普通线程，底层是跑在载体线程上的“轻量任务”。理解了这个三级结构，你就知道未来不管出什么新并发模型，它都在试图用更少的操作系统参与来换取更高的执行效率。
7. 实测记录：我用几行代码测出了两者的真实差距
最后放一个我自己在本地跑过的简单实验。它不严谨，但能直接帮你建立“体感”。
7.1 测试脚本与实验设计
我用Python做对比，这台机器是4核8线程。第一组测创建开销，第二组测CPU密集求和，第三组测IO密集模拟。
import time import threading import multiprocessing as mp def create_threads(n): t0 = time.perf_counter() ts = [threading.Thread(target=lambda: None) for _ in range(n)] for t in ts: t.start() for t in ts: t.join() return time.perf_counter() - t0 def create_processes(n): t0 = time.perf_counter() ps = [mp.Process(target=lambda: None) for _ in range(n)] for p in ps: p.start() for p in ps: p.join() return time.perf_counter() - t0 n = 1000 print(f"create {n} threads: {create_threads(n):.4f}s") print(f"create {n} processes: {create_processes(n):.4f}s")def heavy_calc(): s = 0 for i in range(10_000_000): s += i return s def run_threads(): ts = [threading.Thread(target=heavy_calc) for _ in range(4)] t0 = time.perf_counter() for t in ts: t.start() for t in ts: t.join() return time.perf_counter() - t0 def run_processes(): ps = [mp.Process(target=heavy_calc) for _ in range(4)] t0 = time.perf_counter() for p in ps: p.start() for p in ps: p.join() return time.perf_counter() - t0 print("CPU heavy threads:", run_threads(), "s") print("CPU heavy processes:", run_processes(), "s")def io_task(): time.sleep(1) def run_threads_io(): ts = [threading.Thread(target=io_task) for _ in range(20)] t0 = time.perf_counter() for t in ts: t.start() for t in ts: t.join() return time.perf_counter() - t0 def run_processes_io(): ps = [mp.Process(target=io_task) for _ in range(20)] t0 = time.perf_counter() for p in ps: p.start() for p in ps: p.join() return time.perf_counter() - t0 print("IO threads:", run_threads_io(), "s") print("IO processes:", run_processes_io(), "s")7.2 结果怎么看，为什么跟你想的不一样
我本地跑了多次，结果稳定在这个范围：创建1000个线程大约0.03到0.05秒，创建1000个进程要1到2秒，差距确实是一个数量级以上。CPU密集那组，4个线程跑在GIL下约2秒出头，4个进程每个分到一个核，约0.6到0.8秒。IO密集那组，20个线程和20个进程都要1秒多，区别不大，线程略快一点点。
这里有个额外的坑值得提：Python的multiprocessing在Linux默认用fork方式创建子进程，启动快；在macOS和Windows上默认是spawn，要重新导入主模块，创建会更慢。所以别拿你在一台机器上跑出来的绝对数值去跟网上任何人的数字硬比，数量级趋势和相对关系才是参考价值所在。
这个实验印证了理论，但也暴露了Python的特殊性。如果你用Java或C++做同样的实验，多线程的CPU密集性能会显著好于Python，因为Java线程可以并行执行。所以在你的语言生态里重新做一次同类实验，比背诵任何博客结论都靠谱。
写到这儿，再回头看“进程和线程的区别”，我最大的感悟是：任何并发模型选择，最终都是“隔离、协作、成本”这三者的权衡。进程多带来的是隔离和安全，代价是通信和切换的昂贵；线程多带来的是协作的便利，代价是共享状态和同步的复杂度。我在后来的项目里养成一个习惯：先画数据流图，标出哪些模块需要高频交换数据、哪些模块可以完全隔离，再决定进程模型和线程模型怎么组合。这比一开始拍脑袋选多线程稳太多了。
最后送一个面试小技巧：被问到“进程和线程的区别”，别直接背定义，试着拿你熟悉的系统举例——比如浏览器为什么多进程、Redis为什么单线程——从约束条件反推解决方案，这种回答方式比标准答案更能体现你对系统设计的理解。
