北京
Python的线程有个老毛病：一个进程里，同一时刻只允许一个线程执行Python字节码。这就是GIL，全局解释器锁。它让CPython的内存管理保持简单安全，代价是线程没法把CPU密集型任务摊到多个核上。
想要真并行，开发者过去只有两条路：上多进程，或者依赖那些主动释放锁的C扩展。现在多了第三条——free-threaded构建，官方文档已经把它称为受支持，不再标注为实验性。
这条路走了不短。PEP 703提出设想，2024年10月随Python 3.13作为实验特性落地。第一版代价很实在：单线程代码明显变慢，一些内部优化因为还没做到线程安全被迫关掉。转折点是PEP 779，2025年6月被接受，为这个构建转正定下了标准。2025年10月发布的Python 3.14，把这些标准都满足了。
核心团队把它称作渐进计划的第二阶段。至于更后面的阶段会不会让free threading变成唯一构建，目前仍是开放问题。它依旧是可选项，和默认解释器分开存在。
代价缩到了5%到10%
专门用来加速普通Python代码的自适应解释器，现在能在free-threaded模式下跑了。单线程性能损失相对标准构建缩小到大约5%到10%。
启用方式不是给现有安装拨个开关，而是装一个单独的构建，通常标着3.14t。uv这类工具可以让两个构建并存，方便拿自己的代码做对比。语言还是同一门语言，底下的运行时换了一套。
收益最明显的地方，是能拆到多线程里的CPU密集型代码。比如批量解析和转换大量文件，对海量记录跑打分或特征计算，或者在工作池里处理互相独立的数据块。
在标准构建上，线程池干这类活几乎拿不到好处，锁会把计算串行化。团队于是转向多进程，而多进程自带一笔税：每个参数和结果都要pickle后在进程间传递，每个worker各持一份共享数据的副本导致内存翻倍，启动开销也会累积。
GIL拿掉之后，同样的线程代码可以跨核扩展，所有线程读的是内存里同一批对象。序列化那一步没了，程序也更简单——不必仅仅为了用上花钱买的硬件，就另搭一套进程架构。
收益大小取决于任务切分得好不好。大部分时间在等网络或磁盘的活，本来用线程就没问题，因为I/O期间锁是释放的，换构建几乎看不出变化。重计算又频繁对共享状态加锁的任务，换哪个构建都可能扩展不佳。
效果最好的，是能切成独立片段、且大部分时间跑在Python代码或配合free threading的库里的负载。想知道答案只有一条诚实的路：测。在将来跑生产的那台机器上，用同一份线程基准，在两个构建上各跑几个线程数。
生态是更大的坎
单线程代码仍然慢几个百分点。一个从不用线程做计算的应用，换过去没有收益，只有损失。3.14里的实验性JIT编译器在free-threaded构建上还不可用，指望这项加速的人要留意。
更大的障碍在生态。带C扩展的包需要为free-threaded解释器构建的wheel，核心科学计算库之外的覆盖仍不均衡，一个不支持的依赖就能卡住整个采用计划。
2026年10月发布的Python 3.15用PEP 803解决了一部分：为free-threaded构建加上稳定ABI，标记为abi3t，扩展作者可以发一个wheel跨多个free-threaded版本通用。但构建工具还在追赶。
还有一个更安静的风险藏在自己的代码里。GIL曾顺带掩盖了许多竞态条件，拿掉它，那些从来不算真正线程安全的代码里的bug就可能暴露出来。检查共享状态，该加锁的地方加锁，上负载测试之后再相信结果。
方向已经清楚。主要库在发布free-threaded构建，核心团队把这项工作当作长期承诺，而不是边角实验。负载是CPU密集型、可并行、依赖包也兼容，现在就可以试。否则盯着它，每个版本重新测一遍。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
