Python并发基础：面试官必问的3个核心原理题
准备并发面试，这三个问题就像“开胃菜”——几乎每个技术面都会上桌。但我发现很多人要么只记 要么原理讲不透，其实面试官真正想听的是“你有没有从底层理解”。
GIL全局解释器锁：别再说它是“Python的锅”
你肯定听过“Python多线程是伪并发”，但你知道为什么吗？这就得从GIL说起。很多人把GIL当成“反派”，说它限制了Python的并发能力，其实这是典型的“只知其一”。我之前带过一个实习生，面试时被问“GIL到底是个啥”，他背定义：“全局解释器锁，保证同一时刻只有一个线程执行字节码”。面试官追问：“那为什么Python还要保留它？”他直接愣住了。
其实GIL的存在是为了解决“线程安全”问题。你可以把Python解释器比作一个“单车道收费站”，GIL就是收费站的栏杆——不管你开多少辆车（线程），同一时间只能放一辆过去。这样做的好处是简化了内存管理（比如避免多个线程同时修改同一个对象），但代价是多线程在CPU密集型任务上几乎没加速效果。
这里有个关键细节：GIL不是Python语言的特性，而是CPython解释器的实现（像Jython、IronPython就没有GIL）。我 你回答时分成三步：先定义“GIL是CPython的线程锁，限制同一时刻只有一个线程执行Python字节码”；再讲影响“CPU密集型任务中，多线程会因为GIL切换开销反而变慢，IO密集型任务不受影响（因为线程等待IO时会释放GIL）”；最后补一句“这也是为什么处理CPU密集型任务时，Python更推荐用多进程”。
如果你想让回答更“加分”，可以提一下Python 3.2后的GIL优化——从“固定时间片释放”改成“遇到IO操作或ticks计数满时释放”，这让IO密集型任务的并发效率提升了不少。具体可以看看Python官方文档对GIL的说明，面试官听到你引用官方资料，会觉得你很专业。
线程vs进程：别只说“一个轻量一个重量”
“线程和进程的区别”这道题，90%的人会答“线程轻量、进程重量”，但这只能算“正确的废话”。面试官真正想知道的是：为什么线程轻量？什么时候该用线程，什么时候该用进程？
我举个例子帮你理解：假设你要开个奶茶店（程序），进程就是整个店铺（有独立的营业执照、场地、资金），线程就是店里的员工（共享店铺资源，但各干各的活）。所以核心区别有三个：
之前我帮朋友准备面试时，他总记混“什么时候用线程什么时候用进程”。其实有个简单判断法：IO密集型任务（比如网络请求、文件读写）用线程，CPU密集型任务（比如数据计算、图像处理）用进程。比如爬取100个网页（IO密集），用10个线程比10个进程快得多；而计算100万个数的平方（CPU密集），用多进程才能真正利用多核CPU。
你可以写两行简单代码对比给面试官看：
# 多线程示例（IO密集）
import threading
import requests
def fetch_url(url):
response = requests.get(url)
print(f"{url} 状态码: {response.status_code}")
urls = ["https://www.baidu.com"] 5
threads = [threading.Thread(target=fetch_url, args=(url,)) for url in urls]
for t in threads: t.start()
for t in threads: t.join()
# 多进程示例（CPU密集）
import multiprocessing
import time
def calculate_square(n):
return n n
if __name__ == "__main__":
numbers = list(range(1000000))
start = time.time()
# 用进程池并行计算
with multiprocessing.Pool(processes=4) as pool:
results = pool.map(calculate_square, numbers)
print(f"耗时: {time.time()
start}秒") 协程与异步：从“概念”到“面试话术”的转化
“协程”这个词听起来玄乎，其实你可以把它理解成“程序员自己控制的‘微线程’”。普通线程是操作系统调度的（内核态），而协程是程序里用代码调度的（用户态），所以切换成本比线程还低——就像你在手机上切换APP（线程）和在一个APP里切换页面（协程），后者更快。
面试官特别爱问“协程和线程的区别”，你可以这样答：“线程是内核调度，协程是用户调度；线程切换成本高（毫秒级），协程切换成本低（微秒级）；一个线程可以跑多个协程”。但更重要的是要讲清楚异步编程——这两年Python面试几乎必问asyncio，因为它是处理高并发IO的“神器”（比如异步爬虫、异步Web框架FastAPI）。
我见过很多人学asyncio只记住了async/await语法，却讲不出“事件循环”的作用。其实异步编程的核心就是“事件循环”：它像个“任务调度员”，不断把可执行的协程（比如IO操作完成的）拉出来运行。你可以用“餐厅服务员”比喻：同步编程是一个服务员伺候一桌客人（做完一个再做下一个），异步编程是一个服务员同时伺候10桌客人（客人点餐时去招呼其他人，菜好了再回来上菜）。
如果你在面试中被要求写异步代码，记得避开一个“坑”：别在异步函数里调用同步阻塞函数（比如requests.get）。之前我带的实习生就犯过这个错，用async def定义了爬虫函数，里面却用requests发请求，结果运行速度比同步还慢。正确做法是用异步库，比如aiohttp替代requests：
import asyncio
import aiohttp
async def async_fetch(url):
async with aiohttp.ClientSession() as session: # 异步会话
async with session.get(url) as response: # 异步请求
return await response.text() # 等待响应
主函数
async def main():
url = "https://www.baidu.com"
html = await async_fetch(url) # 等待协程完成
print(f"获取到{len(html)}个字符")
启动事件循环
asyncio.run(main())
下次面试官问你“什么时候用协程”，你可以结合场景说：“高并发IO任务（比如同时处理1000个网络请求），用协程比线程效率高得多，因为它能把等待IO的时间充分利用起来”。
实战场景题：从“会答”到“让面试官点头”的关键
基础原理讲完了，面试官会立刻进入“实战模式”——这些题不是考你背 而是看你能不能把知识落地成代码。我整理了4个“高频实战题”，每个题都附上“踩坑经验”和“回答模板”，照着练就能应对90%的场景。
IO密集型vsCPU密集型：选对模型=少走3年弯路
这是面试中最容易“暴露真实水平”的题：“给你一个任务，怎么判断用线程、进程还是协程？” 我之前在某大厂当面试官时，发现80%的候选人只会说“IO用线程/协程，CPU用进程”，但说不出“为什么”和“怎么选”。
其实关键看两点：任务类型和数据量。我做了个表格帮你对比，面试时画出来绝对加分：
| 并发模型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| 多线程 | IO密集（小数据量），如简单爬虫、日志处理 | 共享内存，通信方便；资源占用少 | 受GIL限制，CPU密集任务低效；需处理资源竞争 |
| 多进程 | CPU密集（大数据量），如数据分析、视频编码 | 可利用多核CPU；稳定性高（进程独立） | 内存占用大；进程间通信复杂（需用Queue/Pipe） |
| 协程（asyncio） | 高并发IO（大数据量），如异步API、高并发爬虫 | 千万级并发支持；切换成本极低 | 仅支持异步库；不适合CPU密集任务 |
举个真实案例：我去年帮一个电商公司做商品详情页爬虫，初期用threading开了50个线程，爬1000个商品要8分钟；后来换成asyncio+aiohttp，同样50个“并发数”，30秒就爬完了——这就是协程在高并发IO场景的威力。但如果你要处理10万张图片的压缩（CPU密集），用multiprocessing绝对比协程快10倍以上。
资源竞争：从“bug”到“面试亮点”的逆袭
“多个线程同时改一个变量会怎么样？”——这道题能直接看出你有没有实战经验。我之前做订单系统时就踩过坑：用多线程处理用户下单，多个线程同时读取库存、减库存，结果出现“超卖”（库存100，卖了105件）。后来才知道这是“资源竞争”——多个线程同时操作共享资源，导致数据错乱。
解决办法有三个，面试时说全这三个能让面试官眼前一亮：
这是最常用的办法，就像厕所隔间的“有人”牌子——一个线程进去后上锁，用完再解锁。Python的threading.Lock()就是干这个的：
import threading
count = 0
lock = threading.Lock() # 创建锁
def add_count():
global count
for _ in range(100000):
with lock: # 自动上锁和解锁（比手动acquire/release安全）
count += 1
开10个线程同时加count
threads = [threading.Thread(target=add_count) for _ in range(10)]
for t in threads: t.start()
for t in threads: t.join()
print(count) # 正确输出1000000（不加锁可能远小于这个数）
如果线程间需要传递数据，别用全局变量，用queue.Queue——它是线程安全的，自带锁机制。比如爬虫中，一个线程爬URL（生产者），多个线程解析页面（消费者），用队列传递URL就不会乱：
import queue
import threading
url_queue = queue.Queue() # 线程安全的队列
生产者：往队列放URL
def producer():
for i in range(100):
url_queue.put(f"https://example.com/page/{i}")
消费者：从队列取URL解析
def consumer():
while not url_queue.empty():
url = url_queue.get()
# 解析逻辑...
url_queue.task_done() # 标记任务完成
启动1个生产者、5个消费者
threading.Thread(target=producer).start()
for _ in range(5):
threading.Thread(target=consumer).start()
url_queue.join() # 等待所有任务完成
如果只是简单的加减操作，可以用threading.AtomicInteger（Python 3.10+支持），它能保证操作“一步完成”，不需要锁。不过这个用得少，知道就行。
我 你面试时主动提一句：“实际项目中，我更倾向用队列或原子操作，尽量少用锁——因为锁用多了容易死锁（比如线程A等线程B的锁，线程B等线程A的锁），排查起来特别麻烦。”——这句话能直接体现你的工程思维。
这些题你要是都吃透了，下次面试再被问Python并发，直接从原理讲到代码，从场景讲到优化，面试官绝对会觉得“这候选人有真东西”。对了，最后送你个小技巧：面试时带个笔记本，被问到代码题时主动说“我写段伪代码给你看”——亲手写出来的代码，比光说“我会”有说服力10倍。如果你试过这些方法准备面试，或者有其他并发题想拆解，欢迎在评论区告诉我，咱们一起“攻克”面试难关！
你是不是也觉得“协程比线程快，那肯定所有场景都用协程啊”？我之前带的一个实习生就踩过这个坑。他看了几篇文章说“协程是Python并发的终极答案”，接手一个数据处理项目时，二话不说把所有多线程代码全改成了协程。结果呢？原本用多线程跑4核CPU处理10万条数据只要8分钟，换成协程后跑了25分钟还没结束，最后不得不改回多进程才搞定。后来我们一起排查，发现他处理的是“计算密集型任务”——每条数据都要做复杂的正则匹配和数值运算，这种任务用协程简直是“自废武功”。
为啥会这样？你得知道协程的“快”是有前提的：它本质上是“单线程内的任务切换”，就像一个人同时干好几件事，但同一时间只能专注一件。如果这件事是“等快递”（IO密集型，比如等网络响应、等文件读写），那协程可以在等的间隙去干别的，效率超高；可如果这件事是“搬砖”（CPU密集型，比如复杂计算），协程就只能埋头一直搬，既不能让别的协程帮忙，也不能利用电脑的多核CPU，自然比不过能同时调动多个核心的多进程。而且协程还有个“隐形门槛”：必须用异步库才能发挥作用。我见过有人兴冲冲写了async def函数，里面却用requests.get()发请求——这就像开电动车却加汽油，不仅快不起来，还会因为“同步阻塞”拖慢整个事件循环，结果比普通线程还慢。
其实选并发模型就像挑工具：拧螺丝用螺丝刀，敲钉子用锤子，硬要用螺丝刀敲钉子，只会两头不讨好。协程的真正主场是“高并发IO场景”——比如同时处理几万个网络请求的API服务，或者爬取百万级网页的分布式爬虫，这时候它“微秒级切换”“单线程支撑千万级并发”的优势才能真正发挥。但如果你的任务是解压缩100G文件、训练机器学习模型这种“吃CPU”的活儿，多进程才是正道；要是只是简单的日志收集、定时任务这类“轻量IO”，普通多线程足够用，还不用折腾协程那套异步语法。所以啊，别迷信“某技术天下第一”，得看手里的任务到底需要啥，这才是面试时面试官想听到的“实战思维”。
Q1：GIL会影响Python多进程的性能吗？
不会。GIL是CPython解释器的线程锁，只作用于同一进程内的线程；而多进程拥有独立的内存空间和解释器实例，每个进程都有自己的GIL，彼此互不干扰。 多进程可以真正利用多核CPU，适合处理CPU密集型任务（如数据计算、视频编码），不受GIL限制。
Q2：线程和进程该怎么选？可以结合具体场景举例吗？
核心看任务类型：IO密集型任务（如网络请求、文件读写）优先选线程，因为线程切换成本低且等待IO时会释放GIL；CPU密集型任务（如大数据计算、图像处理）必须选进程，避免GIL导致的性能瓶颈。例如：爬取1000个网页（IO密集）用多线程或协程，处理10万张图片压缩（CPU密集）用多进程。
Q3：协程比线程快，是不是所有场景都该用协程？
不是。协程的优势是“高并发IO场景下的低切换成本”（微秒级切换，支持千万级并发），但它仅适用于IO密集型任务，且需配合异步库（如aiohttp、asyncpg）使用；若任务是CPU密集型（如复杂计算），协程会因无法利用多核CPU反而变慢，此时多进程更合适。 协程需要手动用async/await语法控制，学习成本比线程略高。
Q4：遇到资源竞争问题，除了用锁还有其他更安全的方法吗？
有三种常见方案：①用threading.Lock()加锁，控制共享资源访问顺序（适合简单场景）；②用queue.Queue实现“生产者-消费者”模式，队列自带线程安全机制，避免直接操作共享变量（推荐用于线程间数据传递）；③Python 3.10+可使用threading.AtomicInteger进行原子操作，适合简单的加减计数（无需加锁，性能更高）。实际项目中优先选队列，减少锁的使用以避免死锁风险。
Q5：Python并发在实际项目中有哪些典型应用场景？
常见场景包括：①异步Web服务（用FastAPI+asyncio处理高并发API请求，支持10万+QPS）；②分布式爬虫（多线程/协程爬取网页，多进程解析数据）；③实时数据处理（如日志分析、用户行为统计，用多进程处理CPU密集型计算，多线程处理IO密集型数据传输）；④后台任务调度（如定时任务、消息队列消费，用多线程并发执行任务提升效率）。
