Python 的Immortal Objects

Instagram 向 Python 引入了 Immortal Objects – PEP-683。现在，对象可以绕过引用计数检查并在运行时的整个执行过程中存活，从而为真正的并行性解锁了令人兴奋的途径。

在 Meta，程序员们使用 Python (Django) 作为 Instagram 中的前端服务器。为了处理并行性，程序员依靠多进程架构以及 asyncio 来实现每进程并发。然而，他们的规模——无论是业务逻辑还是处理的请求量——可能会导致内存压力增加，从而导致效率瓶颈。

为了减轻这种影响，程序员依靠预分叉 Web 服务器架构来缓存尽可能多的对象，并让每个单独的进程通过共享内存将它们用作只读结构。虽然这很有帮助，但经过仔细检查，程序员发现进程的私有内存使用量随着时间的推移而增加，而共享内存却减少了。

通过分析 Python 堆，程序员发现虽然大多数 Python 对象实际上是不可变的，并且在运行时的整个执行过程中都存在，但最终仍然通过引用计数和垃圾收集 (GC) 操作来修改这些对象，这些操作会改变对象的每个读取和 GC 周期上的元数据 - 因此，在服务器进程上 触发写入时复制。

Python的Immortal Objects

共享对象的状态突变问题是 Python 运行时工作原理的核心。鉴于它依赖于引用计数和循环检测，运行时需要修改对象的核心内存结构，这是该语言需要全局解释器锁（GIL）的原因之一。

为了解决这个问题，程序员引入了Immortal Objects - PEP-683。这通过在对象的引用计数字段中标记特殊值来创建一个Immortal Objects（核心对象状态永远不会改变的对象）。它允许运行时知道何时可以改变引用计数字段和 GC 标头。

Standard Objects与Immortal Objects的比较。使用标准对象，用户可以保证它不会改变其类型和/或其数据。不朽性增加了额外的保证，即运行时不会修改引用计数或 GC 标头（如果存在），从而实现完全的对象不变性。

由于相对孤立的环境，在 Instagram 中实施和发布此内容是一个相对简单的过程，但向社区分享此内容是一个漫长而艰巨的过程。这大部分是由于解决方案的实现造成的，它必须处理诸如向后兼容性、平台兼容性和性能下降等问题。

首先，实现必须保证，即使在更改引用计数实现之后，如果某些对象突然具有不同的引用计数值，应用程序也不会崩溃。

其次，它改变了 Python 对象的核心内存表示以及增加其引用计数的方式。它需要跨所有不同的平台（Unix、Windows、Mac）、编译器（GCC、Clang 和 MSVC）、架构（32 位和 64 位）以及硬件类型（小端和大端）工作。

最后，核心实现依赖于在引用计数递增和递减例程中添加显式检查，这是整个运行时执行中最热门的两个代码路径。这不可避免地意味着服务性能下降。幸运的是，通过巧妙地使用寄存器分配，程序员成功地将每个系统的回归降低到了约 2%，使其成为其带来的好处的合理回归。

Immortal Objects 如何影响 Instagram

对于 Instagram，最初的重点是通过减少写入时的复制来提高处理请求的内存和 CPU 效率。通过Immortal Objects，程序员通过增加共享内存使用量来大大减少私有内存。

通过Immortal Objects增加共享内存的使用使得能够显着减少私有内存。减少写入时的副本数量。

然而，这些变化的影响远远超出了 Instagram 的范围，还影响到了 Python 作为一种语言的演变。到目前为止，Python 的局限性之一是它无法保证堆上对象的真正不变性。GC 和引用计数机制都可以不受限制地访问这两个字段。

将Immortal Objects贡献给 Python 首次引入了真正的不变性保证。它帮助对象绕过引用计数和垃圾收集检查。这意味着现在可以跨线程共享Immortal Objects，而不需要 GIL 提供线程安全性。

这是构建多核 Python 运行时的重要构建块。有两个提案利用Immortal Objects以不同的方式实现这一目标：

PEP-684：每个解释器的 GIL

PEP-703：在 CPython 中使全局解释器锁成为可选