诸如Java's weak hash map之类的弱哈希表使用弱引用来跟踪垃圾收集器无法访问的键的集合，并从该集合中删除与该键的绑定。弱哈希表通常用于实现从图形的一个顶点或边缘到另一顶点或边缘的间接访问，因为它们允许垃圾收集器收集图形的不可达部分。
是否存在与该数据结构完全相同的功能？如果没有，将如何创建？
这似乎是一个有趣的挑战。内部实现不能是纯粹的，因为它必须收集（即变异）数据结构以删除无法访问的部分，但我相信它可以为用户提供一个纯接口，该用户永远不会观察到杂质，因为它们只会影响数据的一部分。根据定义，用户无法再访问的结构。
最佳答案
这是一个有趣的概念。 “纯功能”设置中的一个主要并发症是，在“纯功能”意义上通常无法观察到对象身份。即，如果我复制一个对象或创建一个新的相同对象，则在Java中预期克隆不是原始对象。但是，在功能设置上，即使垃圾收集器将以不同的方式对待，也希望新的在语义上与旧的在语义上相同。
因此，如果我们允许对象身份成为语义的一部分，那将是合理的，否则可能不是。在后一种情况下，即使可以发现骇客（我想到了一个，如下所述），您也可能会在各处使用语言实现，因为它会做各种事情来利用这一事实。该对象身份不应被观察到。
我脑海中浮现的一种“骇客”将是使用构造唯一值作为键，这样，在大多数情况下，值相等将与引用相等重合。例如，我在Haskell中有一个个人使用的库，其界面中包含以下内容：
data Uniq s
getUniq :: IO (Uniq RealWorld)
instance Eq (Uniq s)
instance Ord (Uniq s)
像您描述的那样，散列图可能主要将它们用作键，但是即使在这里，我也可以想到它可能会损坏：假设用户将键存储在某些数据结构的严格字段中，而编译器的“ unbox-严格字段”优化已启用。如果“ Uniq”只是机器整数的新类型包装器，则可能不再存在GC可以指向并说“那是关键”的任何对象；因此，当用户打开并解开密钥以使用它时，地图可能已经忘记了它。 （编辑：这个特定的例子显然可以解决;使Uniq的实现不能像这样被拆箱;关键在于它很棘手，因为编译器试图以很多方式提供帮助，而我们可能不会这样做期望）
TL; DR：我不会说这无法完成，但是我怀疑在许多情况下，“优化”可能会被弱哈希映射实现破坏，或者被弱哈希映射实现破坏，除非为对象标识赋予一流的可观察状态。
关于data-structures - 纯函数等同于weakhashmap？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4713906/