本文目录导读：
关于Python全局解释器锁的移除进展,目前最核心的成果是 PEP 703（Making the Global Interpreter Lock Optional，使全局解释器锁可选），它正逐步成为现实。
移除全局解释器锁的“自由线程”模式已经作为一项实验性功能，在2023年10月发布的Python 3.13中首次推出，但距离成为默认选项，以及所有第三方库完全兼容，还有相当长的路要走。
以下是详细的进展和时间线：
核心进展：Python 3.13 的实验性全局解释器锁禁用特性
- Python 3.13 (2024年10月发布)：这是第一个包含
--disable-gil构建选项的稳定版本，你可以下载一个“自由线程”版本的Python 3.13来试用。 - 如何尝试：你需要从官方网站或通过
pyenv安装一个名字里带有-freethreading或通过特定编译选项构建的版本，安装后，运行python时，全局解释器锁就是关闭的。 - 效果：在纯CPU密集型的多线程计算中，性能有显著提升，使用
threading模块并行计算大型矩阵乘法时，速度可以接近线性提升。 - 当前限制：
- 不是默认选项：官方发布的Python 3.13安装包默认仍然是开启全局解释器锁的，你需要专门下载自由线程版本。
- 性能损失：在单线程或I/O密集型的任务中，禁用全局解释器锁会因增加的内存管理开销（如引用计数的原子操作）而导致大约5%-10%的性能下降，这是为了支持多线程安全付出的代价。
未来规划：Python 3.14 及更远的目标
-
Python 3.14 (预计2025年10月发布)：这是关键的一年。
- 目标是将自由线程模式从“实验性”升级为 “稳定支持”，这意味着核心团队会保证它正常工作，不会有大的破环性变更。
- 更重要的是,预计会开始提供“默认禁用全局解释器锁”的安装包（在
python.org下载时，可能多一个“推荐给新用户”的选项）。
-
Python 3.15+ (2026年及以后)：
- 如果一切顺利,在Python 3.15或3.16中，禁用全局解释器锁有可能会成为安装程序的默认选项，但这取决于生态兼容性是否足够高。
- 一个极其重要的前提：CPython核心团队明确表示，必须等到
numpy、pandas、scikit-learn等核心科学计算库以及其他关键扩展库，都完成对自由线程模式的适配并发布稳定版本后，才会考虑将其设为默认。
面临的巨大挑战：生态兼容性
这是全局解释器锁移除最棘手、最漫长的部分，Python的强大在于其丰富的C扩展库（如 numpy、tensorflow、lxml 等），它们很多都直接依赖全局解释器锁来保证内部数据结构的安全。
- 现状：在2024年末，绝大多数C扩展库在自由线程模式下会直接崩溃或产生不可预测的结果，所有依赖于
PyGILState_Ensure()、Py_BEGIN_ALLOW_THREADS等宏的代码，都需要进行重大修改。 - 核心团队的努力：PEP 703的作者们正在开发新的C API (
PyMutex、PyCriticalSection)，并提供迁移指南，像numpy、psutil等项目的核心开发者已经开始进行适配工作。 - 社区状态：这是由 Meta 的开发者（核心是 Sam Gross）主导推动的，许多大型公司（如字节跳动、Netflix）也在内部积极测试和贡献，但完整的适配可能还需要 2-4年。
全局解释器锁移除的现状一览
- 当前状态：实验性功能已可用，对于愿意折腾、想提前体验多线程性能优势的开发者，可以尝试Python 3.13的自由线程版本。
- 实用程度：生产环境不建议使用，除非你完全控制所有依赖库，并且它们都已适配，大部分应用（特别是Django、Flask等Web应用）几乎不受影响，因为它们主要是I/O密集型，使用多线程或异步编程已然足够。
- 最终目标：默认禁用全局解释器锁，但前提是充分兼容现有生态。
- 时间线：2025-2027年左右，乐观估计，在Python 3.15（2026年）或3.16（2027年）中，自由线程模式有希望成为默认选项。
对普通开发者的建议
- 现在：如果你只是写Web后端、自动化脚本或数据分析（单机版），完全不需要关心这个进展，全局解释器锁的移除对你的日常工作影响不大，因为你本就可以使用异步I/O或多进程来绕过全局解释器锁的限制。
- 如果你写CPU密集型多线程代码：可以尝试在开发环境中使用Python 3.13自由线程版做性能测试，但生产环境暂时用不了。
- 如果你维护一个C扩展库：应该开始关注PEP 703的迁移指南，并准备适配工作。
简而言之：全局解释器锁的“死亡”已有明确的路线图，但葬礼尚未确定日期，现在它正处于“实验性试用”阶段，距离全面普及还需数年。
