WeakHashMap与并发修改

Question

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

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

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

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

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

我错过什么了吗？

Answer 1

指的是

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

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

在后面的几个例子中，也提到了给定的例子：

对于给定的键，该方法返回true，然后返回false

所以基本上，我们不应该依赖WeakHashMap的状态，而应该尽可能地使用它

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

或

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

Answer 2

您所描述的是文档中明确说明的内容：

因为垃圾回收器可能会在任何时候丢弃密钥，所以WeakHashMap的行为可能就像一个未知线程正在默默地删除条目一样。

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

特别是，即使您在WeakHashMap实例上进行了同步，并且没有调用其任何突变器方法，size方法也可以随着时间的推移返回较小的值，对于isShelty方法，返回false，然后返回true，对于给定键，对于容器键方法，返回true和后来的false，对于get方法，返回给定键的值，但随后返回null，对于put方法，返回null，对于以前在map中出现的键，对于连续检查键集，值集合和条目集，以相继产生较小数量的元素，对于put方法，返回null，对于之前在map中出现的键，以及对于键集，值集合和条目集的连续检查，返回false

Answer 3

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

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