进程与线程的区别：从原理到线程池与线上排查实战

进程和线程的区别，我面试过的人里十个有八个能背出“进程是资源分配的最小单位，线程是CPU调度的最小单位”，但你再追问一句：你在 Linux 上用 top 看到一堆 pid，怎么知道某个进程里跑着几个线程？哪个线程把 CPU 打满了？能答上来的就没几个了。这篇我就从理论、原理、代码到排查实战，把这个老生常谈又容易含糊的话题彻底捋一遍，尽量写得像个有经验的同事在工位上跟你唠，而不是教科书复读。

先说清楚这篇的定位：适合写过一些并发代码、但总觉得知识是拼凑起来的同学，也适合准备面试、想要一整套完整答案的人。我会把进程和线程到底差在哪、各自适合什么场景、线程池参数怎么算、以及我踩过的那些经典的坑串起来讲，你不光能背概念，还能拿去排查线上问题。

1. 先搞清楚基本概念：进程和线程到底是个啥

1.1 进程：操作系统眼里的一整块“领地”

进程是什么？最直白的理解，就是你双击鼠标或者敲下命令后，操作系统给这个程序分配的一整套运行环境。这套环境包括独立的虚拟地址空间、代码段、数据段、堆、栈、文件描述符表、环境变量、信号处理器等等。进程之间默认是互相隔离的，你的进程里改坏了内存，理论上不会直接搞崩另一个进程。

为什么要有这套隔离？最核心的原因是安全和稳定。你可以把每个进程想象成一个独立公司，公司有自己的办公楼层、财务账户和规章制度，别的公司进不来，也拿不走你的账本。浏览器开几个标签页其实经常是多进程的，一个标签页崩溃了，其他标签页还能活蹦乱跳，这就是进程隔离带来的好处。

谈进程就一定绕不开 pid。你在 Linux 上输入 ps -ef，看到的每一行就是一个进程；你在 Windows 任务管理器里看到的每一个“应用”背后，也基本是一到多个进程。进程是操作系统进行资源分配的基本单位，这句话的意思是：操作系统发内存、发文件句柄、发 CPU 配额，都是发到进程头上，而不是直接发到线程头上。

1.2 线程：同一个进程里的“流水线工人”

线程又是什么？它是进程内部的一条实际执行路径。一个进程可以只有一个线程，那就是主线程，程序从头跑到尾；也可以开一堆线程，同时干好几件事。线程之间共享进程的地址空间、全局变量、堆内存、文件描述符，所以线程之间传数据天然方便——大家在一个地址空间里，直接读写变量就行。

但便宜没好货，共享也意味着风险。一个线程写坏了一个指针，整个进程可能直接段错误崩掉；两个线程同时改一个变量，会出现我们常说的竞态条件。线程是CPU调度的基本单位，操作系统每次把 CPU 分配出去，分配的是某个线程，而不是某个进程。你看 top -H 或者 ps -eLf 会看到，同一个 pid 下面能拆出一堆 LWP（轻量级线程），就是同一进程内部的不同线程。

我习惯用这个类比：进程是公司，线程是员工。公司有独立的注册地址、账本和资产，员工在同一栋楼里办公，共享打印机和茶水间。员工之间交流只需要喊一嗓子，但正因为都在一个屋里，谁把茶水间烧了，全公司都得遭殃。

1.3 为什么有了进程还要发明线程

这个问题面试经常问，但很多人只会背“线程开销小”。开销小到底小在哪？我解释得更细一点：进程切换的时候，操作系统要切换地址空间，要换页表，还要把 CPU 缓存、TLB 全部失效，这是一笔非常昂贵的开销；而线程切换发生在同一个进程内部，地址空间不变，页表不用换，只需要保存和恢复线程自己的寄存器状态、栈指针和程序计数器，轻量得多。

除了切换开销，还有通信成本。进程之间要传数据，得非常麻烦地走 IPC（管道、共享内存、消息队列、socket），每一趟都要经过内核或者做数据拷贝；线程之间共享内存，直接读写全局变量就能通信，配合一把锁就搞定。所以当你需要做细粒度的并发、频繁交换数据的时候，线程是更顺手的选择。

一句话总结：进程给你的是隔离和安全，线程给你的是效率和协作。没有线程之前，系统只能靠多进程做并发，但高并发场景下频繁创建进程、切换进程、跨进程通信，代价实在太大了，所以才有了线程。

2. 进程与线程的核心区别，一张表能说清

