Python 3.13t（free-threaded）首次绕过GIL实现CPU密集型多线程真并行，通过细粒度锁、原子操作和独立GC锁提升多核利用率，但单线程性能下降5%–15%，且C扩展兼容性差。

它让Python多线程在CPU密集型任务中真正并行，而不是“假装并发”——这是自CPython诞生以来第一次能绕过GIL瓶颈、直接榨干多核CPU的原生方案。

为什么标准Python多线程在CPU密集场景下几乎不提速

因为GIL强制串行执行字节码：哪怕你启动16个threading.Thread，同一时刻只有一个线程能执行Python代码。I/O操作时GIL会释放，所以I/O密集型任务（如HTTP请求）仍能受益；但纯计算（比如循环累加、矩阵遍历）会被死死卡住。

• 典型现象：time.perf_counter()测得4线程版本比单线程还慢，htop显示仅1个CPU核心跑满，其余闲置
• 根本原因：GIL不是锁某段用户代码，而是锁整个解释器状态——包括引用计数、字典哈希表、GC标记位等底层结构
• 替代方案代价高：用multiprocessing能绕过GIL，但进程间通信（IPC）开销大、内存不能共享、启动延迟明显

Python 3.13t（free-threaded）如何实现真并行

它没删掉所有锁，而是把一把大锁拆成几十把小锁，并用原子操作兜底——目标是让线程只在真正冲突时才等待。

• Py_ATOMIC_INCREF()和Py_ATOMIC_DECREF()替代传统Py_INCREF()，保证引用计数线程安全
• 每个dict、list、set对象自带独立互斥锁，而非共用GIL
• 默认启用mimalloc分配器，减少内存分配时的锁争用
• 垃圾回收器改用独立锁+延迟清理，避免全局停顿

实测性能差异暴露关键权衡点

加速不是免费的：无GIL换来并行能力，但单线程性能平均下降5%–15%，尤其在频繁创建/销毁小对象的场景。

立即学习“Python免费学习笔记（深入）”；

• CPU密集型多线程：4线程素数筛可降到单线程耗时的28%左右（接近4核理论值），top显示全部核心活跃
• 单线程基准：相同逻辑下，python3.13t比python3.13慢约10%，主因是原子操作开销和细粒度锁管理成本
• I/O密集型：两者表现基本一致，因为GIL本就会在read()/send()等系统调用前释放
• 注意：sys._is_gil_enabled()返回False才确认进入自由线程模式，别只看命令名

第三方C扩展兼容性仍是落地最大拦路虎

很多库没重写线程安全逻辑，直接在无GIL环境下运行会触发数据竞争甚至段错误——这不是bug，是设计预期。

• 纯Python库（如requests、httpx）通常可用；numpy基础数组运算支持，但np.einsum或某些ufunc内部状态可能出错
• pandas在import pandas阶段就崩溃，因其C扩展大量依赖GIL隐式同步
• 如果你的项目依赖pyarrow、scipy或自研C模块，必须验证其是否声明支持--disable-gil构建
• 临时方案：混合部署——用python3.13t跑计算主线程，用标准python3.13子进程处理C扩展逻辑

真正难的不是开启--disable-gil，而是判断你的代码里有没有隐藏的GIL假设：比如某个类的__del__方法被多个线程同时触发、或者用threading.local()存了非线程安全的C对象句柄——这些在标准版里不会出事，在3.13t里就是随机崩溃的种子。