threading：多线程与GIL的那些事

可视化演示

展示Python多线程在IO密集和CPU密集场景下的执行差异，GIL如何在线程间切换，以及为何CPU密集任务无法真正并行。

线程的创建

一家小餐馆的老板发现生意火爆，自己一个人又洗又切又炒根本忙不过来，于是贴出招聘启事，请了几位帮厨。每位帮厨只负责自己手里的订单，两人洗菜、两人切菜，互不干扰，仿佛饭馆凭空多了几个分身。Python 里的线程（Thread）就是这个分身：进程是那家餐馆，线程是餐馆里各自忙碌的帮厨，它们共享同一份食材、同一本账本。

创建线程有两种主流姿势，和招聘的两种方式很像。第一种是“招科班厨师”：继承 threading.Thread 类，把要做的事写进 run 方法，适合逻辑复杂、需要长期复用的任务；第二种是“临时外包”：直接传一个函数给 Thread(target=worker, args=(...))，函数跑完外包结束，简洁轻快。

创建后要调用 start() 让线程真正开工，直接调用 run() 只是在当前线程里“假装干一遍”。主线程可以用 join() 等大家收工；还可以通过 daemon=True 把线程设为守护线程，它就像“主厨下班就散伙的兼职”，主进程一退出，守护线程自动消失。线程从新建、就绪、运行、阻塞到结束，就是它的生命周期。

回到后厨：start() 是喊一声“上工”，join() 是老板在大门口等着最慢的帮厨收工。真正让四个帮厨抢起活来又热闹又出乱子的，是下一节那把共享的钥匙。

互斥锁同步

帮厨多了，问题就来了：厨房里只有一把削皮刀，张三刚拿起来削土豆，李四伸手就抢，两人一扯，土豆滚了一地。共享资源需要“先到先用”的规矩，这把“钥匙”就是锁（Lock）。Python 中 threading.Lock 一次只允许一个线程进入受保护的区域（临界区），其他人只能在门口排队。

使用方式很机械：进门前 acquire()，出门必须 release()，更优雅的是 with lock: 的写法，即使中途抛异常也会自动还钥匙。如果同一线程要“嵌套进门”，普通 Lock 会把自己卡死——你拿着钥匙进屋，又想在屋里再拿一次钥匙，可钥匙在你手里，于是永远等下去。这时要用可重入锁 RLock，它记录重入次数，进几次出几次。

死锁是最经典的翻车现场：厨师 A 拿着削皮刀等炒锅，厨师 B 端着炒锅等削皮刀，两人对视到天黑。死锁需要四个条件：互斥、持有并等待、不可剥夺、循环等待；打破任何一个都能化解。

锁是后厨的“规定动作”，但规定多了也会拖慢出菜速度。临界区越短越好，就像用钥匙开柜子拿完就走，别站在柜门前数鸡蛋。

条件变量通信

传菜窗口是后厨最聪明的发明。厨师做好菜放在窗口，按一下铃；服务员听到铃响才来端走；窗口空空时，服务员就在旁边打盹。Python 的条件变量（Condition）就是这口铃，它解决的是“什么时候可以干活、什么时候该睡觉”的问题。

Condition 必须与一把锁搭配。厨师（生产者）进入临界区后调用 notify() 摇铃；服务员（消费者）发现窗口空了，就调用 wait() 自动释放锁并挂起睡觉，等铃响后再醒来重新抢锁。注意：wait() 醒来后要再用 while 检查条件，防止“假醒”后白跑一趟。

如果你不想自己摇铃，直接用 queue.Queue 就好。它是官方封装好的“传菜窗口”，内部自带锁和条件变量，支持 maxsize 限流、put/get 阻塞等待，生产者和消费者彻底解耦。这是绝大多数生产环境的首选。

传菜窗口把“做菜”和“上菜”彻底分开：厨师不用等服务员，服务员不用催厨师。理解了这口铃，你就掌握了线程间协作的节奏感。

GIL运行原理

现在揭晓后厨最大的秘密：这家店虽然雇了八个帮厨，却只有一个炉灶，而且老板规定“用火权一次只给一个人”。这把全局的“用火权”就是 GIL（Global Interpreter Lock，全局解释器锁）。

GIL 不是 Python 语言的规定，而是主流解释器 CPython 的实现细节。它的存在是为了保护内存安全：Python 内部用引用计数管理对象，如果两个线程同时修改同一个对象的引用计数，计数就会错乱，甚至导致内存泄漏或程序崩溃。GIL 让“改计数”这件事一次只有一个人能做，相当于老板在炉灶边立了块牌子：安全第一。

代价是：同一时刻，整个进程只有一个线程在执行 Python 字节码，多核 CPU 也派不上用场。但 GIL 并非永远霸占，解释器每执行一个时间片就检查一次要不要把炉子让出去，遇到 IO 阻塞则会立刻释放。

炉灶规矩保护了后厨的安全，却也限制了并行炒菜的可能。老板心里清楚：想真正快起来，得看这口锅到底被用来炒菜还是等水。

GIL现实影响

弄懂了炉灶规则，就能解释一个反常现象：四个帮厨同时抢着炒菜，锅只有一口，炒好的菜和一个人炒的一模一样多，甚至更少——因为大家还得互相让位。这就是 CPU 密集任务：多线程加速比约等于 1，开了等于没开。

