Python 3.14来了Python终于可以真正多线程了如果你是一名 Python 开发者最近一定听到过一个非常吸引人的消息Python 3.14 来了而且 Python 终于可以真正多线程了对于很多 Python 程序员来说这句话简直像是等了十几年。毕竟 Python 最大的“槽点”之一就是那个几乎无人不知的GIL——Global Interpreter Lock全局解释器锁。很多初学者甚至会产生一个疑问Python 明明有threading为什么我的 CPU 密集型程序开几个线程以后速度反而没明显提升原因就在 GIL。但到了 Python 3.14这件事情真的发生了重大变化。不过先别急着兴奋。Python 3.14 并不是“默认关闭 GIL”。真正准确的说法是Python 3.14 正式支持 Free-threaded Python自由线程 Python也就是可以运行在关闭 GIL 的构建版本上而且这一模式已经不再属于实验性功能。但是它目前依然是可选模式并不是默认模式。这一区别非常重要。那么问题来了Python 为什么需要 GILFree-threaded Python 到底是什么Python 3.14 的多线程究竟能有多快以后是不是threading就能替代multiprocessing今天我们就把这些问题一次讲清楚。一、先搞懂Python 为什么一直有 GIL如果你写过 Python 多线程代码大概率见过importthreadingdefwork():total0foriinrange(10_000_000):totali threads[threading.Thread(targetwork)for_inrange(4)]fortinthreads:t.start()fortinthreads:t.join()直觉上看线程 1 → CPU 线程 2 → CPU 线程 3 → CPU 线程 4 → CPU如果电脑有 4 个 CPU 核心理论上应该同时运行。但在传统 CPython 中并不是这么简单。因为 CPython 存在一个非常重要的机制GIL │ ┌────────┼────────┐ ↓ ↓ ↓ Thread1 Thread2 Thread3 │ │ │ └───────┬┴────────┘ ↓ 同一时间只有一个 线程执行 Python 字节码也就是说多个线程可以存在但同一时刻通常只有一个线程能够执行 Python 字节码。这就是 GIL。Python 官方文档也明确说明在传统 GIL 构建中GIL 限制 CPU 密集型任务的线程性能因为同一时间只能有一个线程执行 Python 字节码。二、那 GIL 为什么存在很多人会把 GIL 简单理解成“Python 开发者偷懒设计出来的东西。”实际上并不是。GIL 的存在与 CPython 的对象模型和内存管理密切相关。Python 中大量对象都涉及引用计数 内存管理 垃圾回收 C API 对象状态例如a[]这个list对象背后就有大量 CPython 内部机制。如果多个线程同时修改同一个对象Thread 1 ↓ 修改对象 ↑ Thread 2 ↓ 同时修改对象就会涉及线程安全问题。尤其是 CPython 长期使用引用计数管理对象生命周期。如果没有额外保护Thread A: reference_count 1 Thread B: reference_count 1两个线程同时修改就可能产生数据竞争。因此传统 CPython 使用 GIL 来提供一种非常强的全局同步机制。简单理解只允许一个线程进入 Python 解释器核心执行区域。这样很多事情就简单很多。三、GIL最大的痛点是什么问题出现在CPU 密集型任务。例如defcalculate():total0foriinrange(100_000_000):totalireturntotal如果你使用threading.Thread创建多个线程CPU核心1 CPU核心2 CPU核心3 CPU核心4并不意味着四个线程可以同时执行 Python 字节码。传统 CPython 中Thread 1 → 执行 Thread 2 → 等待 Thread 1 → 暂停 Thread 2 → 执行 Thread 2 → 暂停 Thread 3 → 执行看起来像并行。实际上更多是多个线程之间不断切换。所以I/O 密集型比如HTTP请求 数据库 文件读写 网络请求线程仍然非常有用。因为线程大量时间都在等待。CPU 密集型比如图像处理 数学计算 大量 Python 循环 数据计算 CPU 密集型算法传统 GIL 就成为了限制。这也是为什么 Python 长期以来经常建议I/O密集型 → threading / asyncio CPU密集型 → multiprocessing四、Python 3.13 其实已经迈出了第一步很多人以为“Python 3.14 才开始无 GIL。”其实不是。Free-threaded Python 最早在Python 3.13就已经出现。Python 3.13 引入了关闭 GIL 的实验性构建版本。当时它属于Experimental Free-Threading也就是实验性质。Python 3.13 已经可以通过专门构建版本运行在关闭 GIL 的模式下官方 Windows 和 macOS 安装器也提供了相关支持。但是当时存在很多问题兼容性 性能开销 第三方库支持 C 扩展支持 稳定性所以普通开发者并不会直接把生产项目全部迁移过去。五、Python 3.14真正重要的变化到了 Python 3.14Free-threaded Python 正式获得官方支持。这意味着它不再是“实验室里的玩具。”而是官方支持的 Python 构建选项。但是这里一定要注意Python 3.14 ≠ 默认无 GIL正确关系是Python 3.14 │ ┌────────┴────────┐ ↓ ↓ 默认构建 Free-threaded │ │ 有 GIL 无 GIL │ │ 传统模式 真正多线程Python 官方明确表示3.14 是自由线程进入第二阶段官方支持但仍然是可选项。至于未来是否进入第三阶段——也就是把自由线程作为默认甚至唯一构建——目前并没有做出最终决定。所以“Python 3.14 默认没有 GIL”是错误的。但“Python 3.14 正式支持无 GIL 的 Python”是正确的。六、什么叫 Free-threaded Python这个概念其实并不复杂。传统 PythonPython进程 │ ↓ GIL │ ┌───┴────┐ ↓ ↓ 线程1 线程2 │ 只能一个线程执行 Python代码Free-threaded PythonPython进程 │ 无GIL │ ┌───┬────┬────┐ ↓ ↓ ↓ ↓ T1 T2 T3 T4 │ │ │ │ CPU CPU CPU CPU这意味着多个 Python 线程终于可以同时执行 Python 代码。比如你的电脑有8核 CPU理论上Thread 1 → Core 1 Thread 2 → Core 2 Thread 3 → Core 3 Thread 4 → Core 4可以真正并行运行。这就是 Free-threading 最核心的意义。七、怎么判断自己是不是 Free-threaded PythonPython 3.14 提供了新的检测方式importsysprint(sys._is_gil_enabled())如果返回True说明当前运行时 GIL 开启。如果False说明当前进程运行在关闭 GIL 的状态。官方文档也建议使用sys._is_gil_enabled()判断当前运行时 GIL 是否启用。还可以查看python-VV如果使用的是自由线程构建版本版本信息会包含相应的 free-threading 标识。八、那么 Python 3.14 多线程到底有多快这里是最容易被营销文章带偏的地方。千万不要理解成“Python 3.14 多线程 性能直接提升 4 倍、8 倍甚至几十倍。”没这么简单。因为 Free-threading 本身也需要付出代价。为了让多个线程同时操作 Python 对象CPython 必须改变很多底层机制。例如引用计数 对象访问 内存分配 垃圾回收 线程同步 C API因此无 GIL 并不是免费的。官方文档显示Python 3.14 的自由线程构建在单线程运行时仍存在额外开销官方基准数据显示平均开销大致在几个百分点范围内具体取决于平台和工作负载。这就意味着普通 Python 单线程 ↓ 性能可能更好而Free-threaded Python 单线程 ↓ 可能有额外开销但Free-threaded Python 多个 CPU 密集型线程 ↓ 可以真正利用多核所以真正有价值的是牺牲一部分单线程性能换取多线程并行能力。九、一个简单的 CPU 多线程测试我们可以写一个非常简单的例子importthreadingimporttimedefcalculate():total0foriinrange(20_000_000):totalireturntotaldefworker():calculate()starttime.perf_counter()threads[]for_inrange(4):tthreading.Thread(targetworker)threads.append(t)t.start()fortinthreads:t.join()print(f耗时:{time.perf_counter()-start:.2f}s)在传统 CPython 中4个线程 ↓ GIL ↓ 无法真正同时执行 Python 字节码而在 Free-threaded Python4个线程 ↓ 无GIL ↓ 多个CPU核心 ↓ 真正并行当然这只是一个演示。真正的性能测试必须考虑CPU型号 Python版本 线程数 任务大小 编译方式 操作系统 第三方库 缓存 内存带宽不能只跑一次然后宣布“Python 3.14 快了 400%。”那是不严谨的。十、是不是以后 threading 可以替代 multiprocessing答案是不能简单这么说。Free-threading 最大的变化是threading终于可以真正利用多核执行 Python 代码。但multiprocessing仍然有自己的价值。两者最大的区别仍然存在。threading多个线程一个进程 │ ┌──┼──┐ ↓ ↓ ↓ T1 T2 T3共享内存 对象 进程资源优点通信方便 内存共享 创建成本低缺点线程安全问题 共享状态复杂 第三方库兼容性multiprocessing多个进程Process 1 Process 2 Process 3 Process 4每个进程有独立地址空间。优点隔离性强 传统 Python 生态成熟 不依赖 GIL缺点进程创建成本 进程间通信 数据序列化 内存占用所以未来很可能不是threading 取代 multiprocessing而是threading multiprocessing asyncio根据任务选择。十一、AI开发者尤其值得关注如果你做 AI 软件开发那么 Free-threading 的意义其实非常值得关注。例如一个 AI 服务用户请求 ↓ FastAPI ↓ 调用模型 ↓ RAG ↓ 向量检索 ↓ 文档处理 ↓ 结果生成一个请求可能同时包含PDF解析 文本处理 Embedding Rerank 数据转换 JSON处理如果其中存在大量 CPU 密集型 Python 逻辑那么 Free-threading 就可能提供新的优化空间。尤其是文档处理 数据清洗 RAG Pipeline 文本切分 JSON处理 本地推理前处理 批量任务这些场景都值得测试。但是不能看到“无 GIL”三个字就直接认为 AI 服务会自动提速。如果你的程序主要时间都花在OpenAI API Azure OpenAI 数据库 Redis 网络请求 GPU推理那么真正的瓶颈可能根本不是 GIL。十二、asyncio 也发生了变化Python 3.14 对 Free-threaded Python 的支持并不只影响threading。asyncio也开始更好地适配自由线程环境。传统情况下asyncio ↓ Event Loop ↓ 一个线程非常适合HTTP WebSocket 数据库 网络 I/O但如果一个事件循环里出现大量 CPU 密集型 Python 工作Event Loop ↓ CPU计算 ↓ 阻塞那么仍然会成为瓶颈。在 Free-threaded Python 下可以让不同线程中的事件循环真正并行运行。Python 3.14 的文档已经专门增加了 asyncio 与 free-threading 的说明。这意味着未来 Python 的并发模型可能越来越丰富Python │ ┌──────────┼──────────┐ ↓ ↓ ↓ asyncio threading multiprocessing │ │ │ I/O CPU并行 进程隔离这其实比简单的“Python终于没有 GIL 了”更加重要。十三、但是第三方库怎么办这才是 Free-threading 真正落地过程中最大的挑战之一。你的 Python 项目不可能只有Python标准库还会使用numpy pandas torch opencv pydantic requests 各种数据库驱动 各种AI SDK很多 Python 库底层包含C C Rust Cython等扩展。这些扩展必须正确处理 Free-threading 环境。否则Python无GIL ↓ 第三方扩展 ↓ 假设GIL一定存在 ↓ 线程安全问题因此Python 本身支持无 GIL不代表所有第三方库马上都支持。Python 官方文档也明确提醒一些特别是带扩展模块的第三方包目前可能还不适用于自由线程构建并可能重新启用 GIL。这也是为什么现在还不能说“从 Python 3.14 开始所有 Python 程序都应该切换到无 GIL。”还远远没有到这个阶段。十四、Free-threading 会不会让 Python 代码更难写可能会。因为过去很多 Python 程序员实际上享受了 GIL 带来的某些“隐形保护”。例如counter1当多个线程共享counter时开发者不能把它简单理解为绝对线程安全。Free-threading 后程序真正拥有更强的并行能力也意味着线程安全问题会更加真实地暴露出来。以后你会越来越频繁地需要fromthreadingimportLock lockLock()withlock:counter1也就是说更高并发 ↓ 更高性能 ↓ 更多并发问题这其实是所有多线程编程都绕不开的问题。十五、list、dict 是不是就线程安全了这是一个非常容易产生误解的问题。有人看到 Free-threading 后会说“那 Python 的 dict 和 list 以后就是线程安全的了”不能这么理解。Free-threaded CPython 当前会在dict、list、set等内置类型内部使用锁等机制以避免某些并发修改导致的底层问题。但是官方明确提醒不要把这些内部锁当成 Python 层面永久的线程安全保证。正确做法仍然是threading.Lock或者其他明确的同步机制。也就是说不要依赖实现细节。你的业务逻辑需要共享状态时仍然应该主动设计线程同步。十六、Python 3.14还有一个非常有意思的东西JIT除了 Free-threadingPython 3.14 还有另一个非常值得关注的方向JIT 编译器。JITJust-In-Time Compilation简单理解传统 PythonPython代码 ↓ 解释器 ↓ 执行JITPython代码 ↓ 解释器 ↓ 热点代码 ↓ JIT编译 ↓ 机器码 ↓ 执行Python 3.14 的官方 macOS 和 Windows 发布二进制已经包含实验性的 JIT 编译器可以通过PYTHON_JIT1进行测试。但是目前不建议用于生产环境。官方文档也指出这个 JIT 仍处于早期阶段不同工作负载下可能出现明显的性能波动。而且一个非常有意思的地方是Free-threaded build 目前不支持 JIT。所以 Python 3.14 实际上出现了两条不同的性能探索路线Python 3.14 │ ┌────┴────┐ ↓ ↓ Free- JIT threading ↓ ↓ 多线程 单线程/ 多核 热点优化这两个方向目前并不是简单叠加。十七、Python 3.14还有哪些值得关注的新东西如果你只是关注 Free-threading会错过不少 Python 3.14 的变化。例如① Template String也就是tHello {name}相比传统 f-stringt-string 更强调模板处理能力。② ZstandardPython 3.14 标准库增加了compression.zstd可以直接处理 Zstandard 压缩。③ 多解释器能力Python 3.14 进一步增强了Interpreter相关能力。多解释器可以让一个进程内部拥有多个独立的 Python 解释器环境。这也是 Python 并发模型未来非常值得关注的方向。十八、Python 3.14真正重要的是什么如果让我用一句话总结Python 3.14 并不是“Python突然没有GIL了”而是Python正式进入了一个可以逐步摆脱GIL限制的新阶段。这个区别非常重要。Python 3.13Free-threading ↓ 实验Python 3.14Free-threading ↓ 官方支持 ↓ 但仍然可选未来Free-threading ↓ 生态完善 ↓ 第三方库适配 ↓ 性能优化 ↓ ???最终 Python 会不会进入默认无GIL目前还不能下结论。十九、现在要不要立刻切换到 Free-threaded Python我的建议普通 Web 开发暂时没必要。例如Django Flask FastAPI如果你的主要瓶颈是数据库 网络 Redis HTTP API那么 GIL 可能根本不是你的核心瓶颈。AI 应用开发非常值得关注但不要盲目切换。建议普通 Python ↓ 跑基准测试 ↓ Free-threaded Python ↓ 再次测试 ↓ 比较性能尤其测试PDF解析 文本处理 Embedding前处理 RAG数据处理 批量任务 CPU密集型代码CPU 密集型 Python 程序非常值得尝试。例如计算 数据处理 图像处理 算法 大量 Python 循环这才是 Free-threading 最可能真正发挥价值的地方。二十、一个程序员应该如何看待 Python 3.14我觉得可以把 Python 3.14 看成一个“新时代的起点”而不是“GIL已经消失的终点”。过去Python ↓ GIL ↓ CPU密集型多线程受限现在Python 3.14 ↓ ┌─────┴──────┐ ↓ ↓ 传统构建 Free-threaded ↓ ↓ 有GIL 无GIL以后Python生态 ↓ 第三方库逐步适配 ↓ 工具链逐步完善 ↓ 性能持续优化 ↓ Free-threading越来越成熟这才是整个故事真正有意思的地方。二十一、最后Python真的终于可以多线程了吗答案是可以但要加三个限定词。第一可以真正多线程执行 Python 代码。在 Free-threaded build 中GIL 可以被关闭多个线程能够在多个 CPU 核心上并行执行 Python 代码。第二Python 3.14 默认还是有 GIL。你安装普通 Python 3.14并不会自动进入无 GIL 模式。第三生态还在适配。第三方 C/C/Cython 等扩展是否支持 Free-threading会直接影响实际应用。所以最准确的标题其实应该是Python 3.14来了Python终于正式迈入“无GIL时代”但还不是默认模式这比“Python 3.14彻底移除了GIL”严谨得多。写在最后Python 发展到今天最有意思的地方并不是某一个新语法而是它正在发生一次非常深层的变化。过去几十年Python 最大的优势之一是简单 易学 开发效率高 生态庞大而现在 Python 社区正在努力解决另一个问题如何让 Python 在保持开发效率的同时进一步提高多核 CPU 的利用率和运行性能于是我们看到了Free-threading JIT 多解释器同时 Python 生态外部也出现了uv Ruff Rust 高性能Web Server这其实说明一个非常明显的趋势Python 正在从“开发效率优先”逐渐走向“开发效率 工程性能”并重。所以如果你是一名 Python 开发者现在不一定需要马上把项目全部迁移到 Free-threaded Python。但是一定值得开始了解它。因为今天的Free-threaded Python可能就是未来几年 Python 性能演进最重要的方向之一。而 Python 3.14可能只是这个时代真正开始的第一站。 一张图记住 Python 3.14 的变化Python 3.14 │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Free-threading JIT 新语言/标准库 │ │ │ 无GIL 实验性 t-string │ │ Zstandard │ │ 多解释器 ↓ ↓ ↓ 多核并行 性能优化 开发体验 │ ↓ 但目前仍然是可选模式所以Python 3.14 最准确的一句话不是“Python 没有 GIL 了”而是Python 终于正式把“没有 GIL 的 Python”从实验室带到了官方支持阶段。而真正值得期待的是接下来几年整个 Python 生态会如何跟上这场变化。