Python 3.14 自由线程：拆掉 GIL 之后，我们到底得到了什么

多年来，Python 一直背着一个著名的包袱，也就是全局解释器锁（GIL）。Python 3.14 里，自由线程（free-threaded）构建终于从实验品升级为官方支持的形态。下面先讲清楚它是什么，再聊它的好处和代价，最后给出选型建议。

🧭 先搞懂背景：GIL 是什么，自由线程改了什么

GIL 好比一间只有一把钥匙的厨房。厨师（线程）再多，同一时刻也只有拿到钥匙的那位能下锅。这样做让解释器内部的数据结构不容易出错，代价是多线程无法让 CPU 密集型任务真正并行。

自由线程构建拿掉了这把钥匙，多个线程可以在不同的 CPU 核心上同时执行 Python 字节码。

关于官方地位，Python 从 3.14 起对自由线程的态度从实验性支持转为正式支持，依据是 PEP 779。这个状态仍然是可选的，也就是说默认安装的 Python 依旧带 GIL。把自由线程设为默认的第三阶段（Phase III）目前没有时间表。

PEP 779 对正式支持设定了一套标准。社区讨论中有一个很有意思的观点：对 threading 模块不支持，或只在附带严格限制的情况下支持，也是一种合理选择。这说明所谓支持并没有一个统一的硬指标。

以前想让 Python 吃满多核，通常得用 multiprocessing。它要启动多个进程，进程之间传数据得序列化，内存也要多占几份。自由线程下，线程之间直接共享内存，一个进程里就能把多核跑满。

理想情况下的加速比可以用阿姆达尔定律粗略估算。设可并行部分占比为 $pp$ p，核心数为 $nn$ n，则加速比为：

$S= 1(1−p)+pn S = \frac{1}{(1-p) + \frac{p}{n}}$ S=(1−p)+np1

代码里能并行的比例越高，拆掉 GIL 的收益越明显。反过来，如果大部分时间花在无法并行的串行逻辑上，再多核心也帮不上忙。

线程共享内存、通信成本低，很多原本为了绕开 GIL 而设计的复杂架构可以简化。数据处理、科学计算、服务端并发任务这些场景都会受益。

自由线程构建需要用更细粒度的机制保护内部数据，这会带来额外开销。多篇实测和介绍都提到，在单线程程序上，自由线程构建可能比普通构建慢。一位作者拿真实业务负载做测试，也把单线程开销列为上线前必须验证的事项。具体慢多少，取决于你的代码类型，所以别拿别人的数字当自己的结论。

这部分来自我对该领域的一般了解，不出自上述来源。大量依赖 C 扩展的第三方库（比如数值计算、图像处理相关的包）需要专门适配自由线程。没适配的扩展被导入时，解释器可能会重新启用 GIL 来保证安全，自由线程的优势就被抵消了。

GIL 过去替你兜住了许多隐患。拿掉之后，多个线程同时修改共享的列表、字典或自定义对象，就更容易撞上竞态条件。该加锁的地方还得加锁，该用线程安全队列的地方也别偷懒。

官方明确了它是可选的，且成为默认的阶段没有日期。短期内，你的用户大概率还在用带 GIL 的 Python，写库的人往往得同时兼顾两种构建。

这张表是综合各来源信息后给出的经验性建议。真正动手前，最靠谱的做法是拿自己的真实负载，在两种构建下各跑一遍，对比单线程与多线程的耗时。

自由线程是 Python 近些年最大的一次底层变革。3.14 让它从实验品变成了官方认可的选项，多核并行的大门已经打开。不过它依然是可选构建，单线程可能有性能代价，生态也在适配途中。比较稳妥的做法是先在测试环境里验证，再逐步引入，不必一上来就全面切换。

I Ran My Real Workload on Free-Threaded Python. Here's the Truth（Medium）：medium.com/towardsdev/...
PEP 779: Criteria for supported status for free-threaded Python（Python 官方论坛讨论）：discuss.python.org/t/pep-779-c...
Goodbye GIL: Exploring free-threaded mode in Python 3.14（LinkedIn）：www.linkedin.com/pulse/goodb...
Free-threaded (multicore, parallel) Python will be fully supported（Reddit r/Python）：www.reddit.com/r/Python/co...