在 get() 返回 null 之前，ConcurrentMap.remove() 是否提供先发生边缘？

Question

在调用ConcurrentMap.remove() 之前线程中的操作是否保证happen-before 在看到从另一个线程中删除之后的操作？

Documentation 表示关于放入集合中的对象：

将对象放入任何并发集合之前线程中的操作发生在另一个线程中从集合中访问或删除该元素之后的操作。

示例代码：

{
    final ConcurrentMap map = new ConcurrentHashMap();
    map.put(1, new Object());

    final int[] value = { 0 };

    new Thread(() -> {
        value[0]++;
        value[0]++;
        value[0]++;
        value[0]++;
        value[0]++;

        map.remove(1); // A

    }).start();

    new Thread(() -> {
        if (map.get(1) == null) { // B
            System.out.println(value[0]); // expect 5
        }

    }).start();
}

A 是否与 B 处于 happens-before 关系中？因此，程序是否应该只打印 5？

Answer 1

您发现这些并发工具的一个有趣的微妙方面很容易被忽视。

首先，不可能提供关于删除和检索null 引用的一般保证，因为后者仅证明不存在映射而不是先前的删除，即线程可以在键有映射之前读取映射的初始状态，这当然不能与之后发生的操作建立 happens-before 关系地图的构造。

另外，如果有多个线程删除同一个键，则在检索 null 时，您不能假设 happens-before 关系，因为您不知道哪个删除已完成.此问题类似于两个线程插入相同值的情况，但后者可以在应用程序端通过仅执行可区分值的插入或遵循对正在执行的值对象执行所需修改的通常模式来解决插入并仅查询检索到的对象。对于删除，没有这样的修复。

在您的特殊情况下，map.put(1, new Object()) 操作与第二个线程的开始之间存在 happens-before 关系，因此如果第二个线程在查询键 @987654327 时遇到 null @，很明显，它见证了您的代码的唯一删除，但规范并没有费心为这种特殊情况提供明确的保证。

相反，Java 8’s ConcurrentHashMap 的规范说，

检索反映了最近完成更新操作在开始时保持的结果。 （更正式地说，给定键的更新操作与报告更新值的键的任何（非空）检索具有 happens-before 关系。）

明确排除 null 检索。

我认为，使用当前 (Java 8) ConcurrentHashMap 实现，您的代码不会中断，因为它相当保守，因为它使用 volatile 语义执行对其内部支持数组的所有访问。但这只是当前的实现，如上所述，您的代码是一种特殊情况，可能会随着实际应用程序的每次更改而损坏。

Answer 2

不，你的顺序错了。

从put() 到随后的get() 之间有一个happens-before 边。该边缘不是对称的，并且在另一个方向上不起作用。从get() 到另一个get() 或remove()，或从put() 到另一个put()，没有happens-before边。

在这种情况下，您在地图中放置了一个对象。然后你修改另一个对象。那是不行的。在第二个线程中对get() 的写入没有优势，因此第二个线程可能看不到这些写入。

在英特尔硬件上，我认为这将始终有效。但是，Java 内存模型并不能保证这一点，因此如果您将此代码移植到不同的硬件上，请务必小心。

Answer 3

A 不需要在 B 之前发生。

只有原始的put 发生在两者之前。因此，B 处的 null 意味着 A 发生了。

但是没有提到线程本地内存缓存的写回和++和remove的指令顺序。 volatile 未使用；而是使用 Map 和数组来希望保持线程数据同步。在写回数据时，有序关系应该再次保持。

据我了解，A 可以删除并被写回，然后最后一个 ++ 发生，并且在 B 处打印类似 4 的内容。我会将 volatile 添加到数组中。地图本身会很好。

我不太确定，但由于我没有看到相应的答案，所以我伸出了脖子。 （自学。）

Answer 4

由于 ConcurrentHashMap 是一个线程安全的集合，如果语句 map.remove(1) 改变了映射，它必须有一个读屏障和一个写屏障。表达式map.get(1) 必须有一个或一个读屏障，或者这两个操作都不是线程安全的。

实际上直到 Java 7 的 ConcurrentHashMap 都使用分区锁，因此它几乎对每个操作都有一个读/写屏障。

ConcurrentSkipListMap 不必使用锁，但要执行任何线程安全的写操作，就需要写屏障。

这意味着您的测试应始终按预期运行。