前言先说一个措辞上的准确性问题。标题里的「GIL锁」其实是个叠词GIL 全称 Global Interpreter Lock本身就带着「Lock」。更重要的纠正是两点第一GIL 是 CPython 的实现细节不是 Python 语言的规定。你写的 Python 代码交给别的实现比如 JPython跑就不一定有这把锁。所以精确的说法是「CPython 的 GIL」而不是「Python 的 GIL」。第二GIL 和你在代码里import threading; lock threading.Lock()用的那把锁是两回事。threading.Lock是你为了保护共享数据自己加的GIL 是解释器内部为了自保加的。混为一谈是理解多线程时最常见的绊脚石。本文讲清三件事GIL 到底是什么、它为什么存在、以及它对爬虫这类程序到底有什么影响。示例以 CPython 3.8 及以上为基准涉及 3.13 实验性自由线程构建的行为会单独标注。一、GIL 到底是什么一句话GIL 让同一进程内、同一时刻只有一个线程在执行 Python 字节码。拆开看这几个限定词都很关键同一进程内GIL 是每个解释器进程一把不是全局唯一。开两个进程就有两把 GIL能真正并行。同一时刻GIL 会在多个线程之间轮转让每个线程都分到执行机会只是任意瞬间只有一个在跑。执行 Python 字节码注意是「执行字节码」时才必须持有 GIL。当线程在等待 I/O、在sleep、在很多标准库的阻塞调用里时它会释放 GIL别的线程就能趁虚而入。最后一点是理解「为什么多线程对爬虫有效」的全部关键。二、GIL 为什么存在GIL 不是设计失误而是为了让 CPython 的实现变简单引用计数reference counting是 CPython 的内存管理方式。每次对象被引用或取消引用计数器都要加一减一。如果多个线程同时改同一个对象的计数器就需要给每个对象都加锁开销巨大还极易写出竞态。用一把全局锁保护整个解释器状态简单得多。C 扩展的兼容性大量第三方 C 扩展默认「有 GIL 保护就不会被并发打断」因此写起来可以不管锁。这也是移除 GIL 极难的原因——牵扯整个生态。一句话GIL 用「牺牲多核并行」换来了「实现简单 扩展生态稳定」。三、对两类任务后果完全不同任务类型典型例子多线程有用吗原因CPU 密集大量数值计算、图像处理、压缩基本没用大家抢同一把 GIL多核用不上I/O 密集网络请求、读写文件、等数据库有用等待时会释放 GIL别人能接着跑官方文档在threading模块页说得很直接如果想让程序更好地利用多核机器的计算资源应当改用multiprocessing或concurrent.futures.ProcessPoolExecutor而线程依然适合同时跑多个 I/O 密集任务。这个区分对爬虫极其重要因为爬虫几乎纯是 I/O 密集程序 90% 以上的时间在等网络返回CPU 只是在解析少量 HTML。等待期间线程释放 GIL所以多线程爬虫是有效的。四、GIL 对爬虫的具体影响好消息GIL 基本不阻碍多线程爬虫。因为爬虫的瓶颈在网络上不在 CPU 上。坏消息藏在细节里主要有三点1. 解析/计算密集的那部分仍然不并行。如果你在拿到页面后做大量正则回溯、大规模 HTML 解析、或者跑机器学习模型这些是 CPU 密集的多线程跑不出来加速。这时把解析部分放到进程池或换用带 C 扩展的解析库更划算。2. 「多线程能提升 N 倍」是错的。实际吞吐上限由目标站点响应速度、你的带宽、以及对方的限流策略共同决定。线程开到 200 个多半只是让一部分线程在排队还容易被对方识别为异常流量。不要相信任何没实测过的倍数说法。想比较就用time.perf_counter()自己量。3. GIL 的切换会带来开销。线程过多时解释器花在切换上的时间占比会上升。线程数应当和「并发等待的 I/O 数量」匹配而不是越大越好。切换间隔由sys.setswitchinterval()控制默认值约几毫秒——这是全局设置不要在业务代码里随手改。五、想绕过 GIL有几条路方案机制适用与代价multiprocessing每个进程一个解释器各有一把 GIL真并行代价是数据要序列化、进程开销大concurrent.futures.ProcessPoolExecutor同上接口更统一适合把 CPU 密集的部分切出去C 扩展 /numpy一类的库在原生代码里主动释放 GIL真并行但本机没有编译工具链就没法自己写 C 扩展asyncio单线程事件循环靠await切换高并发 I/O 很省资源但生态要适配异步自由线程构建3.13关掉 GIL真正并行跑线程实验性、非默认、需单独安装关于最后一条务必说准CPython 3.13 起提供了实验性的自由线程free-threaded构建可以在运行时禁用 GIL实现线程的真正并行执行。但官方文档明说这是实验特性、默认不启用需要单独的可执行文件安装时选 free-threaded 版本或自行用--disable-gil编译。所以不要说「Python 已经没有 GIL 了」——默认构建里它依然在。想检查当前解释器是否跑在自由线程模式下可以用sys._is_gil_enabled()。对爬虫而言实际情况是主流做法本来就是多线程或 asyncio跑 I/O 必要时多进程做 CPU 密集的解析这条路不依赖自由线程构建今天就能用。六、一个能观察 GIL 行为的实验下面这段代码不需要任何第三方库。用两种方式各跑一次同样的「做饭」任务一种是纯等待模拟 I/O一种是纯计算模拟 CPU 密集。它会打印出实际耗时你可以亲眼看到多线程只在第一种情况下才有收益。# 适用于 Python 3.8import threadingimport timedef io_task():time.sleep(0.5) # 模拟等待网络会释放 GILdef cpu_task():total 0for i in range(3_000_000): # 模拟纯计算全程要持有 GILtotal i * ireturn totaldef run_all(fn, n4):threads [threading.Thread(targetfn) for _ in range(n)]start time.perf_counter()for t in threads:t.start()for t in threads:t.join()return time.perf_counter() - startif __name__ __main__:print(fI/O 型4 线程耗时{run_all(io_task):.3f} 秒)start time.perf_counter()for _ in range(4):cpu_task()serial time.perf_counter() - startprint(fCPU 型串行 耗时{serial:.3f} 秒)print(fCPU 型4 线程耗时{run_all(cpu_task):.3f} 秒)预期现象I/O 型的 4 线程耗时远小于串行相加的 2 秒而 CPU 型的 4 线程耗时不会明显低于串行——因为计算全程都在抢 GIL。请自己在本机跑一遍看真实数字本文不给具体倍数。七、爬虫合规提醒讲爬虫绕不开合规。无论线程开几个下面几条是底线先看目标站的robots.txt和使用条款尊重抓取范围的声明控制请求频率用time.sleep或令牌桶限速不要对单个站点打高并发用合理的User-Agent表明身份不要伪装、不要绕登录墙或付费墙只抓公开数据注意个人信息与版权边界。反爬机制检查 UA、频率、Cookie 校验的成因值得了解但那是识别异常流量的机制不是用来研究怎么绕过的。合规抓取既能拿到数据也不会给对方造成负担。常见坑点1. 把threading.Lock当成 GIL❌ 以为代码里加了with lock:就等于「用好了 GIL」。 ✅ GIL 是解释器内部的锁和你自己的业务锁无关保护共享数据仍需自己加threading.Lock。2. 用多线程做 CPU 密集任务❌ 用 8 个线程跑大量数值计算期待 8 倍速。 ✅ 受 GIL 限制没用改用ProcessPoolExecutor或原生扩展库。3. 说「Python 已经没有 GIL 了」❌ 把 3.13 的实验性无 GIL 构建当成默认行为。 ✅ 它是实验性、非默认、要单独安装默认构建里 GIL 仍在。4. 线程数开得越大越好❌ 爬虫动辄开几百个线程。 ✅ 线程数和并发 I/O 数量匹配配合限速过多线程增加切换开销且会被对方拦截。5. 编造「提速 N 倍」❌ 写「多线程爬虫比单线程快 10 倍」却没有依据。 ✅ 用time.perf_counter()实测或只讲原理不给数字。6. 在业务代码里改sys.setswitchinterval()❌ 随手调小切换间隔以为能加速。 ✅ 它是全局设置影响整个解释器非必要不改。7. 以为 GIL 能代替业务上的同步❌ 在线程里对共享字典「随便改」觉得 GIL 会保护自己。 ✅ GIL 只保证单条字节码不被中途抢占、dict的读改删仍需显式同步。8. 用random生成爬虫里的令牌/签名❌random.random()生成会话标识。 ✅secrets模块才是密码学安全的随机源。总结问题结论GIL 是什么CPython 内部锁同一进程同一时刻只有一个线程跑字节码是语言规范吗不是是实现细节对 CPU 密集基本没有加速效果对 I/O 密集有效因为等待时会释放 GIL对爬虫爬虫是 I/O 密集多线程有效CPU 密集的解析交给进程3.13 自由线程实验性、非默认、需单独安装想真并行多进程、C 扩展、asyncio各有适用场景把 GIL 记成一句话它限制的是「同时算」不限制「同时等」。爬虫干的正是「同时等」的活所以多线程是合适的工具而任何需要「同时算」的重活才该请出多进程或原生扩展。
前言先说一个措辞上的准确性问题。标题里的「GIL锁」其实是个叠词GIL 全称 Global Interpreter Lock本身就带着「Lock」。更重要的纠正是两点第一GIL 是 CPython 的实现细节不是 Python 语言的规定。你写的 Python 代码交给别的实现比如 JPython跑就不一定有这把锁。所以精确的说法是「CPython 的 GIL」而不是「Python 的 GIL」。第二GIL 和你在代码里import threading; lock threading.Lock()用的那把锁是两回事。threading.Lock是你为了保护共享数据自己加的GIL 是解释器内部为了自保加的。混为一谈是理解多线程时最常见的绊脚石。本文讲清三件事GIL 到底是什么、它为什么存在、以及它对爬虫这类程序到底有什么影响。示例以 CPython 3.8 及以上为基准涉及 3.13 实验性自由线程构建的行为会单独标注。一、GIL 到底是什么一句话GIL 让同一进程内、同一时刻只有一个线程在执行 Python 字节码。拆开看这几个限定词都很关键同一进程内GIL 是每个解释器进程一把不是全局唯一。开两个进程就有两把 GIL能真正并行。同一时刻GIL 会在多个线程之间轮转让每个线程都分到执行机会只是任意瞬间只有一个在跑。执行 Python 字节码注意是「执行字节码」时才必须持有 GIL。当线程在等待 I/O、在sleep、在很多标准库的阻塞调用里时它会释放 GIL别的线程就能趁虚而入。最后一点是理解「为什么多线程对爬虫有效」的全部关键。二、GIL 为什么存在GIL 不是设计失误而是为了让 CPython 的实现变简单引用计数reference counting是 CPython 的内存管理方式。每次对象被引用或取消引用计数器都要加一减一。如果多个线程同时改同一个对象的计数器就需要给每个对象都加锁开销巨大还极易写出竞态。用一把全局锁保护整个解释器状态简单得多。C 扩展的兼容性大量第三方 C 扩展默认「有 GIL 保护就不会被并发打断」因此写起来可以不管锁。这也是移除 GIL 极难的原因——牵扯整个生态。一句话GIL 用「牺牲多核并行」换来了「实现简单 扩展生态稳定」。三、对两类任务后果完全不同任务类型典型例子多线程有用吗原因CPU 密集大量数值计算、图像处理、压缩基本没用大家抢同一把 GIL多核用不上I/O 密集网络请求、读写文件、等数据库有用等待时会释放 GIL别人能接着跑官方文档在threading模块页说得很直接如果想让程序更好地利用多核机器的计算资源应当改用multiprocessing或concurrent.futures.ProcessPoolExecutor而线程依然适合同时跑多个 I/O 密集任务。这个区分对爬虫极其重要因为爬虫几乎纯是 I/O 密集程序 90% 以上的时间在等网络返回CPU 只是在解析少量 HTML。等待期间线程释放 GIL所以多线程爬虫是有效的。四、GIL 对爬虫的具体影响好消息GIL 基本不阻碍多线程爬虫。因为爬虫的瓶颈在网络上不在 CPU 上。坏消息藏在细节里主要有三点1. 解析/计算密集的那部分仍然不并行。如果你在拿到页面后做大量正则回溯、大规模 HTML 解析、或者跑机器学习模型这些是 CPU 密集的多线程跑不出来加速。这时把解析部分放到进程池或换用带 C 扩展的解析库更划算。2. 「多线程能提升 N 倍」是错的。实际吞吐上限由目标站点响应速度、你的带宽、以及对方的限流策略共同决定。线程开到 200 个多半只是让一部分线程在排队还容易被对方识别为异常流量。不要相信任何没实测过的倍数说法。想比较就用time.perf_counter()自己量。3. GIL 的切换会带来开销。线程过多时解释器花在切换上的时间占比会上升。线程数应当和「并发等待的 I/O 数量」匹配而不是越大越好。切换间隔由sys.setswitchinterval()控制默认值约几毫秒——这是全局设置不要在业务代码里随手改。五、想绕过 GIL有几条路方案机制适用与代价multiprocessing每个进程一个解释器各有一把 GIL真并行代价是数据要序列化、进程开销大concurrent.futures.ProcessPoolExecutor同上接口更统一适合把 CPU 密集的部分切出去C 扩展 /numpy一类的库在原生代码里主动释放 GIL真并行但本机没有编译工具链就没法自己写 C 扩展asyncio单线程事件循环靠await切换高并发 I/O 很省资源但生态要适配异步自由线程构建3.13关掉 GIL真正并行跑线程实验性、非默认、需单独安装关于最后一条务必说准CPython 3.13 起提供了实验性的自由线程free-threaded构建可以在运行时禁用 GIL实现线程的真正并行执行。但官方文档明说这是实验特性、默认不启用需要单独的可执行文件安装时选 free-threaded 版本或自行用--disable-gil编译。所以不要说「Python 已经没有 GIL 了」——默认构建里它依然在。想检查当前解释器是否跑在自由线程模式下可以用sys._is_gil_enabled()。对爬虫而言实际情况是主流做法本来就是多线程或 asyncio跑 I/O 必要时多进程做 CPU 密集的解析这条路不依赖自由线程构建今天就能用。六、一个能观察 GIL 行为的实验下面这段代码不需要任何第三方库。用两种方式各跑一次同样的「做饭」任务一种是纯等待模拟 I/O一种是纯计算模拟 CPU 密集。它会打印出实际耗时你可以亲眼看到多线程只在第一种情况下才有收益。# 适用于 Python 3.8import threadingimport timedef io_task():time.sleep(0.5) # 模拟等待网络会释放 GILdef cpu_task():total 0for i in range(3_000_000): # 模拟纯计算全程要持有 GILtotal i * ireturn totaldef run_all(fn, n4):threads [threading.Thread(targetfn) for _ in range(n)]start time.perf_counter()for t in threads:t.start()for t in threads:t.join()return time.perf_counter() - startif __name__ __main__:print(fI/O 型4 线程耗时{run_all(io_task):.3f} 秒)start time.perf_counter()for _ in range(4):cpu_task()serial time.perf_counter() - startprint(fCPU 型串行 耗时{serial:.3f} 秒)print(fCPU 型4 线程耗时{run_all(cpu_task):.3f} 秒)预期现象I/O 型的 4 线程耗时远小于串行相加的 2 秒而 CPU 型的 4 线程耗时不会明显低于串行——因为计算全程都在抢 GIL。请自己在本机跑一遍看真实数字本文不给具体倍数。七、爬虫合规提醒讲爬虫绕不开合规。无论线程开几个下面几条是底线先看目标站的robots.txt和使用条款尊重抓取范围的声明控制请求频率用time.sleep或令牌桶限速不要对单个站点打高并发用合理的User-Agent表明身份不要伪装、不要绕登录墙或付费墙只抓公开数据注意个人信息与版权边界。反爬机制检查 UA、频率、Cookie 校验的成因值得了解但那是识别异常流量的机制不是用来研究怎么绕过的。合规抓取既能拿到数据也不会给对方造成负担。常见坑点1. 把threading.Lock当成 GIL❌ 以为代码里加了with lock:就等于「用好了 GIL」。 ✅ GIL 是解释器内部的锁和你自己的业务锁无关保护共享数据仍需自己加threading.Lock。2. 用多线程做 CPU 密集任务❌ 用 8 个线程跑大量数值计算期待 8 倍速。 ✅ 受 GIL 限制没用改用ProcessPoolExecutor或原生扩展库。3. 说「Python 已经没有 GIL 了」❌ 把 3.13 的实验性无 GIL 构建当成默认行为。 ✅ 它是实验性、非默认、要单独安装默认构建里 GIL 仍在。4. 线程数开得越大越好❌ 爬虫动辄开几百个线程。 ✅ 线程数和并发 I/O 数量匹配配合限速过多线程增加切换开销且会被对方拦截。5. 编造「提速 N 倍」❌ 写「多线程爬虫比单线程快 10 倍」却没有依据。 ✅ 用time.perf_counter()实测或只讲原理不给数字。6. 在业务代码里改sys.setswitchinterval()❌ 随手调小切换间隔以为能加速。 ✅ 它是全局设置影响整个解释器非必要不改。7. 以为 GIL 能代替业务上的同步❌ 在线程里对共享字典「随便改」觉得 GIL 会保护自己。 ✅ GIL 只保证单条字节码不被中途抢占、dict的读改删仍需显式同步。8. 用random生成爬虫里的令牌/签名❌random.random()生成会话标识。 ✅secrets模块才是密码学安全的随机源。总结问题结论GIL 是什么CPython 内部锁同一进程同一时刻只有一个线程跑字节码是语言规范吗不是是实现细节对 CPU 密集基本没有加速效果对 I/O 密集有效因为等待时会释放 GIL对爬虫爬虫是 I/O 密集多线程有效CPU 密集的解析交给进程3.13 自由线程实验性、非默认、需单独安装想真并行多进程、C 扩展、asyncio各有适用场景把 GIL 记成一句话它限制的是「同时算」不限制「同时等」。爬虫干的正是「同时等」的活所以多线程是合适的工具而任何需要「同时算」的重活才该请出多进程或原生扩展。
