Python的GIL全称为全局解释器锁，是CPython解释器实现的一套互斥锁机制，它的核心作用是限制同一时刻只有一个线程可以执行Python字节码，从根源上避免多线程并发操作共享数据时的竞争问题。GIL的存在和Python的内存管理机制直接相关，尤其是引用计数的垃圾回收方式，需要保证引用计数的修改是原子操作，否则可能出现对象被错误回收的情况。
GIL的设计初衷
Python早期的内存管理使用引用计数作为主要垃圾回收方式，每个Python对象都有一个引用计数属性，当有新的引用指向对象时计数加1，引用失效时计数减1，计数为0时对象被回收。如果多个线程同时修改同一个对象的引用计数，就会出现竞争条件：比如线程A刚把计数从1减到0，还没来得及回收对象，线程B又给对象加了引用，此时计数变回1，之后线程A执行回收就会导致对象被错误释放，引发程序崩溃。
为了规避这类问题，CPython设计者在解释器层面加入了GIL，让所有线程在执行字节码前必须先获取GIL，执行完一段字节码后再释放GIL，这样同一时刻只有一个线程能操作Python对象，自然就避免了引用计数的竞争问题。
CPython中GIL的底层实现
GIL在CPython的底层是用操作系统的互斥锁和条件变量配合实现的，相关代码主要在ceval.c和pythread.h文件中。核心逻辑可以拆解为三个部分：
1. GIL的获取逻辑
线程要执行Python字节码前，会调用take_gil函数尝试获取GIL。如果GIL已经被其他线程持有，当前线程会先释放之前持有的CPU时间片，然后进入等待状态，直到持有GIL的线程释放锁并发送唤醒信号。
简化后的C逻辑伪代码如下：
void take_gil(PyThreadState *tstate) {
// 尝试获取GIL对应的互斥锁
if (gil_mutex.try_lock() == 0) {
// 获取成功，标记当前线程持有GIL
_PyRuntime.ceval.gil_last_holder = tstate;
return;
}
// 获取失败，等待GIL释放的信号
while (1) {
// 释放CPU，等待条件变量唤醒
gil_cond.wait(gil_mutex);
if (gil_mutex.try_lock() == 0) {
_PyRuntime.ceval.gil_last_holder = tstate;
return;
}
}
}
2. GIL的释放逻辑
线程不会一直持有GIL，CPython设置了超时机制：默认情况下，线程执行100个字节码指令后，或者遇到IO操作、time.sleep等阻塞调用时，会主动释放GIL。另外如果线程运行时间超过了15毫秒（这个阈值可以通过sys.setswitchinterval调整），也会被强制要求释放GIL，让其他线程有机会执行。
释放GIL的核心逻辑在drop_gil函数中：
void drop_gil(PyThreadState *tstate) {
// 标记GIL已经被释放
_PyRuntime.ceval.gil_last_holder = NULL;
// 唤醒等待GIL的其他线程
gil_cond.signal();
// 释放GIL对应的互斥锁
gil_mutex.unlock();
}
3. GIL与线程调度的配合
Python的线程调度是基于GIL的持有情况实现的，线程本身是由操作系统调度的，但只有持有GIL的线程才能执行Python字节码。当线程释放GIL后，操作系统会调度其他就绪的线程，如果新调度的线程是Python线程，它会尝试获取GIL，获取成功后再继续执行字节码。
GIL对性能的影响
GIL的影响主要体现在两种任务场景：
- CPU密集型任务：多个线程同时执行计算任务时，由于GIL的存在，同一时刻只有一个线程能执行，多线程反而会因为线程切换的开销比单线程更慢。这类场景更适合用多进程，因为每个进程有独立的GIL，能真正实现并行计算。
- IO密集型任务：线程在等待IO时会主动释放GIL，其他线程可以趁机获取GIL执行任务，所以多线程在IO密集型场景下依然能提升效率，比如网络请求、文件读写等场景。
常见问题解答
为什么Python不去掉GIL
去掉GIL需要对Python的内存管理和所有C扩展模块做大量修改，保证引用计数的线程安全，这会大幅提升单线程场景的性能开销，同时兼容大量已有的C扩展。目前Python社区也在尝试改进，比如Python 3.13引入了自由线程模式的可选支持，但GIL依然是默认开启的状态。
如何判断自己的代码受GIL影响
如果任务是纯Python实现的CPU密集计算，多线程运行速度和单线程几乎一致甚至更慢，就说明受到了GIL的限制。可以通过threading和multiprocessing模块分别写测试代码对比运行时间，就能明确GIL的影响程度。
以下是一个简单的CPU密集任务多线程测试示例：
import threading
import time
def cpu_task():
# 简单的计算任务，累加1000万次
total = 0
for i in range(10000000):
total += i
return total
if __name__ == "__main__":
# 单线程执行
start = time.time()
cpu_task()
single_time = time.time() - start
print(f"单线程耗时: {single_time:.2f}秒")
# 双线程执行
start = time.time()
t1 = threading.Thread(target=cpu_task)
t2 = threading.Thread(target=cpu_task)
t1.start()
t2.start()
t1.join()
t2.join()
multi_time = time.time() - start
print(f"双线程耗时: {multi_time:.2f}秒")
运行这段代码会发现双线程的耗时和单线程几乎一致，甚至略高，这就是GIL限制的典型表现。