缓存（弱字典）

需要允许维护表示外部状态的对象，将单个实例映射到外部现实，如果允许将多个实例映射到同一个外部资源，则会造成在实例之间维护同步的不必要的困难。在这些情况下，一个常见的习惯用法是支持实例缓存；工厂函数用于返回新的或现有的实例。

这种方法的难点在于必须容忍以下两种情况之一：缓存无限增长，或者需要在应用程序的其他地方显式管理缓存。后者可能非常乏味，并且会导致比解决手头问题真正需要的代码更多，而前者对于长时间运行的进程甚至内存需求很大的相对较短的进程来说都是不可接受的。

• 需要由单个实例表示的外部对象，无论有多少内部用户。这对于表示需要整体写入磁盘的文件很有用，而不是为每次使用都锁定和修改。
• 创建成本高昂但可能被多个内部使用者需要的对象。类似于第一种情况，但不一定绑定到外部资源，并且可能不是共享状态的问题。只有在某种“软”引用或单个对象的使用者生命周期重叠的可能性很高的情况下，弱引用在这种情况下才有用。

循环引用

• DOM 需要大量的循环（到父级和文档节点）引用，但这些可以通过使用从每个节点到其父级的弱字典映射来消除。这在诸如 xml.dom.pulldom 之类的内容的上下文中可能特别有用，允许 .unlink() 操作成为一个空操作。

本提案分为以下几个部分

• 提议的解决方案
• 实现策略
• 可能的应用
• Python 中之前的弱引用工作
• Java 中的弱引用

由于一个早期提案的全文似乎在网络上不可用，因此将其作为附录包含在内。

失效

过去，弱引用失效的方法通常依赖于存储强引用并能够检查所有弱引用对象实例，并在其被引用者的引用计数变为 1 时使其失效（表示弱引用存储的引用是最后一个剩余的引用）。这样做的优点是 Python 中的内存管理机制不需要改变，并且任何类型都可以被弱引用。

这种失效方法的缺点是，它假设弱引用的管理被调用得足够频繁，以便在合理的时间范围内注意到弱引用的对象；由于这意味着扫描某些数据结构以使引用失效，这是一个关于弱引用对象数量的 O(N) 操作，因此对于任何单个被弱引用的对象来说，这并没有得到有效地摊销。这也假设应用程序正在调用处理弱引用对象的代码，并且具有一定的频率，这使得弱引用对库代码的吸引力降低。

另一种失效方法是使释放代码意识到弱引用的可能性，并在每次对象被释放时，对弱引用管理代码进行特定调用以全部失效。这需要更改弱引用对象的 tp_dealloc 处理程序；对于支持弱引用的对象，在处理程序的“顶部”需要额外的调用，并且还需要一种有效的方法来从对象映射到该对象的弱引用链。

表示

弱引用在 Python 层的表示方式有两种：作为显式引用对象，需要在其上执行某些操作才能检索到对底层对象的可用引用，以及尽可能地伪装成原始对象的代理对象。

当在 Python 中添加一些额外的对象管理层时，引用对象易于使用；可以显式地检查引用是否存活，而无需对被引用者调用操作并捕获在使用无效弱引用时引发的某些特殊异常。

然而，许多用户更喜欢代理方法，仅仅是因为弱引用看起来非常像原始对象。

提案：虚拟引用

为了尝试部分解决关于引用计数与垃圾回收的反复讨论，我想提出对 Python 的一个扩展，这将有助于创建“结构良好”的循环图。特别是，它应该允许至少创建带有父级反向指针的树和双向链表，而无需担心循环。

我想提出的基本机制是“虚拟引用”，或简称“vref”。vref 本质上是对一个对象的句柄，它不会增加对象的引用计数。这意味着持有对对象的 vref 不会阻止该对象被销毁。这将允许 Python 程序员例如创建上述树结构，该结构在不再使用时会自动销毁 - 通过将所有父级反向引用都设为 vref，它们不再创建阻止树被销毁的引用循环。

