121、GIL 的前世今生：为什么有 GIL、怎么绕过去、Python 3.13 的变革

121、GIL 的前世今生：为什么有 GIL、怎么绕过去、Python 3.13 的变革一个让我熬夜到凌晨三点的 Bug去年秋天，我在做一个实时数据采集系统。8个线程同时从不同API拉取行情数据，然后丢进一个共享队列做聚合计算。代码逻辑看起来完美无缺——直到生产环境跑起来，CPU利用率始终卡在100%左右，但吞吐量就是上不去。更诡异的是，当我用top -H看线程状态，发现大部分时间线程都在等待某个锁。我盯着sys.getcheckinterval()的输出，又看了看threading模块的源码，最后不得不承认：GIL这个老古董，又一次在关键时刻给了我一记闷棍。如果你写过Python多线程程序，大概率也遇到过类似场景。明明开了8个线程，结果只有一个在干活，其他7个在排队等GIL。这不是你的代码有问题，是CPython解释器自带的全局解释器锁（GIL）在作祟。GIL 到底是个什么东西GIL的全称是Global Interpreter Lock，全局解释器锁。它的存在很简单：CPython的内存管理不是线程安全的。Python对象内部有个引用计数（refcount），用来追踪对象被引用了多少次。当多个线程同时修改同一个对象的引用计数时，如果没有锁保护，计数就会出错，轻则内存泄漏，重则直接崩溃。举个例子，你写了个a = []，然后两个线程