Python多线程无法并行执行CPU密集型任务，因CPython通过递归互斥锁（pthread_mutex_t或CRITICAL_SECTION）实现GIL，绑定于PyThreadState的gilstate字段，确保同一线程可重入获取。
Python多线程源码分析：GIL实现机制
Python的多线程无法真正并行执行CPU密集型任务，核心原因在于全局解释器锁（GIL）。它不是语言规范的一部分，而是CPython解释器为简化内存管理而引入的互斥锁。理解GIL的实现机制，需深入CPython源码（主要在ceval.c、pystate.h、thread_pthread.h等文件中）。
GIL的本质：一个递归互斥锁
GIL在CPython中是一个pthread_mutex_t类型的C级互斥锁（Linux/macOS）或CRITICAL_SECTION（Windows），但关键特性是“可重入”——同一线程可多次获取而不阻塞。这避免了解释器内部递归调用时死锁。
- GIL由PyThreadState结构体关联，每个线程有唯一状态对象，其中包含gilstate字段记录是否已持有GIL
- PyEval_RestoreThread()和PyEval_SaveThread()中，实际调用pthread_mutex_lock/unlock
- GIL不是Python对象，不参与垃圾回收，也不受Python异常影响，纯C层同步原语
字节码执行与GIL释放时机
CPython解释器通过循环执行字节码指令（PyEval_EvalFrameEx），GIL并非全程持有。它会在以下关键点被主动释放：
- I/O操作前：如read()、recv()、time.sleep()等系统调用前调用PyEval_SaveThread()，让出GIL，使其他线程可运行
- 计数器检查点：每执行约100个字节码指令（由sys.setswitchinterval()控制，默认0.005秒），解释器检查eval_breaker标志，若需切换则释放GIL
- 显式让出：C扩展可通过PyThreadState_Swap(NULL) + PyEval_ReleaseLock()手动释放（旧API）或使用Py_BEGIN_ALLOW_THREADS宏
线程调度与GIL争用逻辑
GIL的获取不是公平调度，而是“抢锁”模式。当GIL被释放后，等待线程通过条件变量gil_cond被唤醒，但唤醒后仍需竞争互斥锁本身：
立即学习“Python免费学习笔记（深入）”；
- 调用PyEval_AcquireLock()时，先尝试pthread_mutex_trylock()；失败则进入pthread_cond_wait()等待
- 存在“自旋优化”：在部分版本中（如3.2+），线程会短暂自旋若干次（默认5ms），避免频繁进出内核态，提升短临界区性能
- 主线程退出时，会调用take_gil()确保GIL被最终持有，再清理资源，防止其他线程访问已释放的解释器状态
为什么GIL难以移除？
移除GIL不是技术不可行，而是代价巨大：
- 所有对象引用计数操作（Py_INCREF/Py_DECREF）需加锁，大幅降低单线程性能（基准测试显示下降40%+）
- 大量C扩展（如NumPy、Pandas）假设GIL存在，直接操作Python对象而未加锁，移除GIL将导致数据竞争和崩溃
- 内存分配器（如pymalloc）和GC模块深度耦合GIL，重构成本极高
不复杂但容易忽略：GIL只限制CPython字节码并发，不影响C扩展内部并行（如NumPy矩阵运算调用OpenBLAS多线程）；真正需要高并发应选multiprocessing、asyncio，或换用PyPy/Jython等无GIL解释器。
