gil只锁cpython中python字节码的执行，不锁c扩展、i/o或多进程；其存在是为保障引用计数内存管理的效率与兼容性，移除会导致单线程性能下降和c扩展重写；io密集型适用多线程，cpu密集型应选多进程。
Python的GIL到底锁住了什么
GIL（Global Interpreter Lock）是CPython解释器中的一把互斥锁，它保证**同一时刻只有一个线程执行Python字节码**。注意：它不锁C扩展、不锁I/O、不锁多进程——只锁CPython虚拟机里的字节码执行路径。也就是说，纯计算型多线程在CPython下无法真正并行，但涉及文件读写、网络请求、sleep等阻塞操作时，线程会主动释放GIL，让其他线程运行。
为什么CPython不干脆去掉GIL
去掉GIL不是技术上做不到，而是代价太高。CPython的对象内存管理依赖引用计数，而引用计数的增减操作本身不是原子的。若移除GIL，就必须为每个对象的refcount加锁，或改用更复杂的垃圾回收机制（如标记-清除），这会导致： - 所有内存操作变慢（频繁加锁/解锁） - 单线程程序性能显著下降（多数Python程序是单线程主导） - 现有C扩展需要大规模重写以保证线程安全 所以CPython选择保留GIL，在单线程场景保性能，用多进程绕过瓶颈。
哪些情况GIL会被释放
以下操作会触发线程释放GIL，允许其他Python线程获取执行权： - 调用阻塞式系统调用：如open()、read()、recv()、time.sleep() - 显式让出控制权：如threading.Lock.acquire(timeout=...)超时等待时 - C扩展主动释放：如NumPy数组运算、正则匹配re.search()底层C实现中会临时释放GIL - 定期检查机制：CPython默认每执行约100个字节码指令就检查是否需切换线程（可通过sys.setswitchinterval()调整）
实际面试怎么答才算到位
面试官想看到你理解GIL的边界和应对思路，不是背定义。可以这样组织回答： - 先说清GIL只存在于CPython，PyPy、Jython没有 - 强调“CPU密集型用多进程，IO密集型用多线程”是合理策略 - 举例说明：用concurrent.futures.ProcessPoolExecutor跑数值计算，用ThreadPoolExecutor处理HTTP请求 - 补充一句：Python 3.12开始引入“细粒度GIL”，在部分场景下允许更频繁的线程切换，但仍未消除GIL
