Python 中最大的性能瓶颈是否终于被克服了? Python 中最大的性能瓶颈是否终于被克服了?

Python 中最大的性能瓶颈是否终于被克服了?

Python Python 3.13 现已发布, 全局解释器锁的终结可能指日可待

Python 全局解释器锁 (GIL) 本质上是一个守门人,它一次只允许一个线程控制 Python 解释器。这意味着无论你运行多少个线程或 CPU 核心,任何时刻都只有一个线程在执行 Python 代码。

如果你编写的是单线程程序,你甚至不会注意到 GIL 的存在。但如果你运行的是 CPU 密集型的多线程代码,你就会感受到它的影响——它很快就会成为性能瓶颈。这就是为什么 GIL 在 Python 世界里臭名昭著,尤其是在多线程应用程序中,它会占用大量的 CPU 资源。

很多人从未遇到过这种情况,因为单线程 Python 程序并不在意,但当你尝试扩展规模时,你可能会遇到瓶颈。

为什么Python需要GIL?

Python 使用引用计数来管理内存。每个对象都有一个计数器,用于跟踪指向它的引用数量。当该数字归零时,Python 就会释放内存。

然而,如果多个线程同时递增和递减计数器,很快就会陷入混乱。为了避免这种情况,Python 可以锁定每个共享对象以防止竞态条件。但是,更多的锁意味着更多的死锁风险,而死锁本身就很麻烦。因此,Python 采取了一种捷径:在解释器上加一个锁。这保持了简洁——避免了死锁——但代价是:在处理 CPU 密集型任务时,Python 的多线程实际上变成了单线程。

当然,这会对你的代码产生多大影响取决于代码本身。如果你的代码是 I/O 密集型的,那就没有任何区别;但对于 CPU 密集型系统,Python 的性能一直落后于真正的多线程代码。

GIL消亡了吗?

从 3.13 版本开始,新增了一种实验模式:

CPython 现在实验性地支持以自由线程模式运行,该模式下全局解释器锁(GIL) 将被禁用。这是一项实验性功能,因此默认情况下未启用。

自由线程执行允许通过在可用的 CPU 核心上并行运行线程来充分利用可用的处理能力。虽然并非所有软件都能自动受益于此,但那些在设计时就考虑到了线程的程序在多核硬件上运行速度会更快。自由线程模式目前处于实验阶段,相关工作仍在进行中:预计会存在一些错误,并且单线程性能会受到显著影响。CPython 的自由线程版本支持在运行时选择性地启用 GIL,可以使用环境变量PYTHON_GIL或命令行选项-X gil=1

我猜他们会先进行一段时间的试验,直到几乎所有人都在使用,然后再将其作为标准配置。

这会是 Python 4 的功能吗?目前 Python 4 还没有发布计划,但我认为这不需要一个“重大版本号”。语言本身并没有改变,改变的只是底层引擎,所以不用担心会破坏用户的代码。如果一切顺利,这项功能在 3.20 版本之前就能普及。