WeakHashMap 和并发修改

Question

我正在阅读有关WeakHashMap 的Java Doc，我了解了基本概念。 由于 GC 线程在后台运行，可能会出现“异常行为”，例如迭代时的 ConcurrentModificationException 等。

我不明白的是，如果默认实现不同步并且不包含任何方式的锁，那么为什么不可能获得不一致的状态。 假设你有 2 个线程。 GC线程删除某个索引处的某个键，同时在同一索引处，用户线程正在向数组中插入一个键值对。

对我来说，如果没有同步，那么得到不一致的哈希映射的风险很高。

更糟糕的是，这样做实际上可能非常危险，因为 v 实际上可能为 null。

if (map.contains(k)) {
   V v = map.get(k)
}

我错过了什么吗？

Answer 1

您提到的不一致状态问题不会出现，因为 GC 没有主动重构 WeakHashMaps。当垃圾收集器释放弱引用的引用时，相应的条目不会从映射中物理移除；条目只是变得陈旧，没有密钥。稍后，该条目可能会在地图上的其他一些操作期间被物理删除，但 GC 不会承担该责任。

您可以在grepcode 上查看此设计的一个 Java 版本的实现。

Answer 2

您所描述的是文档明确指出的内容：

因为垃圾收集器可能随时丢弃键，WeakHashMap 可能表现得好像一个未知线程正在默默地删除条目。

您犯的唯一错误是假设您可以通过同步来保护状态。这不起作用，因为同步在 GC 方面不是相互的。引用文档：

特别是，即使您在 WeakHashMap 实例上进行同步并且不调用它的任何 mutator 方法，size 方法也有可能随着时间的推移返回较小的值，isEmpty 方法返回 @987654325 @ 然后true，对于containsKey 方法返回true 和稍后的false 对于给定键，对于get 方法返回给定键的值但稍后返回null，对于put 方法返回 null 和 remove 方法返回 false 对于以前出现在映射中的键，以及对键集、值集合和条目集的连续检查依次产生较少数量的元素。

Answer 3

参考

即使您在 WeakHashMap [...] 上进行同步，size 方法也有可能随着时间的推移返回较小的值

javadoc 向我充分解释了存在不一致状态的可能性，并且它完全独立于同步。

后面的几个例子，给定的例子也被引用：

containsKey 方法为给定的键返回 true 和 false

所以基本上，永远不要依赖WeakHashMap 的状态。但尽可能地使用它。因此，给定的示例应改写为

V v = map.get(k);
if(null != v) {
}

或

Optional.ofNullable(map.get(k)).ifPresent(() -> { } );

Answer 4

此类主要用于关键对象，其 equals 方法使用 == 运算符测试对象身份。一旦这样的键被丢弃，它就永远无法重新创建，因此以后不可能在 WeakHashMap 中查找该键并惊讶于它的条目已被删除。

因此，如果将WeakHashMap 用于其equals() 基于身份检查的对象，那么一切都很好。您提到的第一种情况（“一个 GC 线程同时在同一索引处删除某个键，用户线程正在数组中插入一个键值对。”）是不可能的，因为只要用户线程保持对关键对象的引用，它不能被 GC 丢弃。

第二个例子也是如此：

if (map.contains(k)) {
   V v = map.get(k)
}

您保留引用k，因此相应的对象是可访问的并且不能被丢弃。

但是

这个类可以很好地与等于的关键对象一起工作 方法不基于对象标识，例如 String 实例。 但是，对于此类可重新创建的关键对象，自动删除 其键已被丢弃的 WeakHashMap 条目可能被证明是 令人困惑。