为了实现此机制，Python 核心必须确保永远不会留下任何 -真实- 指针来引用不再存在的对象。我想提出的实现涉及对当前 Python 系统的两个基本添加

1. 一种新的“vref”类型，通过它 Python 程序员可以创建和操作虚拟引用。在内部，它基本上是一个 C 级的 Python 对象，带有指向它所引用的 Python 对象的指针。但是，与所有其他 Python 代码不同，它不会更改此对象的引用计数。此外，它包含两个指针来实现一个双向链表，该链表在下面使用。
2. 在基本 Python 对象[PyObject_Head in object.h]中添加一个新字段，该字段要么为 NULL，要么指向引用它的所有 vref 对象列表的头部。当一个 vref 对象附加到另一个对象时，它会将自己添加到此链表中。然后，如果任何 vref 存在于其上的对象被释放，它可能会遍历此列表并确保其上的所有 vref 都指向某个安全值，例如 Nothing。

希望此实现对当前 Python 核心产生的影响最小 - 当不存在 vref 时，它应该只向所有对象添加一个指针，并在每次对象被释放时检查一个 NULL 指针。

回到 Python 语言级别，我考虑了 vref 对象的两种可能的语义 -

指针语义

在此模型中，vref 的行为本质上类似于 Python 级的指针；Python 程序必须显式地取消引用 vref 以操作它所引用的实际对象。

使用此模型的示例 vref 模块可以包含函数“new”；当用作‘MyVref = vref.new(MyObject)’时，它返回一个新的 vref 对象，使得 MyVref.object == MyObject。如果 MyObject 曾经被释放，则 MyVref.object 将更改为 Nothing。

举一个具体的例子，我们可以引入一些新的 C 样式语法

• & – 一元运算符，在对象上创建 vref，与 vref.new() 相同。
• * – 一元运算符，取消引用 vref，与 VrefObject.object 相同。

然后我们可以定义

1.     type(&MyObject) == vref.VrefType
2.        *(&MyObject) == MyObject
3. (*(&MyObject)).attr == MyObject.attr
4.          &&MyObject == Nothing
5.           *MyObject -> exception

规则 #4 很微妙，但它之所以出现是因为我们对（没有真实引用的 vref）创建了一个 vref。因此，当内部 vref 不可避免地消失时，外部 vref 将被清除为 Nothing。

代理语义

在此模型中，Python 程序员操作 vref 对象的方式就像操作它所引用的对象一样。这是通过实现 vref 来完成的，以便对其进行的所有操作都重定向到其引用的对象。使用此模型，取消引用运算符 (*) 变得毫无意义；相反，我们只有引用运算符 (&)，并定义

1.  type(&MyObject) == type(MyObject)
2.        &MyObject == MyObject
3. (&MyObject).attr == MyObject.attr
4.       &&MyObject == MyObject

同样，规则 #4 非常重要 - 在这里，外部 vref 实际上是对原始对象的引用，而不是内部 vref。这是因为应用于 vref 的所有操作实际上都应用于其对象，因此创建 vref 的 vref 实际上会导致创建后者对象的 vref。

第一个指针语义的优点是它很容易实现；vref 类型非常简单，至少需要一个属性 object 和一个创建引用的函数。

但是，我真的很喜欢代理语义。它不仅减少了 Python 程序员的负担，而且允许您执行诸如在任何使用实际对象的地方使用 vref 之类的好事。不幸的是，在当前的 Python 实现中，实现它可能非常痛苦，甚至实际上不可能。不过，我确实有一些关于如何做到这一点的想法，如果它看起来很有趣；一种可能性是引入新的类型检查函数来处理 vref。这将希望较旧的 C 模块（不希望 vref 简单地返回类型错误）能够修复，直到它们可以被修复为止。

最后，此系统可以提供一些其他附加功能。对我来说，一个特别有趣的功能涉及允许 Python 程序员向 vref 添加“析构函数” - 此 Python 函数将在被引用对象被释放之前立即被调用，允许 Python 程序隐式地附加到另一个对象并观察它是否消失。这看起来很不错，尽管我还没有想出任何实际用途…… :)

– Dianne