Python面试高频题：多进程与多线程到底怎么选？别被GIL忽悠了

每次面试聊到Python并发，十个候选人里有八个会条件反射般地抛出“GIL（全局解释器锁）导致多线程没用，得用多进程”的结论。背八股文确实能应付过第一关，但如果面试官顺势问一句：“那你项目里到底是怎么选的？”很多人就开始抓瞎了。

今天咱们不背干巴巴的定义，直接从底层逻辑和实战场景把这两个概念掰扯清楚。

剥开概念看本质：厨房与厨师

要搞懂区别，得先明白它们在操作系统里的定位。进程是资源分配的最小单位，线程是CPU调度的最小单位。

打个通俗的比方，进程就像是一个个独立的厨房，每个厨房都有自己的食材、锅碗瓢盆（内存空间、文件句柄等资源）。厨房之间是隔离的，互不干扰。而线程则是厨房里的厨师，同一个厨房里的厨师可以共享这些食材和工具。

这就决定了它们的核心差异：

• 创建与销毁成本：开个新厨房（进程）得重新置办全套家当，极其耗时耗力；而招个新厨师（线程）只需在现有厨房里加双筷子，轻量得多。
• 通信难度：厨房之间想借点酱油（进程间通信），得通过专门的传递窗口（管道、消息队列等），手续繁琐；厨师之间喊一嗓子就能共享调料（共享内存），但容易因为抢同一口锅（资源竞争）引发冲突，需要加锁。

绕不开的GIL：多线程真的是废柴吗？

聊到Python并发，绝对绕不开GIL。很多文章会把GIL一棒子打死，说它让Python多线程彻底残废。这其实是个巨大的误解。

GIL的本质是CPython解释器为了内存管理（特别是引用计数）而加的一把全局大锁。它保证同一时刻只有一个线程在执行Python字节码。但这并不意味着多线程毫无用处，关键在于你的任务类型。

如果是CPU密集型任务（如复杂计算、图像处理） 这类任务需要疯狂压榨CPU。在GIL的限制下，多线程的Python代码实际上是在排队单线程执行，甚至因为线程切换的开销变得更慢。这时候，必须上多进程，让每个进程拥有独立的Python解释器和独立的GIL，真正利用起多核CPU。

如果是IO密集型任务（如爬虫、文件读写、数据库查询） 这类任务大部分时间都在“等”。当某个线程发起网络请求或读取文件时，它会主动释放GIL去干别的事。此时，多线程完全能大显身手，在等待IO的间隙让其他线程跑起来，大幅提升整体效率。而且多线程的内存开销远小于多进程，性价比极高。

面试官想听到的“加分项”

当你把上面的场景分析清楚后，面试官通常会觉得你基础扎实。但如果想拿高分，还得补充点实战中的“潜规则”。

在实际工程中，面对IO密集型任务，现在更主流的做法其实是异步IO（协程，如asyncio）。相比于多线程，协程在用户态进行切换，没有线程切换的上下文开销，也不需要处理复杂的锁问题，单机并发能力能轻松翻上几倍。

而在面对极度复杂的CPU密集型任务时，单纯靠多进程也可能遇到进程数过多导致内存撑爆的问题。这时候通常会结合进程池（ProcessPoolExecutor） 来复用进程，或者把核心计算逻辑用C/C++写成扩展模块，直接绕过GIL的限制。

总结

应对这类面试题，千万别停留在“多线程受GIL限制，多进程能绕过GIL”这种表层结论上。

把资源隔离与共享的底层差异讲透，结合CPU密集型与IO密集型给出明确的选型依据，再顺带提一嘴协程与进程池的工程实践。这套组合拳打下来，面试官自然会明白，你不仅懂理论，更是个真正在泥坑里写过代码的实战派。