2.1 资源、调度、切换开销的三组关键区别

如果面试只打算讲三分钟，你就讲这三组区别。

第一是资源拥有。进程拥有独立的地址空间和资源集合，线程共享所属进程的地址空间和大部分资源，每个线程只有自己独立的栈、寄存器和程序计数器。所以进程是资源分配的基本单位，线程是调度的基本单位。

第二是调度与切换。进程切换因为要切换地址空间和刷新页表，开销大；同进程内的线程切换开销小得多。尤其在线程数量不夸张、没有大量锁竞争的情况下，线程来回切换的性能损耗是可以接受的。

第三是容错性。由于地址空间隔离，一个进程崩溃通常不会直接导致另一个进程崩溃；但同一进程里的一个线程如果因为非法内存访问导致崩溃，整个进程连同它的所有线程基本就一起没了。

2.2 通信方式的差异：IPC 和共享内存

面试里问“进程和线程的区别”，经常跟过来的一个问题是“你怎么在进程之间传数据”。进程间通信（IPC）常用的有这么几条路：管道（pipe）、命名管道（FIFO）、消息队列、共享内存、信号量、信号、socket。不同方案各有取舍——管道简单但只能单向流式传；消息队列适合松散耦合的异步消息；共享内存吞吐高但需要自己处理同步；socket 能跨机器，最灵活但也最重。

线程之间通信就简单得多，因为大家共享同一份内存。你需要做的不是“传”，而是“同步”。同步的手段包括 synchronized/ReentrantLock 这类互斥锁、Semaphore 信号量、CountDownLatch/CyclicBarrier 这类协调工具，以及利用 volatile 或原子类保证可见性和原子性。

这里有个特别容易被新手混淆的点：线程同步和线程通信，很多人当成一回事。其实前者是“控制访问顺序，别打架”，后者是“把数据顺利让彼此看见”，但你用共享变量做线程间传值的时候，通常既要解决可见性也要解决互斥性，所以大家习惯性地把锁当成通信工具来用了。严格说，Java 里也有 wait/notify 这种专门做线程间协作通知的机制，C# 里对应的是 Monitor.Wait/Pulse，以及 AutoResetEvent 这类信号量，这才是典型的“线程通信”味道。

2.3 崩溃影响的差异：进程隔离与线程共享

我刚工作那年，见过一个同事调试问题调了半天，最后发现是某个后台线程写坏了一个全局数组，导致整个服务进程崩溃。现场一片混乱，因为线程之间没有隔离，问题定位比其他崩溃更隐蔽。反过来，浏览器多进程架构能这么流行，就是因为它默认“一个页面一个进程”，页面崩溃了，浏览器本体毫发无伤。

所以做架构选型时，隔离需求是很值得认真考虑的。如果你做的是一个广告加载组件，第三方代码质量不可控，你最好把它放到独立进程里跑，崩了也不影响主业务；如果只是自己写的线程池里的任务，崩就崩在同一个进程里，定位排查反而要更小心。

3. 从代码层面看线程的创建、互斥与同步

3.1 Java 里如何创建线程和线程池

Java 创建线程有四种基本姿势：继承 Thread、实现 Runnable、实现 Callable 配合 FutureTask，以及使用线程池。前三种本质都是“造一个线程”，区别在于是否能把执行结果带回来。Runnable 的 run() 没有返回值，Callable 的 call() 可以返回结果、可以抛异常，所以异步拿结果一般用 ExecutorService.submit 配合 Future。