可如果四个帮厨都在等自己的水烧开呢？等水不需要炉灶，这时谁占着用火权都无所谓，四个人可以同时等。这就是 IO 密集任务：线程在等待网络响应、磁盘读写时主动释放 GIL，其他线程趁机执行，并发效果立刻显现。爬虫、Web 服务、文件处理全是这类场景。

Amdahl 定律能帮我们看清天花板：任务的加速比由可并行部分和串行瓶颈共同决定。在 GIL 之下，CPU 计算部分相当于被强制串行化，于是加速比趋近 1；而 IO 等待既不算并行计算，也不需要占着 GIL，反而躲开了它的约束。

所以判断该不该开多线程，先问一句：你在炒菜，还是在等水开？炒菜请找进程，等水请找线程。

线程安全策略

帮厨们除了抢刀抢锅，还会抢“台账”。假设冰箱里的鸡蛋数记在账本上，张三看了一眼是 10 个，拿了一个想改成 9；还没落笔，李四也看了一眼，看到的还是 10，也拿了一个改成 9。结果账本记 9，实际只剩 8 个。这就是竞态条件（race condition）。

GIL 能保护解释器内部的引用计数，却保护不了你的业务数据。x += 1 看似一步，实际是“读旧值、加一、写回”三步，三步之间线程随时可能被切换。GIL 是炉灶规矩，不是账本的保险柜。

让数据线程安全有三招：一是依赖原子操作（单条字节码级别，如简单的赋值），二是在复合操作外加锁，三是优先使用官方安全容器，比如 queue.Queue、threading.local，把风险关进笼子里。

账本的教训告诉我们：共享数据是后厨最脆弱的地方。要么用锁看得死死的，要么干脆用带锁的传菜窗口，别让两个帮厨同时动笔。

线程还是进程

如果这家餐馆真到了要同时炒四桌菜的地步，老板的终极方案是开四家分店：每家一个独立厨房，各有一口炉灶，真正并行炒菜。Python 里这叫进程（Process），multiprocessing 模块就是“开分店”。

分店多了，麻烦也多了：各店有自己的食材库存，不能直接共享锅碗瓢盆；要协作就得走“跨店传送”——进程间通信（IPC），比如队列、管道、共享内存，成本远高于线程间的传菜窗口。线程切换轻、通信快，但受 GIL 约束；进程真并行，但创建和通信都重。

所以选型口诀：IO 密集任务（爬虫、Web 服务、读写文件）——线程开销小、通信快，优先线程；CPU 密集任务（图像处理、数值计算、模型推理）——需要真并行，优先进程。线程池规模也有经验公式。

后厨的故事到这里讲完了：线程是帮厨，GIL 是炉灶，锁是钥匙，队列是传菜窗，进程是分店。理解了这些角色，你就能在并发编程里从容点单。

AI 应用场景

Python 演示

import threadingimport timefrom queue import Queue def cpu_puzzle(n):    total = 0    for i in range(n):        total += i * i    return total def io_puzzle(times, gap=0.1):    for _ in range(times):        time.sleep(gap) def timeit(fn, *args):    t0 = time.time()    fn(*args)    return time.time() - t0 def run_threads(fn, args, workers=4):    ts = [threading.Thread(target=fn, args=args) for _ in range(workers)]    t0 = time.time()    for t in ts:        t.start()    for t in ts:        t.join()    return time.time() - t0 def producer(queue, total):    for i in range(total):        queue.put(i)    queue.put(None) def consumer(queue):    while True:        item = queue.get()        if item is None:            break        _ = item * item if __name__ == "__main__":    n = 2_000_000    single = timeit(cpu_puzzle, n)    multi = run_threads(cpu_puzzle, (n,))    print(f"CPU密集: 单线程 {single:.2f}s, 4线程 {multi:.2f}s, 加速比 {single / multi:.2f}")     single = timeit(io_puzzle, 20)    multi = run_threads(io_puzzle, (20,))    print(f"IO密集: 单线程 {single:.2f}s, 4线程 {multi:.2f}s, 加速比 {single / multi:.2f}")     q = Queue(maxsize=8)    producers = [threading.Thread(target=producer, args=(q, 2000)) for _ in range(2)]    consumers = [threading.Thread(target=consumer, args=(q,)) for _ in range(2)]    for t in producers + consumers:        t.start()    for t in producers:        t.join()    for t in consumers:        t.join()    print("生产者-消费者演示完成: Queue 内部锁与条件变量工作正常")

1. import threading引入“招帮厨”的并发模块，所有线程能力都从这里来。
2. threading.Thread(target=fn, args=args)每个线程绑一个任务函数，相当于给帮厨派单。
3. t.start()真正“上工”，创建并启动线程；只调 run() 不会开新线程。
4. t.join()老板在门口等所有人收工，主线程阻塞直到子线程结束。
5. time.sleep(gap)模拟 IO 等待，此时不占炉灶，GIL 被释放给其他线程。
6. Queue(maxsize=8)限流 8 个任务的传菜窗口，内部自带锁和条件变量。
7. q.put(item)窗口没满就放菜，满了自动阻塞等待。
8. item = q.get()窗口有菜就端走，空了自动阻塞等待。
9. q.put(None)“毒丸”哨兵，通知消费者收工，优雅退出循环。

常见误区

面试题