如何保证 ConcurrentHashMap 的 get() 总是返回最新的实际值？

Question

简介
假设我有一个 ConcurrentHashMap 单例：

public class RecordsMapSingleton {

    private static final ConcurrentHashMap<String,Record> payments = new ConcurrentHashMap<>();

    public static ConcurrentHashMap<String, Record> getInstance() {
        return payments;
    }

}

然后我有来自不同来源的三个后续请求（均由不同线程处理）。
第一个服务发出请求，获取单例，创建 Record 实例，生成唯一 ID 并将其放入 Map，然后将此 ID 发送到另一个服务。
然后第二个服务使用该 ID 发出另一个请求。它获取单例，找到Record 实例并对其进行修改。
最后（可能半小时后）第二个服务发出另一个请求，以进一步修改Record。

问题
在一些非常罕见的情况下，我遇到了heisenbug。在日志中我可以看到，第一个请求成功地将Record 放入Map，第二个请求通过 ID 找到并修改它，然后第三个请求尝试通过 ID 查找记录，但什么也没找到（get() 返回@987654332 @)。
我发现关于ConcurrentHashMap 保证的唯一一点是：

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

来自here。如果我做对了，它的字面意思是，get() 可以返回任何实际存在于 Map 中的值，只要它不会破坏 happens-before 不同线程中的操作之间的关系。
在我的情况下，它是这样应用的：如果第三个请求不关心第一个和第二个处理过程中发生的事情，那么它可以从 Map 读取 null。

它不适合我，因为我真的需要从 Map 获取最新的实际 Record。

我尝试了什么
于是我开始思考，如何在后续的Map修改之间形成happens-before关系；并提出了想法。 JLS says（在 17.4.4 中）：

对 volatile 变量 v（第 8.3.1.4 节）的写入与所有变量同步 任何线程对 v 的后续读取（其中定义了“后续” 按同步顺序）。

所以，假设，我将像这样修改我的单例：

public class RecordsMapSingleton {

    private static final ConcurrentHashMap<String,Record> payments = new ConcurrentHashMap<>();
    private static volatile long revision = 0;

    public static ConcurrentHashMap<String, Record> getInstance() {
        return payments;
    }

    public static void incrementRevision() {
        revision++;
    }
    public static long getRevision() {
        return revision;
    }

}

然后，在每次修改 Map 或 Record 内部后，我将调用 incrementRevision()，在从 Map 读取任何内容之前，我将调用 getRevision()。

问题
由于 heisenbugs 的性质，没有多少测试足以证明这个解决方案是正确的。而且我不是并发方面的专家，所以无法正式验证它。

有人可以批准，遵循这种方法可以保证我总是能从ConcurrentHashMap 获得最新的实际值吗？如果这种方法不正确或看起来效率低下，您能推荐我其他方法吗？

Answer 1

你的方法是行不通的，因为你实际上又在重复同样的错误。由于ConcurrentHashMap.put 和ConcurrentHashMap.get 将创建一个发生在 关系但没有时间顺序保证，这同样适用于您对volatile 变量的读取和写入。它们形成 happen before 关系，但没有时间顺序保证，如果一个线程碰巧在另一个线程执行 put 之前调用 get，这同样适用于将在volatile 那就写吧。除此之外，您还添加了另一个错误，因为将 ++ 运算符应用于 volatile 变量不是原子的。

对volatile 变量的保证并不比对ConcurrentHashMap 的保证强。 It’s documentation 明确声明：

检索反映了最近完成更新操作在开始时保持的结果。

The JLS states 表示外部动作是关于program order 的线程间动作：

线程间动作是由一个线程执行的可以被另一个线程检测或直接影响的动作。程序可以执行多种线程间操作：

…

• 外部操作。外部动作是可以在执行之外观察到的动作，其结果基于执行外部的环境。

简单地说，如果一个线程放入ConcurrentHashMap 并向外部实体发送消息，而第二个线程根据先前发送的消息从外部实体接收消息后从同一个ConcurrentHashMap 获取，则不可能是内存可见性问题。

可能是这些操作不是这样编程的，或者外部实体没有假定的依赖关系，但也可能是错误位于完全不同的区域，但我们不能告诉你没有发布相关代码，例如密钥不匹配或打印代码错误。但不管是什么，volatile 变量都不会修复它。