实际生产环境里，我强烈不建议直接 new Thread(...) 去裸奔。原因很简单：线程创建销毁有开销、线程数量不受控制、缺少统一管理和监控。正确做法是交给 ThreadPoolExecutor。

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                      // 核心线程数
    8,                      // 最大线程数
    60, TimeUnit.SECONDS,   // 非核心线程空闲存活时间
    new ArrayBlockingQueue<>(100), // 有界阻塞队列
    new ThreadFactoryBuilder().setNameFormat("order-pool-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);

这段代码里的每个参数都不能瞎填，后面第 4 节我会展开讲怎么算。你只需要先记住：线程池不是“随手 new 一个就行”，核心线程数、最大线程数、队列容量、拒绝策略这四样，直接决定了你的应用在高并发下是优雅排队还是直接 OOM。

3.2 线程互斥和死锁：两个典型坑

线程互斥是并发的基础，但你用好锁不代表高枕无忧，死锁会找上你。死锁的四个必要条件——互斥、持有并等待、不可剥夺、循环等待——教科书背烂了，现实中是怎么发生的呢？最典型的是两个线程用两把锁，顺序反了：

线程 A 拿到锁 1，想拿锁 2；线程 B 拿到锁 2，想拿锁 1。两边都死死攥着已经到手的锁不撒手，于是谁也别想往前走了。排查死锁的办法，Java 里最直接的是 jstack <pid>，线程转储文件里会明确打印出"Found one Java-level deadlock"，并把循环等待的线程栈指出来。

避免死锁我有几条实操经验：能用一把锁解决的就别用两把；多把锁时保证全局加锁顺序一致；能用 tryLock 加超时就不裸用 lock()，拿不到锁就放弃而不是无限等待；能用无锁数据结构（AtomicInteger、ConcurrentHashMap）就尽量少用锁。

3.3 C# 的 WaitOne、中止线程和 Qt 的子线程更新 UI

跨语言看线程，思路是相通的，只是工具不一样。C# 里 AutoResetEvent.WaitOne() 经常被用来让一个线程等待另一个线程发信号。AutoResetEvent 和 ManualResetEvent 的区别在于，前者通知一次只能放行一个等待者，后者可以放行所有等待者，选错的话程序行为会非常诡异。

C# 里有个老话题是“终止线程”。老版本有 Thread.Abort()，我强烈建议你不要用，因为强制中止线程会让资源来不及释放，锁可能永远不解，状态可能半更新。现代 C# 的做法是协作式取消，用 CancellationTokenSource 发出取消信号，线程在合适的检查点主动退出，这才是安全的中止方式。

Qt 里做线程常见的坑是“子线程直接更新 UI”。Qt 的 UI 控件不是线程安全的，你必须在主线程里操作界面。正确姿势是把数据用信号（signal）发射出去，槽函数在接收者的线程里执行，靠 Qt 的跨线程 queued connection 把 UI 更新切回主线程。我一般建议用 QThread 配合 moveToThread 把 Worker 对象挪到子线程，而不是自己重写 QThread::run()，维护起来清晰很多。Android 上 Fragment 里开线程也一样，本质是子线程算数据，Handler/runOnUiThread 回主线程更新 UI，现在更推荐直接用协程，生命周期管理更省心。

4. 线程池与进程池：参数到底怎么配

4.1 线程池核心参数与“线程数方程组”

搜索引擎里天天有人在搜“java线程池核心线程数工作原理”“线程池参数合理配置”，可见这是个高频难题。先说线程池的工作流程，这是理解参数的基础：

任务提交之后，先看当前线程数小于核心线程数吗？小于就新建核心线程干活；大于等于核心线程数，就尝试丢进工作队列；队列也满了，再看当前线程数小于最大线程数吗？小于就新建非核心线程；最多线程也到了，触发拒绝策略。

很多人不理解“核心线程数”和“最大线程数”之间为什么要拉开一段距离。我的理解是：核心线程数代表你日常稳定的处理能力，最大线程数代表你扛峰值时能临时扩张的上限，中间的缓冲靠任务队列吃掉。核心线程数设小了，平时任务排队时间就长；设大了，闲时线程也在白白占资源。

计算“多少线程合适”有一个经验公式，网上有人戏称“线程方程组”：

• CPU 密集型任务：理论上最合适的是 CPU 核数 + 1。加 1 是为了弥补个别线程因为缺页中断、GC 停顿等情况空出的 CPU 时间。
• IO 密集型任务：线程数 = CPU 核数 × (1 + 平均等待时间 / 平均工作时间)。如果一个任务 8 秒里有 7 秒在等 IO、1 秒在算，那么一个线程在处理请求的时间里 CPU 其实只忙了 1 秒，为了让 CPU 尽量不闲着，你可以开到 8 × (1 + 7/1) = 64 个线程。

这公式是经验值不是铁律，但比拍脑袋靠谱得多。真实项目里我还会留 20%-30% 的余量，并且一定要压测调优，生产环境的变化远比公式复杂。

4.2 阻塞队列选型：LinkedBlockingQueue / ArrayBlockingQueue / SynchronousQueue

线程池里的工作队列，选错了后果很严重。我列一个常用对比：

我自己的选型经验是这样的：绝大多数互联网业务，用有界队列 + 恰当的核心线程数最稳妥。LinkedBlockingQueue 不指定容量就是无界，任务一旦爆发式涌入，队列能撑到把内存耗尽，这不是玩笑，我见过线上真的这么挂过。ArrayBlockingQueue 的好处是把积压上限显式暴露出来，配合拒绝策略，宁可让调用方感知压力，也不能让进程静悄悄被拖死。

SynchronousQueue 适合“来了就得干”的场景，比如你在做一个低延迟响应系统，不想让任务排队，那队列容量为零、最大线程数拉高，任务提交时会直接尝试创建线程执行。但线程数量不受控的时候，系统负载会非常快上去，一般需要配合限流。

4.3 什么时候用进程池而不是线程池

说完了线程池，得聊聊进程池。进程池同样是“池化”思想，但池子的成员是进程而不是线程。Python 里的 multiprocessing.Pool 就是典型，它绕开了 GIL 带来的多线程限制，能让多个 CPU 核真正并行跑 Python 代码。生产环境里 Nginx 的 worker_processes、Gunicorn 的 worker 数配置，本质也是进程池。

什么场景应该优先考虑进程池？我的判断标准很简单：第一，你有 CPU 密集型的重计算任务且脚本语言存在解释器锁的限制，比如 Python 多线程遇到 GIL，那就直接用多进程；第二，你需要进程间强隔离，比如执行不可信代码、或者你希望一个任务崩溃不影响主服务；第三，你已经有多机部署的诉求，进程边界和机器边界更接近，后续扩展更加自然。

反过来，如果任务是 IO 密集型的，比如读写数据库、调用第三方 HTTP 接口，那么线程就够用了，因为瓶颈在网络和磁盘，CPU 本身没被占满，没必要加载一堆“重”进程。

5. 进程与线程的实用排查技巧

5.1 如何在 Linux 下查看进程和线程数量

这是我在团队里经常让新人练手的一个问题：线上 Java 服务 CPU 飙升，怎么定位到具体线程？

第一步，看进程级别。top 找到 pid，假设是 12345，CPU 占用接近 100%。第二步，进进程内部看线程，执行 top -H -p 12345，你会看到这个进程下所有线程的 CPU 占用排行，最上面那个线程的 pid 比如是 12345 的某个子线程号 12370。第三步，把线程号转成十六进制，printf "%x\n" 12370，得到 30b2。第四步，执行 jstack 12345 | grep -A 20 "nid=0x30b2"，线程转储里就能看到这个线程当前在跑什么代码了。

至于查进程和线程的总数：ps -eLf | wc -l 能看全系统的线程数，ps -eLf | grep <pid> 能看某个进程的线程列表，pstree -p <pid> 可以用树形结构看进程和线程的父子关系。Linux 下还有一个隐藏目录 /proc/<pid>/task，里面每个子目录对应一个线程。

5.2 能看到的进程有哪些：从 rundll32 到“任务管理器里没有”

Windows 下有个高频搜索词是“rundll32是什么进程”。rundll32.exe 是 Windows 自带的一个进程，专门用来加载 DLL 并执行其中导出的函数。比如某些控制面板项、系统功能、第三方软件安装后的快捷操作，都会通过 rundll32 来触发。它本身不是病毒，但确实有不少恶意程序喜欢借 rundll32 的壳运行，所以看到它先别慌，去任务管理器看它的命令行参数是什么，wmic process where name='rundll32.exe' get commandline 能帮你判断它到底加载了哪个 DLL。一个明显的规律：正常的 rundll32 一般没有可疑的随机文件名参数；如果你看到它带了一堆乱码 DLL 路径，那就得留个心眼，查查启动项和计划任务。

还有人问“为什么任务管理器里看不到某个进程”。常见原因有几个：进程以服务方式运行在 Session 0 里，普通用户会话自然看不到；进程属于另一个登录用户，比如用管理员身份运行的进程在普通用户的任务管理器里可能不显示；还有一类进程是系统受保护进程，比如某些杀毒软件组件，任务管理器默认就不展示。这个问题让我想到一句话：排查进程问题，先学会用 tasklist 命令行，别只盯着 GUI。tasklist /svc 能列出每个进程对应的服务，Get-Process | Select-Object Id,ProcessName,Path 在 PowerShell 里能直接看进程路径。至于热搜里那种“隐藏进程防检测防封号”的做法，我必须多说一句：正经开发不要走这条路，它和恶意软件的技术手段高度重合，而且违背平台规则，我把话说在前头，这类需求本身就不值得做。

5.3 终端进程启动失败: 无法启动 conpty 的排查记录

把热搜里那个报错单独拎出来讲，因为我在 VS Code 和 Windows Terminal 里都撞到过，而且不止一次：

“终端进程启动失败: 启动期间发生本机异常(无法启动 conpty)。已移除 winpty”

这问题本质上是集成终端依赖的 ConPTY（Windows 控制台伪终端）机制启动失败。ConPTY 是 Windows 10 之后提供的一套用于让第三方终端程序接入 Windows 控制台子系统的协议，VS Code、Windows Terminal 都是靠它来模拟终端的。如果 ConPTY 相关的系统组件异常、终端软件版本有 bug、或者环境变量里 TERM 设置不对，就会报这个错。winpty 则是老的兼容方案被移除了，导致老环境直接失去兜底。

我实测过几种管用的处理顺序：第一步，关掉终端面板，重启 VS Code 或 Windows Terminal，30% 的情况是临时性的，重启就好；第二步，检查默认终端 profile，把默认 shell 从 Git Bash 临时切到 cmd 或 PowerShell，再开终端试试，排除 shell 那边的干扰；第三步，更新终端软件到最新版，Windows Terminal 早期版本 ConPTY 支持有不少 bug，新版稳定得多；第四步，如果系统是 Windows 10 老版本，考虑系统更新或者用注册表清理一下 ConPTY 的缓存状态。环境变量方面，TERM 如果被设成了不支持的值也可能触发问题，可以尝试从环境变量里暂时删掉再试一次。总之这问题绝大多数是环境兼容问题，不是你的业务代码问题，别上来就重装系统。

5.4 线程死锁、线程互斥与竞态条件

排查线程相关问题，我建议手里常备这几样工具：Java 的话用 jstack、jstat、jcmd；C++ 的话用 gdb 的 thread apply all bt 拿到所有线程的调用栈；Python 的话用 faulthandler 或者 py-spy dump --pid <pid>。

线程互斥导致的问题，常见的不是死锁，而是竞争条件。比如多个线程同时执行 count++，这一行代码在底层是“读取-加法-写回”三步，A 线程读到了 10，B 线程也读到了 10，两个都加一写回，结果只变成了 11，而不是 12。这就是为什么需要 synchronized、ReentrantLock，或者直接上原子类。注意 volatile 能保证可见性，但不能保证复合操作原子性，很多人踩过这个坑。

线程安全类是个好帮手，但别误以为用了它就绝对安全。ConcurrentHashMap 保证单个方法原子安全，可如果你先 containsKey 判断再 put，中间仍然可能被其他线程插一脚，这种“复合操作”还是需要外部锁。我建议把并发类的线程安全和“业务逻辑的事务性”分开想，前者帮你省了很多内部同步细节，后者还是得你自己锁边界。

5.5 后台进程在跑，但界面打不开怎么办

搜索热词里有一批问题属于这类：“ps在后台进程里有，但是打不开”“codex为什么只有进程，没有页面”“codex修复 一直后台有进程 但是不显示面板”。这类问题十有八九不是程序没运行，而是 UI 层没能正常显示出来。

在 Linux 上最典型的原因是 DISPLAY 环境变量没设，或者 X11 授权丢失。你 SSH 登录后直接跑一个 GUI 程序，程序把头都伸到空气里找显示服务器了。排查命令：echo $DISPLAY，如果没输出，试试 export DISPLAY=:0，如果有权限问题再 xhost +local: 临时放行本地用户。也有的情况是程序 fork 到后台后父进程退出，或者窗口管理器把它丢到了另一个虚拟桌面，找起来都比较曲折。

Windows 上类似的情况，比如 codex 这种 CLI 工具有进程但不显示面板，我遇到的多是终端面板渲染问题，常见解法是重启终端、升级客户端版本、或者在配置里换个终端渲染模式。这类问题排查的核心思路只有一个：先确认进程是不是真的活着，再看它日志里有没有抛显示相关的错误，最后看环境变量/版本兼容性。别一上来就怀疑进程被杀了。

6. 实际项目里的进程与线程选型经验

6.1 多进程加多线程的混合架构

真实项目很少是非黑即白的“只用进程”或“只用线程”。我参与过的几个高并发服务，最终基本都是混合架构：外层用进程做故障隔离和弹性伸缩，内层每个进程再用线程池处理高并发 IO。

举个具体例子，一个消息推送网关，我用 Nginx 做前置接入，Nginx 本身是 master 进程管 worker 进程，每个 worker 进程内部用事件驱动模型处理海量连接；业务层用 Java 服务，JVM 是一个进程，进程内再用线程池去消费 MQ 消息、调用下游接口。这样设计的好处：进程挂了重启进程，线程池满了只阻塞任务提交，不会直接把服务打死。每一层的边界都清楚，监控起来也方便。

反过来，如果只有线程没有进程隔离，一个第三方 SDK 把你整个进程的内存搞炸，所有业务一起陪葬；如果只有进程没有线程，进程间通信的成本会让你写到想吐。所以好的架构师其实是“哪个粒度合适用哪个”，而不是站队。

6.2 守护进程、父子进程和进程守护

关键词里有“父子进程”“守护进程”“进程保护工具”，我一起讲。Linux 里用 fork() 创建子进程，父进程和子进程是父子关系。子进程结束但父进程还没调用 wait() 回收它时，它会变成僵尸进程，这是面试常考点。如果你发现系统里一堆 <defunct> 状态的进程，那就是有进程忘了回收子进程，要注意排查。

守护进程（daemon）是脱离终端、在后台长期运行的进程，典型的就是各种服务程序，比如 nginx、mysqld。它跟 Java 里的守护线程并不是一回事：守护线程是 JVM 的线程，当进程里只剩守护线程时 JVM 就退出；守护进程是操作系统层面的后台服务进程，它需要被具体的进程守护工具管理。

生产环境里我建议用 systemd 或 supervisor 这种成熟的进程守护工具来管你的服务进程，配置“自动拉起”“失败重启”“启动超时”这些策略。不要自己写 while 循环去守护一个进程，那是重复造轮子，而且你永远逃不脱“谁来守护守护进程”的递归问题。

6.3 进程级安全与令牌的一点说明

Windows 下有个冷门问题被搜得很多：进程能不能绑定主身份令牌和多个模拟身份令牌？这里面的概念其实挺清晰：进程的主令牌（primary token）决定了进程大多数权限操作的默认身份；线程的模拟令牌（impersonation token）是线程在执行某些操作时临时采用的另一套身份，常见于服务进程模拟客户端身份去访问资源。两者不是一个层级的东西，进程有一个主令牌，线程可以按需切换模拟令牌，模拟结束后恢复。这个概念在写 Windows 服务、做访问控制时才会用到，日常业务开发不需要过度纠结，但也不要看到“令牌”就往账号密码上联想，它说的是系统权限上下文。

至于“进程保护工具”，我更愿意解释成“让合法进程活得更稳”的运维手段，比如给进程加 systemd 服务自动重启、用 supervisor 监控任务进程、用看门狗（watchdog）检测心跳。这类工具的核心目标不是让别人找不到进程，而是让服务在故障后能够快速恢复，保证可用性。做安全设计时，正确路线始终是最小权限、尽量隔离、完整审计，而不是靠藏。

6.4 给新手的几条判断准则

把前面所有内容压缩成几条判断准则，我平时带人就是这么教的：

先看任务性质。密集计算吃 CPU 的，优先考虑多进程或者增加机器；大量等待 IO 的，多线程性价比更高。

再看隔离需求。第三方不可信代码、容易崩溃的插件系统，放独立进程；自己人写、需要频繁交换大量数据的逻辑，放同一个进程里用线程。

再看开发语言。Java、Go 这种原生并发能力强的，线程是主力；Python 因为 GIL 存在，计算密集任务要多进程；脚本里要真并行，也得多进程。

最后看运维能力。线程问题用 jstack/gdb 能查，进程通信问题往往需要翻协议和消息日志，调试心智负担完全不一样。如果团队排查分布式问题经验不足，优先选线程，把 IPC 的复杂度压到最低。

结尾

个人体会放最后，说点实在的：进程和线程这道题，理解概念只是起点，真正拉开差距的是“你在排障现场能不能快速定位问题”。我在项目里基本坚持一条原则——默认先用线程池解决并发问题，只有明确需要进程级隔离或跨语言独立部署时才上多进程，因为线程问题的排查链路通常更短，jstack 一把梭能看到调用栈，而进程通信的问题往往要在不同进程的日志里来回对，心累得多。最后再补一句，线程池的参数永远不要照抄别人的博客，拿公式估算出来后，扎扎实实做一轮压测，用真实数据说话。这个领域没什么玄学，所有的坑都踩过一遍之后，你就知道哪些话是经验，哪些话只是传说。